ShaunR

It can be done but it: because: Indeed it does.

and what happens if you change this "prototype" refnum? Maybe? Everything else is guessing but you should post some code to show your use case like everyone else has.

There is a bug fix listed for 2017 for the following. 596804—Re-registering a dynamic event can cause subscribing event frames to behave improperly There are no details beyond that but I suspect the behavioural change is a side effect of fixing this-whatever it was

Yup. My fault. I've changed the quote and noted in the edit. It also makes hooovahhs objection moot; for which he can carry no blame since I subtly misquoted. The sentiment is unchanged. It's well worth watching from ~8mins through to ~12. I agree 100% with him and it is the reason I pulled Linux support for my toolkits that aren't pure LabVIEW - even though they do work on that platform.

Ahh. You are talking about panel/control/user refnums contained within an event ref? Yes they are. That still works as expected <2017 - either before the structure or inside it. There was no bug here to prevent this use case. evnt5.vi

Is it distributed as a lvlibp?. There is a bug (quirk?) in the TPLAT for packed libs that shows an invalid licence for the lvlibp but it still works correctly as a binary distribution.

I'm not sure what "use cases" you are thinking of. But changing the event event reference null and voids all the cases using it. It is a design time, type, decision and can't be changed on the fly. The only thing one can do at run-time is listen for or stop listening for events. It seems, however, that if you really, really unlisten (Unregister For Events) then you are now stuffed.

Or they could have just left it alone ;)

It is representative of what it is doing now, maybe, and not nearly as useful. Also yes. If it had worked like that for a decade and I had written code to leverage it, I wouldn't expect it to stop working one day. Notice too, how a shift register, like the event, would restore the behaviour? Lets be clear here. It's not a difference between 2009 and 2017. It is 2017 differs from all versions back as far as [at least] 2009. I thought I had set the time start. anyhoo..... Start at about 8 mins through to about 12 mins.

Correct. The behaviour has changed. It used to work similarly as I described (and to the DVR analogy). Now it doesn't.

Well. Listen to this for a few minutes It is my sentiments entirely and I get just as annoyed and frustrated as he does with this sort of thing.. I supplied a prototype (DVR ref constant) to the the initialising terminal to fix the datatype and then initialise the DVR (with Create DVR). From my perspective. This is the same as supplying an event refnum to the left hand dynamic terminal and then initialising (registering) the event which is passed to the right hand terminal. In this analogy. The feedback node is hidden under the hood which is why the new registration miraculously appears at the left terminal after re-registering. I think it is just a better analogy than a queue which is also hidden.

I didn't say everyone. I said I was not the only one. You may be OK with breaking interfaces because of anal specmanship, but I am not. Behavioural changes have an enormous cost downstream. It wasn't confusing at all and, to be honest, elegant and compact. Not so much now. You chose a bad analogy with queues. Just because there happens to be one, doesn't necessarily mean events should behave like one. A better analogy from my perspective is DVRs. Would you consider this a "bug"? dvr.vi For the purpose of the analogy, the feedback node is hidden.

If that were true, then in your example you would also need to pass back the refnum to the right hand event terminal for it to magically appear on the left hand terminal (as Smithd showed) or use a shift register as I did. You also don't need to "pass-through" from the left terminal to the right like you would if it where a queue in a case statement.....and lets not forget "Named Queues". I appreciate your argument but events are a category on their own and your solution still breaks dataflow, by your definition, The fact that they may use queues internally is a hidden implementation detail and kind of irrelevant. It may explain why a decision was made to change the behaviour but doesn't mean it was the right decision. To quote Linus Torvalds I know for certain that I'm not the only one that relie[d/s] on this behaviour. I think I learnt it from Jack Dunnaway in his events presentation. Rule #1. You don't break user space.

The register is called later (and should create the queue later if that is internal behaviour). Your synopsis doesn't explain why a shift register works, either since that should also fail. It also doesn't explain why the unregister all events is unrecoverable. It also isn't documented in the 2017 bug fixes, if it is a "bug fix". You have just found a work-around to yield to the new behaviour. I argue that they have broken compatibility, introduced complexity and anomalous behaviour-they broke user space which is rare and unusual for NI.

It intuitively should. It is not a null event reference. It is a constant event reference with a null user event refnum (but could be a panel, control or any other) which is obtained by right clicking on the event registration wire and "create constant". It is syntactically identical to the refnum created by the register function. You may argue that it is a "constant" and therefore immutable but that is a different argument altogether - especially when it has behaved that way for a decade.

Lets assume I have cheated to save space and complexity by using an event refnum and have inadvertently exploited a bug - which has been "fixed". Using your "technically correct method" should I not be able to register and unregister events at will? evnt4.vi

So you can confirm the change in behaviour between all previous versions and 2017?

There are several workarounds, one of which I highlighted in the example. The issue is that it is a change in behaviour from previous LabVIEW versions which breaks compatibility

That is static registration. Yes it is about the constant refnum which is required for dynamic registration. A real world example of dynamic registration might be registering for the mouse_move event only after the left mouse button has been clicked (register mouse_move during mouse_down) and then de-registering on the mouse up (e.g. moving a window when the left mouse button is held down). To achieve this one has to supply a prototype of the event (the refnum constant) to the left hand terminal as I have shown, otherwise the VI will be broken.

So. You can confirm the behaviour has changed between versions?

Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it. The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further). The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed. The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event. To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement. evnt.vi

The MDI toolkit uses a "container" to place the panels. In the example which is shipped with the toolkit there is also a limited area (below the controls) however it is transparent. The container area is defined by the "Create Container" VI. You required a more visible container. So one simply creates a VI with the required appearance and supplies the "Container" input of the "Create Container" VI with the VI reference. I used the attached VI to override the default container which is just a blank VI with a decoration. Untitled 2.vi Don't forget to also change the offset rect for the resize event otherwise when you resize the panel, it wont scale along with the panel.

Well. An area to place them is trivial. As for "we displace indicators and orders". I'm not sure what you mean. You can rearrange the window order, move them around, tile and cascade them, dock and undock. But you'd have to give more detail on exactly what you mean.

MDI Toolkit for LabVIEW? (shameless plug)

Hardly "rusty". Any software that is still at 1.0.1 after years of use is made of stainless steel People just don't know how to release fully featured and tested software any more. Users have been conditioned to think that software that is continuously updated and fixed can only be good when, in reality, it is a testament to how poor the design, implementation and testing is.