Custom Run time menu

[nanocycle]

Hi,

Creating custom menu is accessible by Edit-->Run-time menu.

Also i am able to create custom Items but i need to define my own duty for items.

For example,i have a "settings" item in my menu and i want to open a sub vi when user clicked it.

How can i create such a menu and how program it to act a above?

Sincerely

[Kyle97330]

Use an event structure with the event under "<This VI>" called "Menu Selection (User)".

Then use the ItemTag or ItemPath values generated by the event to detect which menu option was chosen, and do the appropriate action based on that value, such as launching your subVI.

[nanocycle]

Thanks a lot my friend.

i works pretty good .Item tag returns me "setting" string when i click setting menu.

Now how can i open that external vi file?

best regards

[altenbach]

Define "open"!

Is the VI already in memory? Do you just want to show a static front panel or does is need to start running? Look for methods such as "show front panel", or tools such as "start asynchronous call", etc.)

[nanocycle]

I need to open it like a pop up.That vi will be opened in run mode and when i pushed ok button,will be closed.My main vi always will be in background and in running mode.

regards

[rolfk]

---

@nanocycle wrote:

I need to open it like a pop up.That vi will be opened in run mode and when i pushed ok button,will be closed.My main vi always will be in background and in running mode.

regards

---

The easiest solution is to make your pop up VI have a loop that finished when you click the OK (and Cancel) button. You can then go into VI properties and select the frontpanel appearance (title bar, no scrollbars, no menu bar, user closable or not, etc.) and “open Frontpanel when called”  and its subitem “close if originally closed”. Now you can drop that VI in your diagram et voila!

Don’t forget to configure an according event structure case for “VI closing” if you enable the option to let the user close the frontpanel (button in the right upper corner) and treat it the same as your cancel operation.

[altenbach]

---

@nanocycle wrote:

I need to open it like a pop up. That vi will be opened in run mode and when i pushed ok button will be closed. My main vi always will be in background and in running mode.

---

You are still not quite differentiating between subtleties. While the subVI is open if called as Rolf suggested, the main VI is stalled for the part of the code that contains the just called subVI. This is probably OK if it needs to wait for return values anyway. You should also make sure that the subVI is modal so it cannot be covered by other windows and forgotten (there is a preconfigured appearance setting for "dialog").

[JÞB]

---

@altenbach wrote:

---

@nanocycle wrote:

I need to open it like a pop up. That vi will be opened in run mode and when i pushed ok button will be closed. My main vi always will be in background and in running mode.

---

 You should also make sure that the subVI is modal so it cannot be covered by other windows and forgotten (there is a preconfigured appearance setting for "dialog").

---

It is also possible for the properties that make your popup behave as a popup (FP. Closable, FP.Behavior, etc.. ) to be written at runtime to avoid saving the vi with those dialog settings.   One of the most annoying things that can happen to a developer is to have a dialog subvi open and try to run another vi.  That leads you to the point where your dialog goes straight to the front of the screen while not running!  (Leaving you with a hung development environment and no option except for killing LabVIEW with the task manager)  

I wrote a nugget years ago about better dialog design practices a few years ago. With example code and a vi template. 

Let's see how fast someone else beats me to the link...