LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Enrico_Segre

Properties for Run-time Shortcut menu

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

Make it possible to create and modify Run-time Shortcut menus via scripting properties, and to retrieve them at run time. Any reason why not possible?

10 Comments
wiebe@CARYA
Knight of NI

wrote:

Make it possible to create and modify Run-time Shortcut menus via scripting properties, and to retrieve them at run time. Any reason why not possible?


It is possible, but only in the menu activation event. And that is probably the answer to why it's not possible in an easier way. Changing it though a normal reference from a property, would mean keeping a copy is needed, since the user might have activated the menu while it's being edited. The event construct prevents this.

Enrico_Segre
Active Participant

It still doesn't make sense to me that this would be the reason for excluding scripting properties, which manipulate the controls in VIs not being run. For runtime instead I wouldn't buy "user might have activated the menu while it's being edited". If I think at a Menu Ring control, the user may be choosing an element, but the fact doesn't prevent the existence of a Strings[] property, which can change the entries dynamically.

But even if we talk of runtime and events: the Menu palette has VIs, and in the Event structure both "This VI", "Panes" and "Controls" support Menu Activation? and produce an event connector with a MenuRef which can be legally wired to these VIs. I have't tried out all the combinations, but it would look that menu items can be edited there. There is even a Customising Shortcut Menus.vi in the Examples, using them.

The Menu palette has even a Current VI's Menubar constant which provides a MenuRef, Event structure or not. Why the MenuRef of a generic control cannot be accessed too?

Enrico_Segre
Active Participant
wiebe@CARYA
Knight of NI
It still doesn't make sense to me that this would be the reason for excluding scripting properties, which manipulate the controls in VIs not being run. For runtime instead I wouldn't buy "user might have activated the menu while it's being edited". If I think at a Menu Ring control, the user may be choosing an element, but the fact doesn't prevent the existence of a Strings[] property, which can change the entries dynamically. 

Misread scripting for VI Server. My bad. 

 

But even if we talk of runtime and events: the Menu palette has VIs, and in the Event structure both "This VI", "Panes" and "Controls" support Menu Activation? and produce an event connector with a MenuRef which can be legally wired to these VIs. I have't tried out all the combinations, but it would look that menu items can be edited there. There is even a Customising Shortcut Menus.vi in the Examples, using them. The Menu palette has even a Current VI's Menubar constant which provides a MenuRef, Event structure or not.

Yes, the menu's can be edited in the event structure. But like I said, there could be a reason that it can be done *only* there.

 

Why the MenuRef of a generic control cannot be accessed too?

Probably because it would be confusing (not saying that's a valid argument). It would be able to change the menu if you're in an event structure, or when the VI is not running. But the property will always be available... That will confuse people.

 

I agree that (at least reading) the control menu should be available with scripting.

Enrico_Segre
Active Participant
I agree that (at least reading) the control menu should be available with scripting.

 

Not enough to spare a humble kudo? Smiley Frustrated

wiebe@CARYA
Knight of NI

Sure. Does kudo's don't grow on trees you know. (Was waiting for the idea to be set to "Completed, working in NXG" (don't know if it is)).

AristosQueue (NI)
NI Employee (retired)

> Was waiting for the idea to be set to "Completed, working in NXG"

 

NXG doesn't yet have scripting at all, so, no, not complete. 🙂

wiebe@CARYA
Knight of NI

>> Was waiting for the idea to be set to "Completed, working in NXG"

 

> NXG doesn't yet have scripting at all, so, no, not complete. 🙂

 

But this doesn't need to be scripting. It could be a new VI Server feature.

AristosQueue (NI)
NI Employee (retired)

I abused the term "scripting." Let me rephrase: NXG only got control refnums three weeks ago in the 2.0 release. There are a lot of properties they don't have yet.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.