Run time EDIT menu - how to enable/disable items properly?

[CoastalMaineBird]

LV 2013, Win7

I have an app with 15+ non-modal windows. Each window has a MENU BAR, with the same basic menus in it:

File - New, Open, Save, Save As...

Configure - list of possible configuration windows.

Display - list of possible data display windows.

Window - list of currently open windows..

etc.

A few of the windows have additional menus or items, just for that one window.

In each window, I intercept the MENU ACTIVATION? event, and run a standard VALIDATE procedure, which adjusts the menus for presentation: disabling this item and enabling that one, etc.  

All that works fine.

My question is about the EDIT menu.  I construct the menu at window INIT time, with CUT, COPY, PASTE names, and APP_CUT, APP_COPY and APP_PASTE tags.

My VALIDATE procedure does not do anything with these EDIT items - yet they enable/disable appropriately anyway.  If I land on a TEXT field, I can CUT, COPY and PASTE appropriately, If I select some other field (e.g., a row in a TREE control, they are disabled.

I want to implement a CUT/COPY/PASTE for this TREE control, using the menu.  i.e. if you select a certain row in the tree and hit ctrl-C I want to copy the structure THAT THE TREE ROW REPRESENTS into my own clipboard, and if you go somewhere else and click Ctrl-V, I can check that I have the appropriate object on my clipboard and paste it in if appropriate.

I can make all that work by itself, but how do I do it WITHOUT disrupting the existing behavior regarding text fields?

If I enable PASTE only if MY clipboard contains one of MY structures, then how does PASTE get enabled for a text field?

[CoastalMaineBird]

I tried controlling the ENABLED flag ONLY if the tree has KEY FOCUS, and leaving it as is, otherwise.

But no joy.  The light lights up correctly, but the menu item stays disabled.

[James_W]

If I've understood the problem, hopefully this will help.

using an event you can determine is the user has clicked on a menu item (by tag).

You can then tree through the menu and ensure that all items parent items are selected and all other items are deselected.

You can also pass the tag to another VI to handle the common functions and have a specific VI that handles the unique functions for the unique menu items.

Passing menu references around LabVIEW by anything other than direct wires seems to get buggy. I did try using FGVs and globals, neither allowed correct menu updates after a few refresh's.

Modularise the subfunctions and poke them in the VI that contains the menu, then pass out the Menu action to a consumer loop.

(Historically I have got the menu reference an update inside the event structure as it doesn't seem to work in a separate display Q for me)

A Parent being disabled affects the children, but a child being disabled does not affect the parent, so if there are no children active, you want to disable the parent too.

(Basically you are looking at creating a re entrant function.

Is this the sort of information that you are looking for?

James

[CoastalMaineBird]

Well, thanks for trying, James, but that's off the track from what I was looking for.

I'm not passing around a menu reference, other than straight into and out of a common function to handle the common tasks.  

You can see in the 2nd post above, that I handle the ACTIVATION? event by passing the menu ref to a common function.  That handles the basics, like the list of open windows, etc.

When that function returns, I have some things to do specific to this one window, like enable the SAVE if there is a file name.

THAT ALL WORKS JUST FINE.

It's the EDIT menu specifically, that I have trouble with.  The VALIDATE function you see above does NOT enable or disable the EDIT menu items, yet they are appropriately enabled and disabled anyway. (Appropriate for TEXT fields, anyway).  LV itself must be doing that, but I don't know where or when.  It appears to be AFTER this ACTIVATION? event is handled, because it overrides my setting.

I know how to handle the custom Cut Copy Paste behavior I want. 

What I want to know is how to add my own custom C-C-P behavior for my tree without disrupting the existing behavior for text fields?

[James_W]

Hi Steve,

I think you've got the wrong event.

It's very difficult to see without an example VI.

1 cause could be that you are handling the Activation? event (which is a filter event).

- Are there any parallel or near parallel notify events which could be overriding the state of the menu.

- Is the filter event being correctly captured 100% of the time against the latest capture (or are you locking the FP until the current event has been processed, causing a bizarre race condition in the event structure.

Have you customised the Run Time menu as you require it - you could call the RTM file from your different VIs (or call as required) and process the Copy event by TAG as it happens based on CTRL+C being pressed. (but that would be using the "Menu Selection (App)" notifier event instead.

James

[Intaris]

Why use the APP_ entries at all? Why not simply remove the APP_ entries ande fine your own..... The APP_ entries have some behind-the-scenes magic over which you have no control.

It's best not messing too much with them,

[CoastalMaineBird]

1 cause could be that you are handling the Activation? event (which is a filter event).

--- I think that's the best place to make sure the enabled / disabled / checked state is current, before the items are seen by the user - is there a better place?

- Are there any parallel or near parallel notify events which could be overriding the state of the menu.

--- No. I concentrated all the menu item behavior in one validate subVI for all the common stuff, and exceptions are still within the ACTIVATION? event for each window. The only other menu-reflated event I use is MENU SELECTION (USER) to handle whatever gets chosen.

Is the filter event being correctly captured 100% of the time against the latest capture

--- I don't know what that means.

(or are you locking the FP until the current event has been processed, causing a bizarre race condition in the event structure.

--- I use the default behavior.  The "Lock Panel until this event completes" option is checked and not available (disabled by LabVIEW).

Have you customised the Run Time menu as you require it

--- Yes.  I construct the entire menu in code.

you could call the RTM file from your different VIs (or call as required) and process the Copy event by TAG as it happens based on CTRL+C being pressed. (but that would be using the "Menu Selection (App)" notifier event instead.

--- I don't use RTM files, since I duplicate the basic items in every window, I don't want to have to change umpteen RTM files when something changes in the basics. And I don't want to switch from code to menu-editor back and forth.  I tried that at the beginning of this project and it was just a pain.

[CoastalMaineBird]

Why use the APP_ entries at all? Why not simply remove the APP_ entries ande fine your own..... The APP_ entries have some behind-the-scenes magic over which you have no control.

--- I use them because I WANT the default behavior of recognizing when the key focus is in a text/numerical field that can be CCP'ed and enabling CCP when it's available.  I don't want to have to do that all myself.

I just want to ADD to it:

If Current Field is CCP-able  

    Do nothing  (Cut, Copy, Paste already enabled by system)

else

    If Current Field is my Tree

    AND

    Current Selection is > 0

   THEN

        ENABLE CUT, ENABLE COPY

    if Current Field is my Tree

    AND

    My Clipboard is not empty

    THEN

         ENABLE PASTE

I'm just wondering how (if) I can do that.

[Intaris]

In the ENABLE CUT and ENABLE COPY you will need to define other Tags.  Seeing how the functionality you want to implement is non-standard LV behaviour, you're going to have to handle it yourself anyway somewhere.  So for non-trees, stick with APP_COPY and so on but for your custom Tree functionality, use a different Tag.

So everything else after your "Else" needs to remove the APP_COPY et.al and replace them with others.

Yes, this makes handling the menu selection slightly more tedious but I think it's the only reasonable way.

[CoastalMaineBird]

In the ENABLE CUT and ENABLE COPY you will need to define other Tags.

--- Well, the tags are actually DEFINED elsewhere, when i set up the menu.  But I get your point - for this one WINDOW, I will have to override the default tags and use custom tags for PPC.

But that means tracking what the key focus is and enabling CCP myself.  in my case I have a hundred items on the panel (in tabs) - some CCPsble, some not.  Yuck.

Seeing how the functionality you want to implement is non-standard LV behaviour, you're going to have to handle it yourself anyway somewhere. 

--- For handling the actual clipboard operations, yes, I expected that.  But I didn't expect enabling the menu items to be so difficult.  If LabVIEW did it's magic BEFORE the ACTIVATION? event, then I could override it.  But no.

Yes, this makes handling the menu selection slightly more tedious but I think it's the only reasonable way.

--- Well, it's not "slightly", it's more major than that.

I think I'll just append a separate CUT STRUCTURE, COPY STRUCTURE, PASTE STRUCTURE item into the menu, and forget the shortcut keys..

But kudos for your thoughts, anyway.