Child classes influencing eachother?

[Jeffrey Habets]

Not sure if the problem I describe here is class-specific, but since it involves OO, I think this is the best category to put it in.

I use the design below to create child-classes that spawn a process-VI with a specific name (Thread.vi in this case).

This concept works as expected without any problems (we have 9 Station child classes running). The station threads are basically all top-level UI-VI's based on the JKI statemachine extended with the ability to be signaled externally through user-events.

In a later development stadium the need arose to have a second thread in one of the stations and to be able to switch between the two available threads while the application was running. At all times only one of the threads will be running. I implemented code for this and it worked as expected, as long as there was only one child class instantiated.

(What the new 'thread switch' code does is to signal the current running thread via a user-event to stop and then launch the other thread.)

Monitoring the thread's exec.state property shows that the initially running thread goes from 'run top-level' to 'idle' when calling the thread switch code (as expected).

Now, when there are more that one child class instances in memory (e.g. in this test-case I have one instance of Station 1 and one of Station 2) and I run the thread-switch code, the initially running thread of the class with two threads goes from 'run top-level' to 'running' state, preventing me from switching back to this thread. I'm a bit puzzled by his, and have no clue why this should be the case and thus think this could be classified as a bug. This is all LV8.6.

Any other opinions on this?

PS. I have a workaround in place, I'm just putting this up here to here your thoughts.

[MikaelH]

Hi Jeffrey

It's always nice to get a peak into your design solutions :-)

I guess you have 2 base class methods Thread 1 and Thread 2 that you override like this:

I tried the solution the way I would have done it, and it worked as suspected.

I’m using the GDS’s design pattern function to create a spawning process for every Station object.

In this process I call the Thread VI.

Have a look at the design and check out the video describing how Design Patterns in GDS works.

http://goop.endevo.n...DesignPatterns/

Threads.zip

Cheers,

Mikael

[Jeffrey Habets]

Hey Mikael,

It's always nice to get a peak into your design solutions :-)

Likewise.

I guess you have 2 base class methods Thread 1 and Thread 2 that you override like this:

This is an other way of solving this. I certainly keep it in mind for the next time I need this.

What I actually did is add an extra StartThread method that can be called from the childs. I only added the second thread to the child that needed it.

Why the extra method for starting threads? The SpawnThread contains some extra logic to wait for the thread to be in a specific state (and is hardcoded to only launch ThreadStub).

The other thread is started from the currently running thread like this:

When StartThread finishes executing, the VI finishes its loop(s) and goes idle (well, it should go idle, but it only does if I have not more than one childs instantiated).