Popup menu

[bogdani]

Hi

I'm just wondering, is any simple way to create my own popup menu. For example I in my VI I want my onw popup menu which is changing in dependence where the mouse cursor is.

I found on NI forum some solution that use win32 API, but I'm looking for easiest way.

Thank You for any help and suggestions

Bogdan

[Michael Aivaliotis]

I created a LV7.0 VI that shows how to do this using the event structure and a listbox. I am not Entirely satisfied with this implementation because it has an issue when you right-click close to the border of the VI. The menu gets chopped-off. However this implementation might be ok if the right-click requirement is needed for internal areas of the VI.

Download File:post-19-1084498075.vi

[Michael Aivaliotis]

I am not Entirely satisfied with this implementation because it has an issue when you right-click close to the border of the VI.

Well, I took my previous implementation back to the drawing board and decided to go with a sub-vi call. In essence, the menu list is a subvi that pops-up. It works quite well actually. I was surprised at the excellent look and feel of it. it looks like a real right-click menu. it might require a bit of programming to create nested menus but it can be done. Best of all, no WinAPI call required. :thumbup:

In the process to developing the above implementation I tried using Callback VI's. It almost worked however I was getting LabVIEW crashes and hangups. The Callback VI was the menu so it contained the event structure. When the menu was selected and the Callback VI panel was closed, LV would hang. Maybe I'll post that version seperatly.

Download File:post-19-1084516114.llb

[bogdani]

Thank You for a quick answer.

I think it is very interesting solution and what is very important it's works.

I wold like to put your solution to my page - Polish LabVIEW Center - and show it polish users. I hope your are agree for that (of course I put the autors name too).

I would like to learn from you, because you are more advance users in LabVIEW than me any most of Polish LabVIEW memebers.

I want to create Polish User Group but now I only think about it.

Thank you again for your help and sugestions

Bogdan

[didierj]

I took Michael's example onto the drawing-board and "enhanced" it a bit.

