What controls how many 'event data node' terminals are visible when an event case is created?

[Les__Bartel]

I created a new event case for a string control and was puzzled why several of the event data nodes were not visible. Only after lots of head scratching and hair pulling, did I finally figure out that I could resize the node block to see the "missing" terminals (duh). If I created a new vi with an event structure the desired terminals were shown by default. What determines which event data nodes are displayed when creating a new event case? Note, I did not add an event to an existing event case.

[Darin.K]

I have not examined this lately, but I seem to recall that by default it shows one less than the number of possible data nodes.  I have no idea why they would do that, it just seems bizarre.  Always showing one makes sense, two would be ok, showing all makes some sense.  Showing all but one gives you a sense that it is showing all of them, but without really showing all of them.

[Les__Bartel]

In my case it was showing 2 of the 7 or so possible.

[JÞB]

The Event you configure for the case controls what terminals are available for the data node For example Here is the help for the Drag Ended Event.

If no other events are handled by the same case Type,Time,CtrlRef and Result will be shown.  If the same case also handles App Instance Close CtrlRef and result will dissapear because it is not common to both events.  Source is never shown by default.

[Darin.K]

---

@Les__Bartel wrote:

In my case it was showing 2 of the 7 or so possible.

---

Were the two values shown with black text?  Every so often, usually when duplicating a case, the data node does not populate the n-1 available values.  It usually gets stuck showing one in black which is not valid for the chosen event.

As to showing n-1 nodes instead of n, I think the one which is always left out is Source.  I hardly use it so I do not mind so much, but on the other hand I hardly use most of them.  There are a small number of them which are constantly used and the rest end up getting in the way all of the time.

[Les__Bartel]

---

Darin.K wrote:

---

Were the two values shown with black text?  Every so often, usually when duplicating a case, the data node does not populate the n-1 available values.  It usually gets stuck showing one in black which is not valid for the chosen event.

As to showing n-1 nodes instead of n, I think the one which is always left out is Source.  I hardly use it so I do not mind so much, but on the other hand I hardly use most of them.  There are a small number of them which are constantly used and the rest end up getting in the way all of the time.

---

The ones shown were Mods and PlatMods. The text was pink. This was not a duplicate case.

[Darin.K]

Yes, there is in fact some funny business going on here.  I kept seeing it recently with the Mouse events (thanks for jogging my memory)

Create a String Control.

Create an Event Structure.

Modify the default Timeout Event Case to be String->MouseDown.  Change the Event Data Nodes to show Button,Mods,PlatMods

Add Event Case for String ->MouseUp.  Now you only see Button.

Add Event Case for String->MouseMove.  Now you only see Button, but it is invalid.

Edit:

I was able to find another pattern.  If you change the visible nodes for one type of event (say value changed).  All other cases you add to handle the same event with different controls will be created automatically with the same nodes visible.  So if you shrink the first one down to only NewVal, all new cases are added with only NewVal visible.  Seems like it was done on purpose, so it is probably a feature.

[Les__Bartel]

---

@Darin.K wrote:

Yes, there is in fact some funny business going on here.  I kept seeing it recently with the Mouse events (thanks for jogging my memory)

Create a String Control.

Create an Event Structure.

Modify the default Timeout Event Case to be String->MouseDown.  Change the Event Data Nodes to show Button,Mods,PlatMods

Add Event Case for String ->MouseUp.  Now you only see Button.

Add Event Case for String->MouseMove.  Now you only see Button, but it is invalid.

---

This is quite different from my situation. I have only one control/event for this particular case.

If I add an event to the case, the invalid data nodes are removed. If a node that would be invalid is wired to something, the text turns black, indicating it is invalid.

[Darin.K]

At this point I am guessing from somewhat vague descriptions.  Can you give a specific list to reproduce what you are seeing?

[Les__Bartel]

---

@Darin.K wrote:

At this point I am guessing from somewhat vague descriptions.  Can you give a specific list to reproduce what you are seeing?

---

I'm not able to reproduce it in a new vi, but here's what I did.

My vi had several event cases, including a 'value change' for a string control. I added an event case 'key up' for the same string control. The event data node showed only two terminals.