Universal Dialog Box

[JÞB]

---

@paul_a_cardinale wrote:

Drat again.

I left remnants of debugging code in there, so the UTF-16 LE handling doesn't work.

Stay tuned.

---

Would you be so kind as to provide a snippet so it becomes easy to see what you've done?  I'm really hoping that you have 

• Used a vim
• Used events rather than polling
• Supported Localization of FP elements
• Used property nodes to set FP.Behavior rather than saved it as Modal to avoid hanging LabVIEW when the vi is idle and another vi runs.

[paul_a_cardinale]

---

@JÞB wrote:

---

@paul_a_cardinale wrote:

Drat again.

I left remnants of debugging code in there, so the UTF-16 LE handling doesn't work.

Stay tuned.

---

Would you be so kind as to provide a snippet so it becomes easy to see what you've done?  I'm really hoping that you have 

• Used a vim
• Used events rather than polling
• Supported Localization of FP elements
• Used property nodes to set FP.Behavior rather than saved it as Modal to avoid hanging LabVIEW when the vi is idle and another vi runs.

---

Provide a snippet?  I provided the whole thing.

• The main VI is an Express VI; that's the only way I could make it universal.
• If course it uses events.
• Supports localization of the title, message string, entry field captions, and boolean texts.
• It was just set to modal, but I'll change that to be an option.

[JÞB]

---

@paul_a_cardinale wrote:

---

@JÞB wrote:

---

@paul_a_cardinale wrote:

Drat again.

I left remnants of debugging code in there, so the UTF-16 LE handling doesn't work.

Stay tuned.

---

Would you be so kind as to provide a snippet so it becomes easy to see what you've done?  I'm really hoping that you have 

• Used a vim
• Used events rather than polling
• Supported Localization of FP elements
• Used property nodes to set FP.Behavior rather than saved it as Modal to avoid hanging LabVIEW when the vi is idle and another vi runs.

---

Provide a snippet?  I provided the whole thing.

• The main VI is an Express VI; that's the only way I could make it universal.
• If course it uses events.
• Supports localization of the title, message string, entry field captions, and boolean texts.
• It was just set to modal, but I'll change that to be an option.

---

Snippets allow the code to be seen before downloading...even on Android devices!  Lucky me, my 'Droid" opens docx files just fine.

Look the vi seen in the document attached to This post. 

I originally developed that vi and added it to Templates allowing an easy to modify (Just replace the Data control with the desired Data type and set type specific properties as needed on the FP Data Object 😀)

It shows programmaticly setting FP.Behavior and FP.Closable properties.  And the document explains exactly why a dialog vi SHOULD do so.

The Template predates vim and the Type Specialization Structure by several years.  I'm betting a vim would handle most cases.  But, an Express VI would allow for input data type specific property management (such as file filtering, text and float display formats, radix integer radix,  DAQmx filters, etc...) So I like that you went that route! Kudos!  A vim would likely need to handle Data Type Specific property management as attributes of a void variant and require the user to know how to wrap them around the variant. An ExpressVI would easily allow the ExpressVI generated instance to expose those property values directly to the generated connector pane.

Essentially,  anything that replaces the obsolete and troublesome "TBD Core.vi" is well worthwhile. 👌

[paul_a_cardinale]

Making the FP behavior configurable now raises the question of how I should indicate that in the icon.

Here are some icon variants:

    

Let me know what you think.

[paul_a_cardinale]

---

@JÞB wrote:

---

@paul_a_cardinale wrote:

---

@JÞB wrote:

---

@paul_a_cardinale wrote:

Drat again.

I left remnants of debugging code in there, so the UTF-16 LE handling doesn't work.

Stay tuned.

---

Would you be so kind as to provide a snippet so it becomes easy to see what you've done?  I'm really hoping that you have 

• Used a vim
• Used events rather than polling
• Supported Localization of FP elements
• Used property nodes to set FP.Behavior rather than saved it as Modal to avoid hanging LabVIEW when the vi is idle and another vi runs.

---

Provide a snippet?  I provided the whole thing.

• The main VI is an Express VI; that's the only way I could make it universal.
• If course it uses events.
• Supports localization of the title, message string, entry field captions, and boolean texts.
• It was just set to modal, but I'll change that to be an option.

---

Snippets allow the code to be seen before downloading...even on Android devices!  Lucky me, my 'Droid" opens docx files just fine.

Look the vi seen in the document attached to This post. 

I originally developed that vi and added it to Templates allowing an easy to modify (Just replace the Data control with the desired Data type and set type specific properties as needed on the FP Data Object 😀)

It shows programmaticly setting FP.Behavior and FP.Closable properties.  And the document explains exactly why a dialog vi SHOULD do so.

The Template predates vim and the Type Specialization Structure by several years.  I'm betting a vim would handle most cases.  But, an Express VI would allow for input data type specific property management (such as file filtering, text and float display formats, radix integer radix,  DAQmx filters, etc...) So I like that you went that route! Kudos!  A vim would likely need to handle Data Type Specific property management as attributes of a void variant and require the user to know how to wrap them around the variant. An ExpressVI would easily allow the ExpressVI generated instance to expose those property values directly to the generated connector pane.

Essentially,  anything that replaces the obsolete and troublesome "TBD Core.vi" is well worthwhile. 👌

---

Malleables are not user configurable.  User configurability is the whole point of the project.

There are 133 VIs in the project; I don't think a snippet would be useful.

[paul_a_cardinale]

---

@paul_a_cardinale wrote:

Drat again.

I left remnants of debugging code in there, so the UTF-16 LE handling doesn't work.

Stay tuned.

---

Fixing that initial problem (and another) was easy.  But then I encountered other Unicode issues.  The mish-mash of ASCII/Unicode turned into a headache of intractableness.  So I've decided to re-cromulate things such that externally, everything will be UTF-8; whereas internally, everything will be UTF-16 LE.

Stay tuned.