Enable Toggle key to work in Block Diagram

[sandyy]

Hi,

Its difficult to debug a big application. Switching back and forth to FP and Block diagram. Application with Event driven in particular.

Suggestion :

1. Set toggle key  for controls in Front Panel Once.

2. Switch to Block Digram

3. Control + R [ RUN LabVIEW ] and press Toggle Key [ To trigger the user Event ] 

No need switch to Front Panel anymore to trigger the user event each time while debugging. 

Note : Now Toggle key wont work if the active window is block diagram. 

Thanks.

[Intaris]

You have no way of knowing which control has focus when on the block diagram.

Enabling this feature would create a LOT of confusion.  UI inputs are generally made from the UI, not the Block Diagram.  What if you map Ctrl-. to a UI element (essentially blocking you from stopping code in debug mode).  It suddenly nmakes your Block diagram experience dependent on your UI state which seems to be adding way more complexity than neccessary.

[crossrulz]

And, as I said in another one of your ideas, having a second monitor will fix your problem.

[AristosQueue (NI)]

Intaris and crossrulz raise good points. But sandyy raises a legitimate issue he'd like to see solved -- a way of not having to tab over to the front panel in order to trigger keyboard events while debugging. Having a second monitor still requires you to flip focus (ctrl+e) to the panel.

Let's see if we can make this idea viable.

What keyboard items are live when you're on the block diagram AND running? Not many. Pretty much just the control keys, alt-menu keys, and (if you're one of those users with autotool turned off) the TAB key.

Given that... if LabVIEW did redirect the Enter key, Esc key or other not-handled-by-diagram key strokes to the front panel, how bad would that be? Would it be more confusing for people hitting it for the first time than it would be useful for people trying to raise triggers in their code? I'm not sure. Thoughts?

[muks]

I feel this would be pretty confusing if implemented

[Intaris]

I would much prefer an addition tot he Event structure debug possibilities which allows us to trigger ANY event during debugging in order to test the responses.

And when I say ANY event, I mean ANY event, from menu activation to mouse over to value change right down to user events.

[crossrulz]

I'm liking Intaris' idea there.  That would be way more useful.

[AristosQueue (NI)]

Intaris: although a useful suggestion, I don't know if that would satisfy sandyy's request. All the ways that I can think of for triggering an arbitrary event would entail some sort of separate window (floating, probably) that has buttons to push to trigger events (perhaps with some sort of form you fill out to supply parameters of the event). You still would have to switch to it. I was focusing on the "do it without moving focus away from the diagram", but maybe I'm overplaying that aspect.

[sandyy]

Hi AristosQueue ,

If setting up toggle key is confusing. How about this idea of probing the Front panel. where probe window is a floating. If theres an option to access the front panel in probe window. Im not sure if its easy to implement. I thought easy way would be setting up toggle. ( May be can reserve atleast 5 keys to set up ).  Just my idea.

My request is it would be better if we solve the switching between windows.

Thanks all for the comments.

[Intaris]

What is exactly the difference between having the FP ina probe window and just having the FP open?

[AristosQueue (NI)]

Intaris -- I think it is just the way that the probe window floats over the BD.

sandyy -- you can set your front panel to be a floating window.

VI Properties >> Window Appearance >> Customize >> Window Behavior >> Floating.