Cascading Menus Strangeness

[RunningDog]

I have encountered some strangeness with cascading menus that is not intuitive or documented.  I am using cascading menus to help the user populate and edit a table with a limited set of choices.  The intent is that several of the level 1 menu choices will pop-up a list for the user to select from.  The pop-up lists are intended to be very similiar and potentially could be identical, but the actions to be performed with the level 2 pick are to be different.  The level 1 choices are: Add, Insert, Edit, Delete, Move Up & Move Down with the first three cascading to secondary lists. The problem that I have encountered is that when the 2 level lists are identical or nearly so, the ItemPath is not indicative of the user selections.  It appears that the ItemPath defaults to the first menu item in level 1 and the user selection in level 2.  If the pop-up lists are dractically different, the ItemPath behaves are expected.  Has anyone had experience in this area - either confirming or conflicting?  Is this part of a ploy to help improve my coding style :-)? I am using XP with LV2009.  Thanks in advance

--

RunningDog 

[Pcorcs]

Hello,

Could you post an example VI that demonstrates this behavior? Or screen shots of what you are describing? 

I think it would help better identify the behavior you are seeing, and clarify the behavior you are looking for. 

Thank You, 

[RunningDog]

Patrick C.

Attached is VI that demonstrates what I believe to be strange & undesirable behavior.  Please see comment on VI front panel.  Any suggestions would be appreciated.  Thanks in advance.

[JohnMc19]

Hi RunningDog,

I have looked at your code and by using the 'Search string and replace' function I have been able to remove the issue you had.

I hope this quick solution is sufficient!

Regards,

[RunningDog]

John Mc,

Thanks for the prompt repose.  The proposed solution does not solve the issue that I am having - either to it does not address the issue or I did implement it correctly (equally probable).  What I desire in the 'ItemPath' is a result that is indicative of the user selections, such as 'Add & Charlie' or Edit & Echo'.  Although not in this example I am parsing the 'ItemPath' about the semi-colon and using the contents to direct further activities.  Hope this clarifies my need.

I assume the 'Search & Replace' inputs use 'space/underscore/numeral' and an empty string.  Is this correct or did I miss?

Thanks in advance.

--

RunningDog

[JohnMc19]

RunningDog,

You are correct with the 'space/_/numeric'.

I'm not sure I understood you fully, but I think you could possibly change whatever output you desire by still implementing the search and replace function. As for then passing the data of 'Itempath', try using local variables for this, I will continue to look into this for you and try to suggest more possible solutions.

Regards,

[RunningDog]

John Mc,

Again, thanks for the prompt response and the confirmation on my interpretation on the 'space/_/numeric'.

I agree we are not communicating accurately.  I expected the contents of 'Itempath' in the 'Shortcut Menu Selection (User)' event would be controlled by the Right-Click menu event structure and user selections.  If I am interpreting your comment on local variables and search/replace, then the recommendation would be to bypass the Right-Click event structure.  I have difficulty believing that it is necessary and appropriate to bypass the Right-Click event structure as LV2009 uses this technique very effectively in the 'Create Property Node' as do other graphical interfaces.

Thanks in advance.

--

RunningDog

[blawson · Accepted solution]

-The LV rtm parser assumes that all tags are unique.  What you're seeing is the result of a linear search on a list with repeating elements: Menu Selection (User) takes the ItemTag and searches the RTM list for the first instance of that tag from top to bottom.  Insert one of your 2nd tier items on the top tier before everything else and see what happens.

-The help file for this function says "The function always ensures that the tags of all the inserted menu items are unique to the menu hierarchy by appending numbers to the supplied tags, if necessary." It appears that this does not happen if you create the menu dynamically, as you are doing.  I think that's what John Mc was getting at; his code would remove the appended numbers so the tags would look the same (to your parser). Perhaps he's using 2010 and it works in that version?

-If you were to right click on the control, go to advanced->run-time-menu->edit..., you get a dialog box that lets you build a custom RTM.  If I try to recreate your RTM in that dialog, when I go to save it it updates duplicate tags with appended numbers.

-Your best solution is to ensure that your items have names AND tags, where names can be repeated and tags must be unique.

[Pcorcs]

Hello All,

I just ran the VI you posted on my system, and these are the results:

Could you verify the version of LabVIEW you are using? Is this not the behavior you are hoping for? 

Thanks, 

[RunningDog]

Patrick C,

That is the behavior I was expecting.  I  am using LV 9.0f3 on a Win XP system.

I am digesting blawson's message, but your graphic distracted me (my fault).

Thanks for the response.

--

RunningDog