Shift + Right Click does not behave correctly in run mode...

[Jeramy_Soucy]

When I run my VI a shift+right click launches the tools pallet (just like it does in edit mode), but when I create and executable from the VI, shift+right click simply produces the shortcut menu for the clicked control (desired effect).  This is terribly annoying and makes testing a pain (have to build the exe to make sure behavior is correct).  Does anyone know how to keep this from happening, short of discarding all right clicks and drawing my own context menu?

[RavensFan]

I don't understand your issue.  If it is in run mode, of course, then the front panel is supposed to behave like if it was running.  You even said this was the desired effect.  But then you said this is annoying.  And what are you expecting with an .exe.

You have 3 modes for the front panel.

1.  Development environment, edit mode.

2.  Development environment, run mode.

3.  Compiled Executable environment.

What version of LabVIEW do you have?  And exactly how do you want it to behave in each of these 3 conditions?

EDIT:

I played some more and I think I see the behavior you're trying to describe.  When you are in Development environment, either in run mode but not running, or when actually running.  A shift right-click on the VI (but not on a control) produces the tool palette.  And you don't want that.  Does that sound accurate?

I don't know if that's truly annoying.  I don't use run mode much when I'm in the development environmentn (unless of course I'm running).  And when I'm running, I never have a reason to shift right click on a blank area of the VI.

Are you using customized shortcut menus?

Message Edited by Ravens Fan on 02-19-2009 01:58 PM

[Jeramy_Soucy]

Ravens Fan, I am certain that you interpreted my post incorrectly.  To make a long story short...yes, what you describe in your edit is correct.  When the VI is in run mode shift+right click brings up the tool pallet (as stated in my original post).  It is annoying to me because the pallet is useless when the VI is running and it keeps me from being able to easily have shift+right click custom functionality in run mode.  What I would like to happen during a shift+right-click on a particular control is a custom operation (implemented in the Mouse Down? event) followed by the custom shortcut menu for that control (this is the "desired effect" as stated in my original post), which only happens in the compiled executable.  In order to avoid having the tool pallet pop up instead of my custom menu I need to run the VI as an executable.

Perhaps NI can explain the point of having the tool pallet during run mode?  It should only come up in edit mode...unless I am missing something.  If I am the only one who feels this way then so be it, but I'll be submitting a feature request anyway just out of principle.

BTW shift+right-click produces the tool pallet in run mode regardless of the target object (front panel, control, indicator, etc).

I am using LabVIEW 8.2.1., but as far as I know this behavior is not unique to this version. I have not experimented with other versions due to time constraints and project requirements.

[RavensFan]

Yes.  Having the tool palette show up in run mode or while running is truly pointless as you can't use any of the items on the palette.

In LV 8.6, if you shift right-click on the control, a context menu that makes sense pops up.  That is how I originally interpreted your message.  It wasn't until I shift right clicked off the control that the tool palette popped up.

In your original message, it wasn't clear what your desired effect was, and you hadn't mentioned using a custom shortcut menu or the event structure.

Here is an interesting link that is related http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=352427#M352427.  It doesn't specifically mention run or edit mode, but apparently the behavior was modified in 8.6 (shift right click on control did not bring up tool palette) in a way that annoyed people.

[Jeramy_Soucy]

Thanks Ravens Fan.  I could've been more articulate in my original post (hence the re-explaination in the second).  For now I'll just have to test my functionality with an executable.  : (

[TCPlomp]

Is there a specific reason to differentiatie between <shift+richt-click> and <right-click>?

Ton

[Jeramy_Soucy]

Yes.  In my application <shift+right-click> and <right-click> do two different things.

[X.]

It would be nice for NI to acknowledge that this behavior is useless and undocumented and escalate it to a CAR.

I was trying to implement a modifiable right-click menu for a control using a shift-right click but this bug doesn't allow this to be debugged therefore I won't use it.

Luckily, a Ctrl-Right Click doesn't create this kind of problem, so I have an alternative.

Tested in LV 2013 SP1 64bit