Re: Event structure, SubPanel Bug.
Otto et al. This is reproducible in LV 7.0 and 7.1 under MacOS-X (10.3.4). I guess the SubPanel is a method and therefore not ready for directly communicating its events. However LV should not crash hard upon this operation. It's a bug and should be reported. Happy wireworks Urs Urs Lauterburg Physics demonstrator LabVIEW wireworker Physics Institute University of Bern Switzerland Hi Everyone, Not sure if this has been discovered yet. I don't consider it critical because most people will not have reason to program like this but it will fatally crash without prompting to save your work. I was just playing around with SubPanels and the event structure (trying to programmatically move the SubPanel around in my main front panel) when I came across it. Procedure: -Create new blank VI. -Create an event structure on the block diagram. -Create a control (for example a string control) on the front panel. -Add event case for this new control (for example string-mouse down). -Go to the front panel and right click on the control (string) and replace with a SubPanel control. (Replace-Containers-SubPanel). -Go to the wiring diagram and click on the event case selector arrow. I get the following message: Fatal Internal Error: typemgr.cpp line 1025 I've seen this bug occur in LV 7.0 and 7.1 on Win XP. It will occur with other control types as well (not just string). It's been reported it to NI. This begs the question: Is SubPanel a method or control? It appears in the Control pallet but is instantiated as a method on the block diagram. Anyway, enjoy... otto CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at mailto:[EMAIL PROTECTED], and destroy the original transmission and its attachments without reading or saving in any manner. (1)
Event Structure locking front panel control
Hi All, I discovered something unusual (at least to me) about the Event Structure in a State Machine which I don't entirely understand. I've verified that it works the way I will describe below in both LabVIEW 6.1 and 7.0 (under Windoze XP). 1) Make a Boolean on the front panel (NOT Latched) 2) Make a State Machine with the following states: Poll, 1, 2. 3) In Poll, make an Event Structure with no Timeout and only one event: Boolean Value Changed 4) If the Boolean changes, send the State Machine to state 1 (I put Wait 200 ms in States 1 2) 5) In State 1, if Boolean = True, stay in State 1. If False, go to State 2 What I found is that I can get the code to go to State 2 just fine (I see it looping with the lamp on) when the Boolean is set to False. However after that, I cannot click on the Boolean on the front panel any more- it seems to be locked! State 2 was supposed to send the state machine back to Poll when the Boolean went True, but there's just no way to click on the Boolean. Emperically I guess this is the way it's supposed to be, but I don't understand why. My guess is that the Event Structure is somehow trapping changes to the Boolean and then freezing it but, again, I have no idea why this should be. I expect many of you will reply Why in the world do you want to do this (especially since the above logic probably seems pointless)? I'd prefer to put that question off for now. Suffice it to say that I needed this functionality and the only way to make it work was to no longer have the Event Structure track changes to the Boolean (the original program would go to State 1 for 30 seconds, unless the boolean was hit again before the time was up, at which point it would go to State 2 until it was turned back on when it would go back to State 1 until the full 30 seconds was up). So, to be slightly more concise: any idea why an Event Structure is locking a front panel control when the software is in a state in a State Machine in which it (the Event Structure) is not being called? Much thanks in advance for any enlightenment on this... E. Blasberg iDAQ Solutions Ltd
RE: Event Structure locking front panel control
Hi there, I tried out your problem and it does seem peculiar. At first I thought you were getting the anomaly due to you not placing the boolean control within the event state, but that wasn't the case. Observing what happens first hand, it seems to me the user interface thread is overloaded with user events that it simply locks the UI out. When a lockout occurs, it's simply LabVIEW (or the OS?) trying to limit the amount of events coming in from the UI thread. I learned about this back in the LV 6.1 days. Seeing your design work makes sense in my head why it would lock you out... And it's all due to user events timing... Too many get queued up before the Event Structure can handle them fast enough. Maybe you can consider placing the event structure in a separate loop? This might seem too much... But at least have the Boolean: Value Changed event trigger another 'mirror' indicator Status. Then, have State 1 review the state of the Status... This way, you're separating your UI from your Process threads and you shouldn't have a lockout state. Good luck! --- Juan Carlos Flores ArchonWest Technologies telephone: 888.824.2320 mobile: 323.620.1548 http://www.archonwest.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Blasberg Sent: Thursday, June 10, 2004 2:13 AM To: [EMAIL PROTECTED] Subject: Event Structure locking front panel control Hi All, I discovered something unusual (at least to me) about the Event Structure in a State Machine which I don't entirely understand. I've verified that it works the way I will describe below in both LabVIEW 6.1 and 7.0 (under Windoze XP). 1) Make a Boolean on the front panel (NOT Latched) 2) Make a State Machine with the following states: Poll, 1, 2. 3) In Poll, make an Event Structure with no Timeout and only one event: Boolean Value Changed 4) If the Boolean changes, send the State Machine to state 1 (I put Wait 200 ms in States 1 2) 5) In State 1, if Boolean = True, stay in State 1. If False, go to State 2 What I found is that I can get the code to go to State 2 just fine (I see it looping with the lamp on) when the Boolean is set to False. However after that, I cannot click on the Boolean on the front panel any more- it seems to be locked! State 2 was supposed to send the state machine back to Poll when the Boolean went True, but there's just no way to click on the Boolean. Emperically I guess this is the way it's supposed to be, but I don't understand why. My guess is that the Event Structure is somehow trapping changes to the Boolean and then freezing it but, again, I have no idea why this should be. I expect many of you will reply Why in the world do you want to do this (especially since the above logic probably seems pointless)? I'd prefer to put that question off for now. Suffice it to say that I needed this functionality and the only way to make it work was to no longer have the Event Structure track changes to the Boolean (the original program would go to State 1 for 30 seconds, unless the boolean was hit again before the time was up, at which point it would go to State 2 until it was turned back on when it would go back to State 1 until the full 30 seconds was up). So, to be slightly more concise: any idea why an Event Structure is locking a front panel control when the software is in a state in a State Machine in which it (the Event Structure) is not being called? Much thanks in advance for any enlightenment on this... E. Blasberg iDAQ Solutions Ltd
Event structure, SubPanel Bug.
Hi Everyone, Not sure if this has been discovered yet. I don't consider it critical because most people will not have reason to program like this but it will fatally crash without prompting to save your work. I was just playing around with SubPanels and the event structure (trying to programmatically move the SubPanel around in my main front panel) when I came across it. Procedure: -Create new blank VI. -Create an event structure on the block diagram. -Create a control (for example a string control) on the front panel. -Add event case for this new control (for example string-mouse down). -Go to the front panel and right click on the control (string) and replace with a SubPanel control. (Replace-Containers-SubPanel). -Go to the wiring diagram and click on the event case selector arrow. I get the following message: Fatal Internal Error: typemgr.cpp line 1025 I've seen this bug occur in LV 7.0 and 7.1 on Win XP. It will occur with other control types as well (not just string). It's been reported it to NI. This begs the question: Is SubPanel a method or control? It appears in the Control pallet but is instantiated as a method on the block diagram. Anyway, enjoy... otto CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at mailto:[EMAIL PROTECTED], and destroy the original transmission and its attachments without reading or saving in any manner. (1)
How detect key ENTER in Event Structure
I have developped a check password VI, with a text box and boutons OK and Cancel. It's easy to program the event structure when the user click on the OK bouton, but I don't know how to do the same thing when the user press the Enter key to validates his login. I think I should use the filter event on the ENTER key but how ?? thanks. Eddy
Re: How detect key ENTER in Event Structure
Argh !! I understand your solutions = so I can't use the event notification filter (on the right of the event structure) to detect this; OK. I have a little pb : I'm using LV7.0 and your example is written with LV7.1 = I can't open it... Could you save it in LV7.0 ? Thanks.
WHERE IS THE EVENT STRUCTURE IN THE FUNCTION PALLETE?
I am using LabVIEW Express 7.0 and I can not find the event structure inside functions pallete... I have used it so many times before and I know it exists but where exactly I can find it. It is not at the same place where the rest of the structures are (while, for, sequence etc). Thanks, P.C.
Re: WHERE IS THE EVENT STRUCTURE IN THE FUNCTION PALLETE?
If you use the express palette view, it will not be under execution control like some of the other structures. You need to go to all functions...Structures. There is also a second instance in application control...events. Of course if you bonly have the base package/b, you won't have the event structure (See http://www.ni.com/labview/how_to_buy.htm#compare ).
Re: WHERE IS THE EVENT STRUCTURE IN THE FUNCTION PALLETE?
Well I double checked all the places and it is not there. As the matter of fact, I copy-pasted the event structure from some other vi that I have built before and when I went on help for the event structure and then tried to find it by clicking the button that finds it in the function pallete I received the message saying Object not found. Then it says it might not be supported in the execution target currently selected. Then it says to go to OperateSelect Execution Target but when I went to Operate I could not find Select Execution Target option. My guess is that somebody did not install labview properly and few functions are therefore missing... I am gonna have to further explore what is exactly going on ... thanks for fast reply, P.C.
Re: writing to switches in an event structure from another vi
Alexi, I replied to your previous post about this problem: http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101RPAGEID=135HOID=50650008006DCDUCATEGORY_0=_49_%24_6_UCATEGORY_S=0 Regards Anthony Sims Applications Engineer NI-UK
Re: Having issues with using an event structure to detect value change
dont worry I have just figured it out. Thanks for your help it inspired me to find a new way of addressing the issue. thanks Alexi
Re: Having issues with using an event structure to detect value change
hi, thanks for the help. I need my vi to be able to do as you have shown me, except when I press clear I need the switches to automatically turn off. As is now I need to change a value of a switch to get the clear to take place.I would just clear the queue but I need to be able to change the value of individual switches and leave others on. My problem is that this vi is running in the background of other vi's so I wont access it much but will need to write to these switches. Do you know a way to do this? If the switches werent in an event structure I would just write to them with globals. thanks for any help, Alexi
Re: Having issues with using an event structure to detect value change
Instead of using the Value property, you have to use the Value(Signaling) in order to fire the event.
Improve event structure edit events dialog box
When control labels become long, the edit events dialog box has a slider at the bottom for scrolling to both ends of the text. The problem is, it fails to reach the end of the text so I have to guess at the control name. Also, it would be really nice to resize this dialog box to see more of the text all at once.
Re: Why timer anomalies in event structure?
Here's my first take on this: Unlike other events the timeout event will not que up and it will restart it's counting when another event has happened. The time value will be the time it is handled, not the time it went into the que as with other events. So let's say that there was a timeout at 10:00:00:000. After 300 ms you press the wait 200 ms button. The event returns at 10:00:00:500. Now the timeout starts running again and after 1000 ms it fires and is handled. Now however it's 10:00:01:500, and you calculate a delta t of 1500 seconds. This way the maximum delta t can become 2*Timeout+Wait time. If this is true I have some code that needs adjustment myself to work 100% correct; code that expects the timeout to enter the que and be handled even if the event structure was busy when the timeout occured.
Re: Why timer anomalies in event structure?
slaps head Well, duhhh.. I should have seen that. If it's 999 mSec into the timeout when the wait event occurs, then it will add 200 mSec to the 999, and start another timeout counter at 1199. If that one times out, then I'm sitting at 2199 mSec between events. Sometimes I can't see the forest for the trees. Thanks,
Re: Problem with stopping subvi in event structure
It would help if you would also post the sub vi
Re: Problem with stopping subvi in event structure
When you add or edit an event structure, there is a checkbox in the lower left hand corner. The defualt is checked, which will lock the front panel until the event is finished. Unchecking it will allow other event cases to be called even before that case is finished.
Re: Problem with stopping subvi in event structure
Your problem has nothing to do with the event structure. When you call a subVI statically, you pass control to that subVI and while it's executing, the main VI can do nothing. It's the same thing with text based programming. Call a function with an infinite while loop, and the rest of the program stops. The solution is to call the subVI dynamically. You can use an Invoke Node to open a front panel (if you want it visible) and then run it. There have been numerous examples of dynamically calling VIs posted to the forum and available on NI Developer Zone.
Re: Problem with stopping subvi in event structure
Actually, You can do this with an event structure. If you uncheck lock front panel until the event case completes, the event will start the code and return to the main program before the vi finishes. It won't respond to the same event (if you trying, it seems to stack them up and will execute when it finishes), but you can call other events.
Re: Problem with stopping subvi in event structure
Thanks. Learn something new every day. Never tried the lock panel unchecked before.
Some frontpanel controls stop firing the Event Structure
In my main vi,I have an event structure. I created a subVI that also has an event structure. I load the subvi via a subpanel in my main vi. It runs fine for a while. But sometimes after firing events on the subpanel, most but Not All controls on the main VI stop firing the Main Vi's event structure. The Subpanel's subvi event structure always works fine. When I reload the program it works fine again for a while.
Re: Some frontpanel controls stop firing the Event Structure
This sounds to me like your two event structures are stepping on each other. Maybe try increasing the timeout value in the one event structure or by placing a wait in your subvi. This might free up the top level application to read events. Try posting an example of your code. This might help diagnose the problem better. Hope this helps.
Re: Some frontpanel controls stop firing the Event Structure
Thanx, I tried your sugestions but it still had a problem with some of the main vi's controls. I did some more experimenting and found that the 'mouse down' on my subpanel's control(a table) would cause my problem to happen. I created an event case in my subpanel's vi for the mouse down and set the Discard? to true. Everything works well now. I think it is an internal labview problem because only some of the main vi controls(buttons) would not generate the proper events.
Re: Event Structure recognises clicks on diasbled buttons
Hi, In LabVIEW 7.0, mouse up event is still queued on the event structure even if the button is disabled. This is expected behavior. The rational for the mouse up event is you can still want to know that you have a mouse up event even if the control is disabled. All disabling should do is not allow you to do a value change. On the other hand, the value changed event should check to see if the button is disabled, but not the mouse up event. Feroz National Instruments
Re: How can we change the name of dynamic events selector label in Event Structure
I agree! I can't top this approach. Ben
Re: How can we change the name of dynamic events selector label in Event Structure
I have used dynamic events a bunch and I do not thing there is a better way to do this. Your VI is an excellent example!!
Event structure with FieldPoint
Hi All, Can I use an event structure in a VI that is to be downloaded and run on a Fieldpoint FP2000 module? Thanks, Neville Dholoo Cellex Power Products, Inc.
RE: Event structure with FieldPoint
Sure, but it has to use dynamic events (LV7) to trigger the event cases. Standard event triggers such as button presses, key presses, etc will not work due to it being embedded in the fieldpoint unit. You can use buttons, etc. on the front panel of your embedded vi for debugging purposes, but when you disconnect you want a way to remotely trigger the events; dynamic events do this nicely. There might be a way to use vi server to remotely change the value of a button and thus triggering an event, but I haven't tested this method. Eric Scott -Original Message- From: Neville Dholoo [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Event structure with FieldPoint Hi All, Can I use an event structure in a VI that is to be downloaded and run on a Fieldpoint FP2000 module? Thanks, Neville Dholoo Cellex Power Products, Inc.
Re: Event structure
--2153655.1076616571558.JavaMail.quiq.tekken Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When one of the subvi is running, the event that fires the subvi will not be finished until the subvi is stopped. To overcome this, you can dynamically load the vi using vi server (check the snapshot for this. Note the vi path need to be the path to your vi). Joe --2153655.1076616571558.JavaMail.quiq.tekken Content-Type: image/gif; name=Snap7.gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Snap7.gif Content-Description: snap R0lGODdhlwF7AOMAAOTuxAQCBOzu7AR+BPz+/Pz+zPwC/AR+fARmZAAA ACwAlwF7AAAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhYaH iImKi4yNjo9SAZCTjZIilgCYlJucFpianaF5n5kVkgGoE6iWq6eZqaKxdKSgsKUUrKqksrxwrreq uKYSu8S9x22/tcKvsMXAyNFmysPBu8+g0tphz9C/t9jb4mLdrZ+rut7j62jZLObw8fLw7PU57isB Bfv8/f7/APfhizSvoMGDCBMqNGjPiL6AECMK1PJQosWLGDNqlDiwIY+K/hsjdoRScVXIkyhT8jO5 0uOJAzBjypxJEwNIfwr/jXxSsgAqlUCDcvRZ0qUJmkiT2oSorylRnTqTSp1KtapVqj1ZihTKNWPT nz6vih1LFukemATSql3LNi3MpQF/Or3pUyfFlXg50k2ZFWzXnj6pHDh7gACCwwjatn17Ya/Aul+h 4rz7uLJIxycBY+abdyeSwXrQJjasmC1jT0zn1sVpN0vJVv0iw+OquetK2IGngM4jOu3o0m53m2IK +Snrya4typ4t1Kll262lCL8jGjFwtaeHx1VNtzvlrXLN/V1NHjpy6YTX/gYek0B7mJhznr+y+bJt 5+XNt9SdXu360jO5/odWfJLFFh19txln330GQhfeRPyFVphv1rE3nSrEHddgbCkY4OGHIIYo4ogk lggiSJEN5eBt9WVmXAAmxihjjChcWAdavuVoIVwAdVfgfid8mJaHQxpQ5JEEEJmkkUsiqeSTTL6m oH5UXvSgT1A6yWSWTXbJJZEG1NgfaWQCaGMmGW6YF4cozOjmmyNq1mKVdD4EFoxw5klikmJK6F+F ZvL443OE5hYknz3MSeeiyuXwYZ+8TXidaWcSqOGaQJpgZJiJdqYooyu+6KiHkOKB46RrZYdLaggd WMKjnYIqa0iesbBpqdSVpSqGDnZIaqILBSvssMSa4yiiRxGmq6A4/iXkKgm3JorqtNRWa+21itW6 AqyXFFtQH/WpNuWzI0T7EbbopquutdqqwG0In3oFLos3zYVfj75yeu66/Pbbb7sdIguveQCzYefB l/qFb5u/7uvvWq1gG4BaE6/ycFsFH6rvwL3ygfC4Cm6WsQXm7jDxxRSnzK7KJ6NM8agbgxAvRiOn 8bHCsd1Lrggl69Ayyi2fHDQBEUPMsssQw0zCzFbO+6Jj4sWVrw8/Xzw00SlfnbXKSBN9bMwfMN2o xwJ9rBNuPeppItVdF411WhVzDffbdCNdM7QCy4yXuJ0VV6/TROFM65dbFq5l3ve0PffiWGs9t+Mu 311uwxxfSZ6d/mPvITZHapfItt1HPy4343VHrvQIKKYJVVFkd4xF1Q//LLTFkNNtcdtfL112yH0/ Jq7k03g7D0VdF487Dj2HvXdxhWKOolFMwG789OoCH8K7el/eO/P2Qgh9EtJTLz67p19i5dnMe/99 CQO07/778McPv03C12+/8LmjbllWxKVoPfTyC6AA22cTARjwgAhMoAIXyMAGOvCBEIzgAf/3geR5 gH/O2Qt3MrW+EbRvXQRsjARHSMISmlCCFPQA9pTnug56cACTGiABQuiJE9pwhANgYA5vyMAUdmCF FySYC9kHw7TA8IhqcR9bPkhDUzxwhwKAIhQRmMMpSlCKUdQh/g97mD/ztXCIIPjgEteixBm+z4wF dCAWDWhFKprQim1k4xYX6EMOWLADimKO1MAoAjEmcYl+NOMRB5DGAGhRjoh0nxwVeUAsvo+N7csi HBlJSUZGMZIQrOMGgIhHmrGIKXzsYxHJSEYxwk+QM0wlDA0pAFRosYpZTCAs2+jIRsZSkm5cpC1r iUgHalIDnORAHvcGtVCGIJCpLGURT9lEXBjQlQuc5S0fCUtZ7vKaurRlNnG5yEc+8JcZuKMw6dUj ci7MmB5AZjKNaMozNlMVz2ygNHdYS1pik5v4nKY+eYnCLlbObJgqlPrQuQF1AjKAaBQhBNe4z1tq E5/VzCc//iNK0UyW759buRSbCMoBg1brncSIIEMvGUl6TrKk2kTpSU1Kz5Ri8psXzZ7g1CRQQ3FU AwPM6fwUOsee+rSE4MSAODcA0EHlh4M3vYBOl0pInv70qVCl49c6dzMfaRSpSb0BK6PKVa4G9QJC 8pLhxPqamcpjj1nFAFN1Sr/7ufWtCIEZVYWYVrWudYBp7Kpef/rVFmxOJHW1KwibWsO9GnaOfX0H XG0RWAowUYAxJKwTD0vZJ8YxsY2NwmPb4kckjhKkmYhmHHspT0uOdo7ejGYDMZvZJzy2nYEcZRIl 60wFvtS2C31oV0eaS6m2dg6vXWYZVQnIQqa0l1XEpCVJ/ltNRabWtMq9rT4hyVLf/jYOwWVnbDnr WVWyEpotbShye4vLKU7UoSNdIz8VyNrrLiG7gvysYkD7XVaG97zMdWNyH1rRl8KPitB17mrdi91B wla2smWncUkq4G2mV7+N7C9/I2rN6eo2ge0lMBKCG7/I5jW/+EXvce9ZURL3Nrz5xLCG3+BRatG3 womsJHVlaVqSUleK0cUxHHNJyQGvuA13xatTK3thIiMwwz8mQpAF+GEjO9TJE0yyI7YK5SqzV8qV WKyWt8xYLHv5y2AOs5jHTOYym/nMaE6zmtfM5ja7+c1wjrOc50znOtv5znjOs573zOc++/nPgA60 oAdNFuhCG/rQiE60ohfN6EY7+tGQjvSjIwAAOw== --2153655.1076616571558.JavaMail.quiq.tekken--
Re: How do I call another event from the current event in an event structure ?
I don't believe though that the other event will actually execute until the first one completely finishes. Even if you use a sequence to call the other event. The other event's timecode will indicate when it was called or placed in the queue to be executed. Note this behavior is different than other languages (Delphi for example) where a second event can be made to execute at any point in time from within another event. Steve
How do I call another event from the current event in an event structure ?
1
Re: How do I call another event from the current event in an event structure ?
You need Labview 7. 1) using dynamic event or 2) using value (signal) as an event condition. any changes to the value will signal the event -Joe
LV7 Event Structure - Vkey Enum oddity
I have this problem on ONE LV7 machine and not another. I dont mess with LabVIEW.ini to see how this can be but . I cant get the Event Structure Vkey from the Key Down Event to connect to a Vkey in an cluster Or to even have it connect to an indicator!. (The cluster is prototyped correctly) Do the following: 1. Drop in an Event Structure, Add Key Down as an event. Right-click on the Vkey output node and Create Constant 2. Drag the Vkey constant outside the Structure build it into a cluster. 3. Pass the cluster into the Key Down Event unbundled by name and try to wire the Event Vkey value into the cluster. 4. I get a broken wire and an Error Enumeration Type Error the Enum type must be exactly the same. 5. Disconnect the cluster from Vkey Right-click on the Event Structure Vkey node and Create Indicator when I wire the indicator I STILL get a broken wire! This code works in LabVIEW 6.1 just fine. Jack Hamilton Hamilton Design [EMAIL PROTECTED] www.Labuseful.com 714-839-6375 Office
event structure bug?
I'm not sure if this has been posted before (about 4400 hits came up for event structure bug): Start with a blank VI, drop an event structure, add dynamic registration terminals, add and wire register, unregister for events. Next, drop two create user event vis and wire a plain boolean constant to each (that's one per create vi), then name each (e.g. bool1 and bool2). Wire the create event outputs to register for events. Now, go to edit the events handled by the event structure (should be timeout by default), select the first user event (instead of timeout), then add (as a second event) the other user event. Click OK, then voila! The first user event you chose is listed twice in the event case heading (bool1,bool1 for the naming above). Also, if you try to resize the Source, Time, Type terminal, the vi breaks (non-executable). If you try to re-edit the events for the case, only the first user event is listed. --Omar (I still think User Events are pretty cool!)
