LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV6.1 Wait for Front Panel Events, Good but not enough

I would like to voice both my appreciation and complaint for the new 'Wait
for Front Panel Events' vi in LV6.1. This vi can take a front panel
reference as an input thus allowing one vi to determine if activity has
occured on another vi. That is GREAT! but would it not be even more
exciting if it would return a reference and type of the front panel object
that had generated the event? I am curious to know if there was some sort
of technical hurdle in providing this extra information or just that the
developers did not think it was valuable enough.
0 Kudos
Message 1 of 3
(2,600 Views)
> I would like to voice both my appreciation and complaint for the new 'Wait
> for Front Panel Events' vi in LV6.1. This vi can take a front panel
> reference as an input thus allowing one vi to determine if activity has
> occured on another vi. That is GREAT! but would it not be even more
> exciting if it would return a reference and type of the front panel object
> that had generated the event? I am curious to know if there was some sort
> of technical hurdle in providing this extra information or just that the
> developers did not think it was valuable enough.
>


The node is meant as a quick way of making already written front panel
intensive VIs be able to have a reasonable wait amount, but
automatically waking up early if something occurred. It wasn
't meant to
change the way the program is written. That is what the event structure
is for.

The problem with returning additional information the way you mention is
that it would be incredibly generic and would make writing the rest of
the program way too difficult. That is why we created the structure.

Greg McKaskle
0 Kudos
Message 2 of 3
(2,600 Views)
It would still have been nice if the wait on front panel event would return
the name of the object that caused the event. That way you could at least
get its value without having to poll every object or see which object the
mouse was clicked on (which is the way I am currrently doing it). The use I
see for this type of interface is to be able to create server vi's that can
monitor and process events that occur on client vi's.

"Greg McKaskle" wrote in message
news:3C535F25.4050901@austin.rr.com...
> > I would like to voice both my appreciation and complaint for the new
'Wait
> > for Front Panel Events' vi in LV6.1. This vi can take a front panel
> > reference as an input thus allowing one vi to determine if activity has
> > occur
ed on another vi. That is GREAT! but would it not be even more
> > exciting if it would return a reference and type of the front panel
object
> > that had generated the event? I am curious to know if there was some
sort
> > of technical hurdle in providing this extra information or just that the
> > developers did not think it was valuable enough.
> >
>
>
> The node is meant as a quick way of making already written front panel
> intensive VIs be able to have a reasonable wait amount, but
> automatically waking up early if something occurred. It wasn't meant to
> change the way the program is written. That is what the event structure
> is for.
>
> The problem with returning additional information the way you mention is
> that it would be incredibly generic and would make writing the rest of
> the program way too difficult. That is why we created the structure.
>
> Greg McKaskle
>
0 Kudos
Message 3 of 3
(2,600 Views)