Jeffrey Habets

I've got my ticket in too (Euhh, I lost money through paypal, I guess that counts as a ticket in. ) Transportion would be nice indeed, it seems like quite a walk.

I like the Idea! This is something that has always been on my mind to do internally, but time never permits. Making it a group effort is a good idea. I'll be happy to throw in my where-ever I can, as time permits. I'll be at NIWeek this year btw.

This is pre-LV2009 behaviour.. You probably should check this setting in your build specification: It should be unchecked.

I like it very much.. Now the RSS feed is usable again in Firefox!

I just ran your benchmark code on LV2009SP1 and indeed see that calling the static method is about 10x faster than calling the dynamic dispatch one. I backsaved to LV8.6 and ran it there, now calling the static method is only 2x faster. Mind you, in both version of LabVIEW the dyn.dispatch was about the same speed, but it seems static calling speed has improved in LV2009.

I released a new version: http://decibel.ni.co...t/docs/DOC-6771 Due to lack of spare time it's only been tested sparsly under LV86, but I didn't want it to ly around for to long here since it's more usefull than the previous version imho. So I'm very interested in any feedback on problems that you find, especially under LV2009 and up.

Hey Mikael, Likewise. 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).

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.

There is no need to store the ref each time you switch the run-mode. Just write the ref ones to the state data, there are several ways to achieve this, here's one example: As a matter of fact you could do this in either of the four "... Change" states since they all get called when the XControl is instantiated.

Congratulations Chris, to you and your family!

The idea is not to create a unique user event for each listener, just store the user event ref on the first call to GetUserEvent and return the previously created refnum on all subsequent calls. Each observer registers it with it's own reg-events node. As for the observers being able to destroy the event ref, I see your point, but in general I second Ton's statement: 'delete what you created, leave what you received'. Also: Document your API well and your users should be OK. And in the case your user doesn't read the docs/description, make sure errors are propagated correctly when attempting to generate an event.

I wouldn't be to sure about that.. In my understanding the queue exists at the event registration refnum. This is also illustrated by the LV help that states you shouldn't wire an event registration ref to more than one event structure to prevent race condition situations. So in order to have multiple observers observe you, you have to either publish the event refnum or a unique event registration ref for every observer. Practical in your XControl (or class or whatever code module you want to make observable) you have a finite number of possible dynamic events that you can send and they all serve their own purpose. I'd simply put them all in an event-ref cluster inside my internal data structure. No need for putting them in arrays imho. (It would be the same as wanting to stuff several different clusters in an array... which ofcouse is possible using variants classes.. )

I'd probably go with creating the event ref in the property node when it's called the first time, all subsequent times you just return the previously created ref that you stored in your state data. Although in the past I've used the concept you suggested in option A in some of my classes. It does create a 'useless' ref until someone registers for it, but I doubt it takes up a lot of resources since the actual event queues are created when a listener registers for the event (I guess..).

Congratulations Jim! And congratulations to Lilah.. You've picked some fine classes to inherit from.

You're right.. You need class wire input on the constructor for the childs to be able to call the parent's constructor. I should have said I just never connect the object constant to the constructor method, simply leave the class input terminal unwired. I don't really mis the ability to be able to force it, but I agree it would be nice if it was possible. I wouldn't want the code to be run as part of the cube-constant though, it wouldn't feel natural.

To prevent this confusion I never use the object constant on the BD to 'create' objects.. Basically all objects are created by explicitly placing the constructor method on the BD. I should note I use by-ref classes for the major part of my designs and they come naturally with a create method for construction, but for by-value classes I use the same paradigm. The constructor typically has no input terminal for the class wire. For most LV users using a create-destroy paradigm is quite natural since there's a lof of that already in LV (instrument I/O, file I/O, Queues, etc..).

Hmmm, I think this would make LV a bit to artistic.. Well, at least it's good to here that some people at do NI thinks about usability of features.. I have to agree with some comments made here, something is always better than nothing at all.. It's very cool we've got the native classes, but it's simply to much of a hassle to work with them out-of-the-box. There's always been a lack of usability features for classes and to be honest, if it weren't for Endevo's GDS, I doubt I would be using the native classes today (or I would at least have build some wizards myself..). I'm a bit surprised NI didn't just let this feature make it into the release (or at least in a beta release) and let the users give feedback on it. Indeed you'll probably get a lot of comments as you also did get internally. These should then be considered very useful input to consider what should be changed and/or configurable for the next release. So now.. Will it come back in 2010 or should I just keep on coding?

This was in version 8.6.. I just checked 2009 and have to confirm they now look the same.. Looks like this little gem of a hack is broken in LV2009.

For all who don't see the difference, here's an example comparisson: It's very subtle, but it's there.

I think these two are the ones that AQ posted originally.. (I safely tucked them away in my svn repo. ) I think these are saved in 8.6. TopLeftBorderOnlyCluster.ctl OnePixelBorderCluster.ctl

I posted a new version of the Class Tool with some improvements to the menu and it now also shows methods of ancestor classes.

Yep.. Keep monitoring that page.. :-)

What I'm trying to do is get a list of all class methods of the selected wire.. I'll populate the right-click menu with this list so the user can do a quick drop or insert of a method of the specific class without having to browse or going to the project. If it's documented, it's very well hidden.. I wasn't able to find it either. Anyway, thanks for the insight, it was very helpfull. I now simply run the sub-vi containing the pictured code via a call-by-ref in the application context of the VI it's operating on and just return the class-path and wire ref. Jeffrey

Hi All, While writing a RCF plugin I bumped into this problem which I was also able to reproduce outside of the RCF framework, so it's probably not a framework issue. The piece of code shown tests a diagram's selection list for class wires and returns the wire ref and class path of the first class-wire found. This code works whenever the VI that it's operating on is in the main application context. When I have opened the same VI from within it's project, the variant to data function returns error code 91 (The data type of the variant is not compatible with the data type wired to the type input). However the datatype in the variant is under both circumstances exactly the same. Also, after the error 91, LV becomes instable. Doing edits in my script-VI or even just saving it gives me an fpsane crash on line 432. Your thoughts please? Am I looking at a bug here? Jeffrey