Daklu

As a general rule I always put subvi controls and indicators on the top-level diagram outside any structures. I believe that usually results in the most efficient compiled code. In normal looping situations with n loops option 1 will typically outperform option 2. In option 2 every loop creates two additional copies of Data In for a total of 3 copies; one for the front panel control, one for the wire, and one for the front panel indicator. (Note: It will do this if the front panel is open. It may not if the front panel is not open... I don't recall for sure.) However, since this loop always only executes once logically it shouldn't make any difference in terms of memory allocation and data copying. Another thing to look at is using for loops instead of while loops. I read somewhere that a for loop with a constant 1 turns out more efficient code than a while loop with a constant TRUE. IIRC the compiler doesn't recognize they are functionally equivalent and still executes a check at the end of the while loop to see if it should continue.

Or create anything near the edge of the structure. Or when you change a typedef and all your typedef constants reset to 'align vertical' and your structure grows to fit?

Thanks for the clarification AQ. I admit that once I understood what you were saying (it only took a dozen reads) my immediate question was "so what?" I didn't see how it would have much impact in real world applications. I mean, sure it violates the absolute principle of encapsulation and it could cause some odd bugs in obscure corner cases, but is it anything to get alarmed about? Probably not, because in your example Class B (the parent) code was modified to violate Class C's (the child) defined interface. It appeared to require injecting a rogue class into the inheritance tree. Then I read gb's comments. Now... it may take me a bit longer (okay... a lot longer) to get all the way around the block, but eventually I'll get there. I started wondering if this could be used to exploit released code. I rigged up a simple class hierarchy with a Textbox object and Password object. This is certainly not a good example of secure coding practices, but it surprised me how easy it was to break into the Password class even though I didn't modify the Textbox or Password object in any way. Yeah, me too. Password Hack.zip

Can you explain what you mean by 'destroying the data integrity of your D object?' I wired up a simple project to try and follow through the different scenarios you described and I didn't see data internal to D get corrupted or reset. Class Spaghetti.zip I'm far from an OOP expert so I may be way off base here, but that inheritance structure strikes me as odd. Class A is your GenericMeasurementObject and Class B is an array of GMOs. Doesn't that violate the "Class B is a Class A" rule of thumb for inheritance? What you're describing might work but I'm concerned your path will lead you off into the weeds (having spent much time there myself) with an application that is difficult to maintain or expand.

Isn't every day beat up on crelf day? No? Maybe it should be... (Think of how high your post count would get responding to all those comments...)

So is there a preferred way for a class to expose events to subscriber vis? Here are a few options I've considered but I'm not sure of all the tradeoffs associated with each. Exposing a User Event - Easy to implement for the class developer, but forces the caller to handle all event registration duties, probably leading to duplicate code if events are registered in more than one place. Since user events have data types associated with them it could be harder to implement this is a complex class hierarchy. Exposing a Message Queue - Aside from the UI polling issues, this seems similar to exposing a user event except it 'feels' like it would lead to more tightly coupled code. Different classes may have different message types. Event subscribers would have to implement separate event loops for each class. Accepting an Event Registration Refnum - Have the class expose Register and Unregister methods that implement the prims. Event subscribers pass an event registration refnum to those methods. I think I would prefer this implementation except calling Unregister for Events removes all events from that refnum. The class has no way of knowing what other events are registered to that refnum, meaning the event subscriber has to implement bookkeeping and auto-reregistration routines. Accepting Callback VI Refnums - Same idea as the event reg refnum except the subscriber passes vi references to the registration methods. When the event fires the class automatically executes the callback VIs. The problem with this is I haven't figured out a good way to pass data with the events. If I invoke the callbacks using a Call By Ref node the callback has to finish executing before the thread returns to the class. When multiple callbacks are registered for a single event one poorly written callback could significantly delay (or prevent) other callbacks being executed. Maybe the answer is to require the subscriber to query for data after the event...Any other ideas?

In some cases it is possible to deduce which threads are performing certain actions. Looking at PE, the highlighted thread and the 15 others with the same name are the user threads. If you monitor this you can see which threads become active when you start a new parallel loop. It might be possible to identify certain LV primitives by examining function offsets on the thread call stack, although that would be a lot of work since the call stack is a snapshot and there's no guarantee the thread is executing that prim at any given moment. It's also not always obvious by looking at the bd when LV will use one of those threads. A spinning loop uses one thread, but a spinning loop with a wait prim uses two and occasionally kicks in a third. Is this is the 'UI thread' often talked about on the forums? I've never quite understood if they meant the Labview UI, the VI UI, or maybe even the Windows UI. I'm also curious about the who does the user thread management. I take it LV is responsible for deciding when to invoke one of the threads from the pool. Does LV also manage all of it's own thread switching? Does the OS get involved in LV threads or does it stay at the process level?

What's amazing is the high ratings the book receives on Amazon. I had to laugh when I read this reader review...

That's true, the OP didn't say his VI was broken, only that 2 VIs causing the problem were hidden. Although even in that case execution highlighting should have revealed the VIs. I did have an issue recently where some VIs in a diagram disable structure's disabled case were causing project file links that shouldn't have been there.

Thanks Jim. I didn't figure JKI would pull the license but it's nice to have reassurances.

Actually I do use the autotool - betty. (I started with LV8.2 so I never got used to tabbing through the tools.) If so, it should have been easy to find using the Show Error button on the Error List dialog.

Omar, one of the reasons I haven't pushed VI Tester more internally is because it's unclear what JKI's future plans are with it. The way I read the license it appears that JKI can revoke permission to use the tool at any time and instead sell it as a commercial package. I certainly wouldn't fault JKI for doing this. VI Tester is very good software and JKI certainly deserves to be compensated for your work. However, building and maintaining a suite of unit tests is very time-intensive and I'm hesisant to invest that much time in a tool that might be yanked out from under me. Can you share JKI's future plans for VI Tester? There are a couple ways I've dealt with testing modules that interface with hardware: Do write/read combinations--send a command to the hardware and read back a value to confirm the command was received. Technically this violates the unit test paradigm as it requires the hardware to be connected during testing. It also doesn't work for all commands, such as commanding an LED to blink. Use a dialog box to ask the user if the command worked. Obviously this also violates the unit testing paradigm. Not only does it require the hardware be connected, but it requires a user to be present. Still, it's better than no testing at all and doesn't need to be run every time. Create dummy objects that represent the hardware. This is the preferred way of doing it. It does require a lot more time to implement though. I fully agree more discussion on software engineering is needed. I think that is too broad of a topic for a single forum though. SE includes Application Design and Architecture, OOP, User Interfaces, Source Code Control, and Code Distribution, just to name a few. Each of those topics rightly needs its own forum. Maybe if tags were used more it would be easier to find threads discussing SE principles?

Nailed it. I hate autogrow. I've spent far too much time rearranging block diagrams that autogrow (and various other 'features') has screwed up. Well that's no way to engage in a flame war. I'm curious... exactly what error were you seeing from having vis in a diagram disable structure?

I'll second Labview for Everyone. There aren't a whole lot of Labview books out there but this is the best one to get you going and covers enough advanced topics to make it valuable as a reference.

Now you're just trolling for rep points. (j/k. I though the eye camera bit was hilarious.)

No no... that's consultants. Other differences between contractors and consultants: Consultants are respected as subject domain experts, acknowledged as providing valuable services to the client, have outrageous bill rates, and spend the winter skiing in Switzerland. The company I'm at now has a history of regarding contractors (of which there are many) as falling somewhere between the janitor and the trash he carries out to the dumpster. (Although the group I'm in right now is very good.) I wouldn't say it sucks. I've thoroughly enjoyed my last 2.5 years contracting. (Except for that part where I was fired for not volunteering to put in extra unbilled hours...) There are definite pros and cons to it though. On the plus side I get to keep doing technical work (as opposed to just managing projects), I have very few meetings, yearly reviews and office politics are a thing of the past, and my manager tells me not to work more than 40 hrs a week. The negative side includes no paid vacation, no sick leave, no training budget, and generally being regarded as a second class citizen.

As a great philanderer once said, "I feel your pain." As much as I'd like to go I can't afford 40 hrs of lost wages plus the cost of attending the event itself. Such is life as a contractor. But I can afford root beer once in a while. I'll raise a frosty glass of A&W to you while scouring the web for NI Week information.

I've used VI Tester for various side projects--mostly to learn how to use it and what it can do. I haven't applied it in a structured way to any real world problems though. Because the Probe and Highlighter are very slow debugging tools with large complex applications. If you have a good suite of unit tests it will help you quickly find bugs.

I just ran some quick testing using this block diagram and monitoring the memory allocation using Process Explorer. I discovered that during the second loop when empty arrays are queued, LV won't start deallocating memory until the second iteration, after which one element's worth of memory is deallocated with each iteration. It looks like LV keeps a buffer around in case you queue up another element. When the second loop is finished there is still one element worth of memory (30 MB) allocated for the queue. That's good news for SEQs--it looks like they are in place operations. I wonder if this strategy was adopted as a way to minimize the number of memory (de)allocations or if was designed to make SEQ operations more efficient. Incidentally, if you need every last ounce of memory and want to get rid of that large buffer, write one extra empty element to the queue. Putting 8 empty arrays on the queue instead of 7 gave me this:

Here and here.

No, you're not missing anything. Neither diagram accomplished my goal... I just thought it interesting how my fiddling led me to a somewhat abstract equivalent of dropping a sub vi on a block diagram. (Plus I wanted to double check that the two methods are essentially equivalent, minus the performance issues AQ mentioned.) The only way I've been able to figure out how to pass parameters to a vi while launching a parallel process (thread, actually) is to wrap the sub vi in a by-ref framework such as a Single Element Queue.

So today I was fiddling around with ways I might be able to start a vi in a parallel process while passing it data at the same time. Doing this always seems more complicated that it should be. One of my experiments ended in this: I quickly realized that didn't do what I wanted, then after looking at it for a few seconds it dawned on me... I could accomplish the same thing with this: Sometimes I deserve a slap in the forehead. (Just in case I'm missing something... is there any advantage to using the first method as shown over calling the vi directly?)

Ah ha, I don't know anything about the linker methods. I take it each vi has a table at a fixed offset containing all the sub vis it calls that allows the project to retrieve the information directly from disk?

Prompt, to the point, and you even threw in an apology. What more could a guy ask for?

I'm impressed danny! I didn't think there was anyone who could accumulate posts slower than me. From the Lounge forum description: "Nothing is off-topic..." I believe that is tacitly acknowledging that nothing is inappropriate for this forum. (Provided, of course, that it is all in good fun.) --Always on the lookout for good comebacks--