To my feeling the pull-down menu now works quite like Windows ones (sorry, don't know if it works like mac/linux ones).

Main features:

- no (yet) hierarchy

- put "<Separator>" to produce a horizontal line, that divides the pull-down into visual sections

- change the selected element also with the keyboard (up-/down-key).

- width set to largest text

- Saved in LV7.0

use the "Demo" to see how it works.

Download File:post-253-1103190660.llb

[Michael Aivaliotis]

I took Michael's example onto the drawing-board and "enhanced" it a bit.

To my feeling the pull-down menu now works quite like Windows ones (sorry, don't know if it works like mac/linux ones).

Main features:

- no (yet) hierarchy

- put "<Separator>" to produce a horizontal line, that divides the pull-down into visual sections

- change the selected element also with the keyboard (up-/down-key).

- width set to largest text

- Saved in LV7.0

use the "Demo" to see how it works.

Download File:post-253-1103190660.llb

3057[/snapback]

That's great! Do you think you or someone else can enhance this to include nested (hierarchy) menus? This would make it complete... hint! Take a look at OpenGoop...

[didierj]

That's great! Do you think you or someone else can enhance this to include nested (hierarchy) menus? This would make it complete... hint! Take a look at OpenGoop...

3066[/snapback]

Yes, I was thinking of making a version that allows nested menus. Yet I didn't made up on the format the "data" would have to be. What do you think?

Would a string array, where nested elements are built like paths (with backslash separating the levels), be enough?

...about the OpenGoop, I know and use it well, but somehow on general tools I prefer to use this way. It is an implementation way I use since quite a while (longer than I know OpenGoop). Infrequently (but it happens) I get problems of overriding and such stuff, when I use Goop, OpenGoop, and LV-made VI's and port it to other computers. I prefer to have the whole stuff packed in 1 .llb.

Didier

BTW: How I have implemented it is the way how GOOP (from Endevo, distributed by NI) is built. The LV5.x version of GOOP wasn't password protected and so I found about the internals. Unfortunately I don't have this version in my archives anymore.

[Mike Ashe]

Excellent utilities, both Michael's and Didierj's.

Data Format:

I have a dynamic menu bar menu creation utility from a friend that populates a user defined menu hierarchy from simple text. The format for nesting uses > characters, one for each nested level, as in:

File

>Open

>New

>Close

Edit

Tools

>OpenG Tools

>>Packaging Tools

>>>OpenG Package Installer

It's his code, so I'll have to ask permission to give it out. But the data format is obviously not proprietary.

Nesting Implementation:

It seems to me that this is an excellent use for General Recursion of one menu, passing down the nested items to the next. Since it is for a GUI function, the performance hit of recursion should not be noticed.

http://forums.lavausergroup.org/index.php?...findpost&p=1850

Another good method might be with templates. I'm kinda busy right now, but if nobody comes up with a general nested Right Click Menu (RCM) by New Years, I may give it a shot and a few hours.

[hfettig]

Hi Guys,

I had a couple of slow days at the office and had a crack at it. Let me know what you think.

I more or less created similar VIs to the menu creation for the LV menu.

That way you can now create nested menus.

Furthermore you can then link a control to a menu. This way you can have different menus for different controls, but also easily link 10 controls to the same menu.

I tried calling my menu display recursively, however I ran into problems with events see my other post

However, I managed to work around it using a template. The only thing that bugs me is that once I close a menu FP the instance of the template is still kept in memory until the main VI stops. Any ideas how to fix this?

Furthermore I have to do some cleanup and some commentary. If anyone would like to draw some icons, be my guest.

Cheers,

Heiko

Download File:post-1022-1104867276.llb

[didierj]

Congratulation Heiko, :thumbup:

You outraced me by 2 days.

I still want to present my solution here, so the time I used isn't totally wasted .

My approach isn't quite the same as yours. It's based on what I did prior. To Michaels and Jims delightment its based on OpenGoop.

- It still works like (MS) pulldown-menus with mouse AND key navigation (up/down/left/right arrow/ESC/Enter).

- The nested elements are indicated with a ">" sign. Do not insert a blank before, otherwise it isn't recognized.

- Separator lines are marked as "<Separator>" and can have also n ">" signs before. The separator lenght adapt to the longest text length in a menu.

- Unfortunately you'll have to assign/hanlde a menu for each control.

Try the Demo and right click on the string control.

Didier

Download File:post-253-1105008908.zip

[hfettig]

Hi Didier,

Very nice implementation. Love the icons :worship:

I have to check how you implemented closing child menus and going back up. So far mine doesn't do that.

If you look at my code you'll see, that the popup part is mostly based on your original design. :thumbup:

One thing I found when I was playing with the list box properties was, that if you set the symbol for a line to -1 a proper separator is displayed. This works even if you set display symbols to false. And you don't have to calculate the length of the separator.

I also like the way you describe the whole submenu structure in one array. If you don't mind I will add that to my parser.

Maybe we should join forces and develop this further.

Cheers,

Heiko

PS.: I attached a version of my program that actually works as an llb ;-) Thanks to Jim for pointing out the bugs.

Download File:post-1022-1105020889.zip

[Michael Aivaliotis]

This is great!

Thank you to all in this thread for your enthusiasm. :thumbup: . I would really like to see the pop-up menu system (RCPM) become an official openg package. I currently have a use case for this tool to use it in the next generation openg package manager which we've named Commander. Before this happens, I'd like to debug the RCPM and create it into a package.

I've been busy working on the release of the NEW openg website but I will spend some time working with the RCPM and give you my feedback in this thread ASAP. Once the new openg website is up and running we can transfer this discussion over there.

[Michael Aivaliotis]

My comments follow:

hfettig, your code has a path problem:

I'm not sure what you're trying to do with the name mangling. I took that out and it worked.

Menu look and feel.

hfettig, in your implementation, I noticed that when you hover over an item that leads to a submenu, nothing happens. You have to click on the item for the submenu to fold out. This is contrary to standard menu behavior. In general, I noticed both (hfettig and didierj) implementations have menu's that are non-standard. The question arises, what is standard. Well, in my opinion the menu's should match the system colors and schema whenever possible. For example, dotted lines as separators is not standard. Also, didierj, when a submenu unfolds, it should be slightly overlapping the previous menu.

Architecture

hfettig, I like how you've implemented the architecture to match the built-in menu functions of LabVIEW. However frankly do you think that's easy to program with? It simply takes up too much valuable digram real-estate and requires an extensive concatenation of VI's. I love didierj's method of describing the whole structure in a string array. Perhaps we should target that approach.

The more I think about it the more I come to the conclusion that we should create a menu builder GUI . If you think about it, this is what NI did because they also realized that you can't rely totaly on VI's to create your menus every time. For the casual menu user, a menu editor that saves the menu architecture to a file is all that is really required. However, you still need the VI's to manipulate the menu for dynamic situations. Perhaps we can keep hfettig's approach for dynamic menu manipulation and just build a GUI for menu building.

Programmer Usability

hfettig, I like how there is minimal code required for the launching of the menu. Ideally I would love to have a 3 VI implementation. As long as you have a control reference then that is all you really need. didierj, there is simply too much code required to feed into the functions from the toplevel. Look at how hfettig has used a subvi to capture the control coordinates to minimize the amount of work the programmer has to do for implementation. I believe we can minimize the overhead even more.

Here is what I envision for the final implementation:

[didierj]

One thing I found when I was playing with the list box properties was, that if you set the symbol for a line to -1 a proper separator is displayed. This works even if you set display symbols to false. And you don't have to calculate the length of the separator.

3391[/snapback]

Cooooooool :worship: :thumbup:

Maybe we should join forces and develop this further.

3391[/snapback]

For sure we should.

This would mean that we first should define exactly what the menu should be able to do, on which implementation we base (or if we begin again from scratch),...

Should we switch to personal messages to avoid getting an endless thread?

Thank you to all in this thread for your enthusiasm. I would really like to see the pop-up menu system (RCPM) become an official openg package.

3392[/snapback]

Also my oppinion!

The question arises, what is standard. Well, in my opinion the menu's should match the system colors and schema whenever possible. For example, dotted lines as separators is not standard. Also, didierj, when a submenu unfolds, it should be slightly overlapping the previous menu.

3402[/snapback]

These are details, I chose "my" look to follow the standard of NI's controls&indicators. Overlapping aso. are details easily changable.

What I made is the basic implementation. Build a few vi's around the different parts and you end with 2-3 vi's.

The more I think about it the more I come to the conclusion that we should create a menu builder GUI.

3402[/snapback]

Greate Idea :thumbup: !

[Jim Kring]

My comments follow: 

hfettig, your code has a path problem:

I'm not sure what you're trying to do with the name mangling. I took that out and it worked.

3402[/snapback]

Michael, you must not have the latest appcontrol or file package. The code works fine on my system. Don't you have OpenG Commander installed?

That bit of code was put there to ensure that the code worked, once built (and name-mangled) using the OpenG Builder.

-Jim

[Michael Aivaliotis]

Should we switch to personal messages to avoid getting an endless thread?

3405[/snapback]

Not really, I think this is educational for all.

These are details, I chose "my" look to follow the standard of NI's controls&indicators. Overlapping aso. are details easily changable.

Yes, I realize that. Perhaps it would be nice to create some function VI's that operate on the "look and feel" of the menu. This way the colors and style can be programmaticaly changed. We can also have 3-4 "preset" looks that people can choose from. Remember, the key here is to satisfy a broader audience.

What I made is the basic implementation. Build a few vi's around the different parts and you end with 2-3 vi's.

Ok, I just wanted to clarify that this should be the direction.

Greate Idea for the menu builder GUI :thumbup: !

3405[/snapback]

Do you want to work on this? I think it would be a great way to combine forces. This way there is no overlap.

[hfettig]

hfettig, in your implementation, I noticed that when you hover over an item that leads to a submenu, nothing happens. You have to click on the item for the submenu to fold out. This is contrary to standard menu behavior.

I know, but it took me two days to do the menu handler that stores all the menus and I only had one day left to implement the actual pop-ups. I'm fast, but not that fast :laugh:

Also I agree with Didier, that the look and feel are details that can be easily fixed. Although the roll-out animation and the shadow might be a little tricky

I love didierj's method of describing the whole structure in a string array. Perhaps we should target that approach. 

...

The more I think about it the more I come to the conclusion that we should create a menu builder GUI . If you think about it, this is what NI did because they also realized that you can't rely totaly on VI's to create your menus every time. For the casual menu user, a menu editor that saves the menu architecture to a file is all that is really required. However, you still need the VI's to manipulate the menu for dynamic situations. Perhaps we can keep hfettig's approach for dynamic menu manipulation and just build a GUI for menu building. 

Sounds good to me.

hfettig, I like how there is minimal code required for the launching of the menu. Ideally I would love to have a 3 VI implementation. As long as you have a control reference then that is all you really need.

I like the three VI approach for basic use, especially to add the one array menu structure and the control reference to the constructor. Then for advanced and dynamic use I would suggest the following VIs:

Add Item(s) to menu

Delete Item(s) from menu

Set Item Info (change item name, enable/disable, check/uncheck)

Get Item Info

Link Control to Menu (so you don't have to redefine the same menu for different controls)

Unlink Control from Menu

I was also wondering, whether there was a way to link a menu to columns or rows of a multicolumn listbox, or would this be over the top?

Where do we go from here?

Cheers,

Heiko

[PJM_labview]

Attached is a "merged" version of both context menu tools.

I kept the architecture developed by didierj because it was the more advanced (covering mouse and key events) and I integrate a lot of code from hfettig for using standard separators, symbols, disabled items, multi list column, side behaviors ...

Everything is in LV7.0.

Now, who is feeling like writing a LV6.1 version ?

Note: the menu builder GUI remains to be done.

Also, for Michael only , I fix a bunch of cosmetic issues.

PJM

Download File:post-121-1105386921.zip

[hfettig]

I kept the architecture developed by didierj because it was the more advanced (covering mouse and key events) and I integrate a lot of code from hfettig for using standard separators, symbols, disabled items, multi list column, side behaviors ...

Nicely done,

I like the fact that the 'Prepare' VI already configures and starts all the pop-up menu VIs and the only thing that needs to be done is position them appropriately and open the frontpanel.

The <disabled> and <symbol> tags are great, too.

I think the simplest way to provide advanced menu manipulation, e.g. enabling/disabling items, is to write a wrapper class around the CTX MNU class that deals with the contents of the menu itself.

I was also wondering whether we should we should discern between item names and item tags. It could happen that we have duplicate item names, however, we could force unique item tags. This could be handled in the array as <tag=......>.

I'll volunteer to write the wrapper class if we can come to an agreement on the items mentioned above.

Cheers,

Heiko

[Michael Aivaliotis]

The new OpenG Forums are now live and running. The decision has been made to move forward and make this into an OpenG package. This thread is now closed and a new one has opened on the OpenG Forums here:

http://forums.openg.org/viewtopic.php?t=31

Please continue all discussion there. Nice work everyone. :thumbup: