Dr. Damien's Development - The Xylophone Project IV - Core Architecture

[Ben]

I am plesently pleased to find that other may feel the same way about name spacing.

I started another thread here to discuss the Name Spacing Standard and if the LV community should adjust it standards.

If you have comments re: Name Spacing please use the other thread. 

Thank you for your thoughts!

Ben

[F._Schubert]

Finally found the time to look at the code. Some points I'm unsure about, maybe there have been some changes as I still mainly work with old LV 7.1.

* The Application Instance Closed Event (It was called Application Exit in 7.1.), should I really discard the event? I found that shuting down my program with the task manager nicely fired this event and I could perform some cleanup code. When I had more than 1 Event Structure active and all registered for that Event and discarding it, only one of these structures actually got it, so the others did not exit at all.

* Putting the Enqueue commands inside a case structure seems unnecessary. I did at first when using event structure, but I don't get two events using latched booleans but only one.

Felix

[DFGray]

Felix,

1. You really want to discard the Application Instance Closed Event so that it does not instantly shut down the application without allowing cleanup.  Since cleanup is not done in the event structure due to multiple events triggering the same cleanup, the event must be discarded.  Of course, you have to do the cleanup and exit and ensure nothing hangs in the process or you can seriously irritate your user.  In addition, you should never have more than one event structure in a VI or you run into the sorts of problems you just mentioned.
2. Putting enqueue commands inside case structures is not currently necessary.  However, I have found that booleans tend to occassionally change mechanical action due to changes in GUI function.  By writing them in this manner, I prevent future issues.  I tend to code in a fairly conservative manner, so this is a personal preference (like the synchronous UI loop discussed above).

Thanks for your comments!  I should get the next installment posted this week.

[tst]

---

DFGray wrote:

In addition, you should never have more than one event structure in a VI or you run into the sorts of problems you just mentioned.

---

I disagree with this. There are cases where you want more than a single event structure. The key is just knowing the caveats (e.g. filter event behavior, dynamic event registration).

[tst]

---

F. Schubert wrote:

should I really discard the event?

---

Yes. This behavior is documented and logical - when you discard an event, the rest of the event structures don't get it (why else did you discard it?). What you should do instead is create a stop user event which all structures will register for and fire that event when you finally decide to stop the program. Then, only your UI event structure should register the app instance exit event.

[Ben]

---

tst wrote:

---

DFGray wrote:

In addition, you should never have more than one event structure in a VI or you run into the sorts of problems you just mentioned.

---

I disagree with this. There are cases where you want more than a single event structure. The key is just knowing the caveats (e.g. filter event behavior, dynamic event registration).

---

I both agree and disagree (with who!?!).

I will often have more than one event case but one or the other gets pushed down into a sub-Vi to keep the top level VI clean.

Ben

[F._Schubert]

I did check with LV 7.1., and this behaviour is NOT as expected/documented in Developement Mode. In an exec the code outside the event is not executed, but in development, the clean-up code outside the event IS executed. I based my point on that experience, and I'm happy to know that issue now and can correct my code, otherwise I would have run into problems with my exec.

Felix 

[tst]

---

F. Schubert wrote:

In an exec the code outside the event is not executed, but in development, the clean-up code outside the event IS executed.

---

I'm not sure what you mean by this.

What I meant was that when you have a filter event registered in several structures, the event passes between them in the order of registration and each structure has to finish processing it before the next structure can start. If one of them discards it, it disappears. This appears in the documentation for 8.6 and if memory serves, it also appears in 7.0.

One thing which would be interesting to check is what happens if we have an event structure which registered a filter event, but which never gets to execute. Does that mean the event will get "stuck"? My guess would be yes and maybe that's what you're seeing.

[F._Schubert]

The second dialog should not be executed. It is not executed when I build an executable. But it is executed when I'm in the developement system.

 

This did mislead me to not use the filter event, discard it and send a stop event to other event handlers to have all clean-up code executed.

Felix 

Message Edited by F. Schubert on 03-17-2009 06:23 AM

[tst]

I think you have a race condition. That event is fired when the "entire" application is closed. That means that the code will be stopped regardless of what you do. You just don't know when it will stop.

This is why I use filter events for things like this (e.g. Panel Close?) and then discard the event. If your code is running, you should discard the event and handle the shutdown yourself.