Customizable dialog box

[JB]

---

@altenbach  a écrit :

---

@JB wrote:

I’m looking for a VI that implements a dialog box with these options :

 - configurable buttons (OK, OK/Cancel, Yes/No, Yes/No/Cancel...)

 - selectable dialog appearance (Standard, Critical, Question, Exclamation, Information)

 - modal or non‑modal execution

 - synchronous or asynchronous call

 - optional automatic closing after a configurable timeout

 - compatibility with both 32‑bit and 64‑bit versions of Windows and LabVIEW

Any suggestions or shared VIs would be greatly appreciated.

Thanks in advance!

---

Paul might just provide a good solution for a reasonable subset of your requirements.

I assume you are looking for a dialog subVI that has these options as inputs.

Synchronous vs. asynchronous has to be decided by the caller, so you would need an additional wrapper, especially also if you want it asynchronous and disappear after a given amount of time. How are you planning to get the return value in the asynchronous case?

Should it be reentrant so you can use multiple instances? If not, it could be implemented as an action engine that can show/hide its panel based on inputs, return immediately, but keep the panel open if needed. It would remain open until the next call where it would act according to the new inputs. It could even display a timestamped log of the last few calls to it.

Note that the stock 3-button dialog is actually a set of VIs that you could use as a starting point.

(as long as you do it all in LabVIEW, bitness is irrelevant)

---

When the dialog box is called asynchronously, it is used to display information and contains only a single OK button. Depending on the configuration, it must be closed by the user or will automatically close after a specified timeout, but we do not handle the returned value.

[paul_a_cardinale]

Try this.  Here are your assignments:

1. Place it in user.lib *
2. Change the names.
3. Edit the library icon (and apply to contained items).
4. Change whatever you like.
5. Test thoroughly.
6. When you find and fix bugs, post the fixed version.

* Due to a limitation in the way LabVIEW handles Express VIs, I strongly recommend that you put all homemade Express VIs in user.lib.

[BertMcMahan]

Sounds like you don't need them, but asynchronous returns could be handled by the dialog VI returning a notifier refnum upon which it'll supply the result at a later time.

I think you'd likely lose the notifier refnum if nothing registers for it by the time the dialog closes, though. I also think the automatic garbage collector would close out the dangling refnum when your top level VI finishes, but if this program runs a long time you should handle it manually.

The safe bet would be to have the dialog VI use "Get notifier status" to see if anything's registered for it when it's ready to timeout/close; if so, then it closes normally. If nothing is waiting, it closes its own notifier.

All of that should ideally be wrapped in something so your users don't need to remember to close their own notifications.

Or, you could launch yet another async process that auto-handles the notifier; it periodically checks the notification and, if there are no waiters then it closes itself out. Probably the safest and easiest option.

[paul_a_cardinale]

---

@BertMcMahan wrote:

Sounds like you don't need them, but asynchronous returns could be handled by the dialog VI returning a notifier refnum upon which it'll supply the result at a later time.

I think you'd likely lose the notifier refnum if nothing registers for it by the time the dialog closes, though. I also think the automatic garbage collector would close out the dangling refnum when your top level VI finishes, but if this program runs a long time you should handle it manually.

The safe bet would be to have the dialog VI use "Get notifier status" to see if anything's registered for it when it's ready to timeout/close; if so, then it closes normally. If nothing is waiting, it closes its own notifier.

All of that should ideally be wrapped in something so your users don't need to remember to close their own notifications.

Or, you could launch yet another async process that auto-handles the notifier; it periodically checks the notification and, if there are no waiters then it closes itself out. Probably the safest and easiest option.

---

I can't imagine any scenario that would need asynchronous returns.

[BertMcMahan]

---

@paul_a_cardinale wrote:

---

---

I can't imagine any scenario that would need asynchronous returns.

---

Mainly for long running, unattended tests.

I could imagine a scenario that pops up a dialog "Warning: Temperature out of bounds, aborting in 5 minutes" with 5 minute timeout. You could block with the notification, but if it's in your UI loop then that would stall out all of your other UI updates. If your returns are async you could throw up the popup and keep going with your other tasks. If it times out, abort the test. If the user clicks "Ignore", then record the deviation and keep going.

Or you could have a scenario where you need to notify a user of something but keep going, then log when the user acknowledged that something.

[mcduff]

---

@BertMcMahan wrote:

---

@paul_a_cardinale wrote:

---

---

I can't imagine any scenario that would need asynchronous returns.

---

Or you could have a scenario where you need to notify a user of something but keep going, then log when the user acknowledged that something.

---

I do use a Call and Forget for some dialogs, similar to the situation described above, except I don't log when the user acknowledged the message. If the dialog window doesn't have a choice, e.g., "Continue" or "Cancel", having an Call and Forget is nice for non-blocking applications. If the user has a choice of actions, then it would be a Call and Collect Dialog.