Build applicatio​n based on queue message handler template

Question

I programmed an application, using QMH template in LV and made a build out of it. The build has the "main.vi" and it is always included. But, after build is complete, the application starts by clicking on my apllication.exe and immediately terminate itself !!!! any idea about why? (I have one global function ("exit" which set to false at initialize state of the application" and shared variables, but both seem not the items to be blamed !!

Answer 1

I recently (about two years ago) started using the QMH fairly heavily, "re-inventing" my usage of it several times (that means taking a LabVIEW Real-Time project of several hundred VIs and almost "starting over").  I've attached a Demo Snippet to illustrate some Lessons Learned.
     First, an admission -- see all of those Queue wires?  I've gotten rid of most of them by using a Queue Action Engine that handles all of the Queue actions except Dequeue.  In place of the Obtain Queue, Enqueue, and Release Queue calls, I have a Message Queue VI that takes an Enum (Obtain, Enqueue, or Release) and (optional) inputs (such as the Element to Enqueue).  The only Queue wire in my diagram is the one from the call to Enqueue Initialize to the (necessary) Dequeue Element (but I don't need the Queue wire coming out of Dequeue Element as I use my VI instead of Release Queue).  Not only don't I need a Queue wire going into the parallel Event Handling loop, but I don't need a wire going into a sub-VI that needs to "send a Message", which makes spawning asynchronous parallel loops easy.
     You'll notice my Messages are Strings, not an Enum.  I'm a little conflicted here -- I like the "error-checking" feature of Enums, but especially when designing, it is so much easier to say "Hey, I need another State here to do this" and simply name it and add it.
     The Event Handling Loop, for the most part, should do nothing except generate a message, passing the Event New Value (if needed) as the Data part of the message.  In particular, the Exit message is just another Message -- it doesn't need to be "filtered out" for special handling.
     To stop all of the loops, I use a Local Shared Variable (you could use a Global or FGV/VIG as well) -- the TimeOut case in the Event Handling Loop wires this variable to the loop Stop, and as you can see, the Exit message sets it;
     You may notice the 500 msec timeout on the Dequeue -- this allows you to catch cases where no messages come in.  Here I "do nothing".  But you'll notice that this makes my Stop code work.  The User pushes Stop, generates an Event, calls the Stop Message, sets the Stop Shared Variable to True, but that (probably) does not stop the lower loop, as the earlier False value was probably read and "connected" to the Stop indicator when the loop was entered.  200 msec later, the Event Timeout fires, sees the Stop Shared Variable = True, and stops the Event loop.  After another 300 msec, the Dequeue times out, enters the True Case and does nothing, but now the Shared Variable is True and the lower loop stops.
     You are correct that if you want to do repetitive things with this model, you need to repeatedly call the State you want to run.  It depends how much of your code you want to put into a single QMH -- it might be just as simple to have yet another parallel loop do the same thing every 100 msec, and use the State Machine to handle the User Interface (I've done it both ways, depending on circumstances).
     Have fun!
BS