missing events if two event structures simultaneously listen to the same event

[Norbert_B]

Shane,

that is a good argument, though i point out that my approach is modular in a comparable way.

If i understand that registering you are doing correctly, you have to register within your new surrounding again on the event. So you have to "pick up an interface".

With my approach, using a new module would only need to pickup the appropriate queue/notifier (which is easy done by name).

The only situation, where my aproach definetly lacks is, if i chose to use a dedicated queue/notifier for each module. Then each new module would require the "construction" of a new queue/notifier in my mainapplication.

Nevertheless, the modules could be "standardized" as i only have to pass the name of the queue/notifier to them in order to pick up the correct one.....So the work has to be done in only one place, the reusability of the modules can be quite good as well....

Well, i think i see your point and the issue is answered by Bens link. Nonetheless, i am always glad if i can see examples from professional made software!

Norbert 

[F._Schubert]

Hi Norbert and Ben,

your discussion gave me some thinking and coding... 

Going the way with vit's or reentrant vi's spawned (which is a really powerful design pattern), I can either go the way passing the refnum and an exit event/refnum if using event handling or I pass a queue/notifier and a refnum if required (background color change) exiting the spawned Vis by releasing the queue. That seems a bit less effort using norberts approach.

In 7.1. I don't get value change events fired if I'm writing to the terminal of an indicator, so I would need a value signaling property node.

The event way is needed if my prime interest is not the value of the control/indicator, but any kind of mouse events. I used that to create my own popup-menus (right click event). The other advantage I see is that I can access the references in run-time via FP.Controls[] with my launcher vi.

I propably do some coding to clarify my methods tonight.

Felix 

[F._Schubert]

Ok,

here is my code, pics come next.

Felix 

[F._Schubert]

Here as pictures, there seems to be a max upload of 3 files.

 

 

 

Felix

PS: Please note, that this demo involves not the 'spawning' of vit's. It just focuses on queue vs. events. 

Message Edited by F. Schubert on 08-22-2008 02:43 PM

[Intaris]

I see in the examples that the queues or events are meant for one way communication only.

My idea was to do something else..... Like this example.  It's a pretty trivial example and is kept simple on purpose.  I usually have a queue or notifier for the communication TO the module, but I nearly always prefer pre-registered events for any communication FROM the module.  Reason is the ability for each event to have a different data type.  The other method via Queue or Notifier would be to either use many instances of queus or notifier, one for each "command" or use variant which I find a displeasing version.  OOP would be another solution, but many people are not yet comfortable with it, so it's often sacrificed for ability to understand the code.

I've simply visually separated the module from the main VI.  I would normally launch the background process via VI server......

Instead of sending control references to the module, it's also possible to use a series of user events for communication in both directions.

Shane.

[F._Schubert]

Shane, 

can you please post it as pictures as well... I've just old LV 7.1...

Felix 

[Intaris]

I'm not a fan of using pictures of a VI to show what I'm referring to.... (Event structures make for big pictures with different frames.....)

I don't have a version of LV to allow me to save back to 7.1, maybe someone else can do it for me?

Shane