run time menu error

[TCPlomp]

---

Intaris wrote:

Surely a graph has only one active menu at a time?

Shane.

---

No, the graph consist of many items (axes, legends, grid, graphs, labels, cursors) if all these items were to be kept in memory besides the actual settings that are stored inside the (X)Control.

From a programmers point of view the menu is not the place to keep the settings, that is the control or diagram, such a feature will be a good place for race conditions.

Ton

[Intaris]

I'm not suggesting the menu should be aplace to keep the settings, it should just remember which items were checked last time.  Of course the settings need to be stored within the program itself.  It would just be a piece of work less not having to intercept the "Menu Activation?" Event in order to do this.

Is it possible to customise the menu for the axis of a graph?  I wasn't aware of this.   How does one go about that?  Once I activate acustom run-time menu for a graph, it is the ONLY menu which appears when right-clicking the graph ragardless whether I click on an axis, plot or whatever.

Regarding the other properties of the control such as "Autoscale X" these ARE retained, so the issue you're mentioning is already in practise.  I'm talking about the ability to retain settings (for visualisation only) of user-generated runtime menus.   If an axis is not modified, then nothing would need to be stored, no?

Shane.

[TCPlomp]

---

Intaris wrote:

I'm not suggesting the menu should be aplace to keep the settings, it should just remember which items were checked last time.  Of course the settings need to be stored within the program itself.  It would just be a piece of work less not having to intercept the "Menu Activation?" Event in order to do this.T

---

 This screams race condition all over it.

---

Is it possible to customise the menu for the axis of a graph?  I wasn't aware of this.   How does one go about that?  Once I activate acustom run-time menu for a graph, it is the ONLY menu which appears when right-clicking the graph ragardless whether I click on an axis, plot or whatever.

---

You can attach your menu items to the standard menu using the filtering event, you don't have to use an rtm to customise the menu.

---

 Regarding the other properties of the control such as "Autoscale X" these ARE retained, so the issue you're mentioning is already in practise.

Shane.

---

Are they? I assume NI is using the same structure updating the menu when it is requested (look at the time it takes when you right click on a control).

Ton

[Intaris]

Lots of things scream race condition.  Doesn't mean they shouldn't be included.  The possibility of race condision is also limited because we're only dealing with one interaction point, the menu selection event

I am aware of the ability to attach to a menu using the filtering event.  That's not what I'm talking about here.  I'm talking about using an rtm.   It's what my original post was about and it's what was in my code provided.  Obviously a menu created on-the-fly cannot retain its state.  Nobody's trying to argue that point.

I'm also not arguing the mechanism of keeping the display settings, I'm simply arguing that the user does not have to intercept the "Menu activation?" event to set the "Autoscale X" check mark.  It's done "in the background".  Whether NI uses method X or method Y to do this is irrelevant. The code for it is encapsulated in the control (as is the runtime menu when using the method I'm talking about).

I would have thought that setting a run-time menu (Via pre-configured RTM file) would give some advantages to creating a menu on-the-fly.  As it is I see no advantage except for maybe having the menu copied with the indicator or control (when including the menu in the control) or allowing switching between menus (using property node to load the menu at run-time).  Personally, I would welcome either

1. Stating this difference in the help files
2. Allowing a RTM (at least ones stored within a control as a replacement for the default menu) to retain their state

Even if the state WOULD be retained, it doesn't stop people using the event intercept method if they want to (Would not break existing code).

Either way I'm able to get my code working so the "problem" is reduced to a minor annoyance.  The handling of the different menus just seemed to be a bit counter-intuitive to me but I suppose different things are intuitive to different people.  Having only ever implemented VI menus before, I expected control menus to work in the same manner but they don't.

Maybe it's a case for an XControl.  Time I learned about those.  Then it should be possible to fully encapsulate the menu into the control, no?

Shane.

Message Edited by Intaris on 10-03-2008 04:00 AM

[TCPlomp]

Hi Shane,

thanks for the interesting discussion, I have learned new things as well, such topics keeps a mind clear and sharp.

Ton

[Intaris]

You're more than welcome.

Needless to say I've learned something too.

It's refreshing to be able to take part in forums where people are able to argue on different points of view without danger of offending people.

It's this kind of differentiated argumentation which makes the forum such a great place to be.  And it means I'm never afraid to throw a "stupid" question out there.  Now whether this is a good thing or a bad thing, I'll let others decide..... 

Shane.