mje

Yes, I'd love to see that idea implemented. Usually though, I take the situation as a hint I ought to put the loops in their own VIs. Not always convenient, but helps a lot for when you need to do stepping or execution highlighting.

Good idea, but nope, the methods still list in the override dialog. Code is attached. To reproduce the behavior, just right click on View.lvclass, select New > VI for Override ... The View class inherits from MessagePump, which defines the offending methods. Some of the offending methods are even privately scoped, all of them reside with property definition folders: Note that if you then go further down the inheritance chain, and try to implement an override on ContainerView, the methods are no longer listed. The project is for LV2010: LabVIEW.Messaging.2.0-r494.zip

There's still something funky going on with that class though. I think some of the info in the lvclass file is corrupt or something? Look what happens when I try to create an override: What's the problem you ask? The methods in the red boxes are not dynamic, yet the script picks them up for some reason and puts them in the box. Also the previously mentioned bit how the terminals aren't getting properly renamed when I override a method in the class. Even weirder is the dialog appears normal if I try to do an override of a class further down the inheritance chain. For now I'm ignoring the behavior, I hope it doesn't come back to bite me in the behind...

Well, that was foolish of me. First to clarify: Actually I did, if you look at the title bar that's exactly what the VI is. Pardon the names on the terminal labels, but I hadn't gotten around to changing them yet (the override script does not apply the new name). So to clarify, the terminals *are* View.lvclass objects, they just are labeled as "Pump". Now the weird part is when I created the override and connected View methods, I *swear* I got a broken wire. So without thinking I inserted the cast. That was dumb on my part. Should have immediately clued in to the fact that something was wrong. I was also having problems in which the override was never being called, even with the "functional" version I showed. Still not sure what happened there, I'm trying to figure it out. For now, ignore the mad man, I'm trying to reproduce the behavior... Well I give up. I have no idea what was going through my mind. For the record (with properly named terminals!): I swear that when I first coded the VI the wire to the first method broke when I wired it up. I'm not crazy. Honest. Sheesh, this VI should have taken five minutes to code and it took nearly an hour (had a meeting in between some of my posts). Sigh...I need a vacation.

I'm a little confused as to why this is. If you could take a quick look at the code below: The method is an override for a base class method. I need to get information from my class data, so I cast the object to the proper class. Note the cast will ALWAYS be valid (otherwise the dynamic dispatch will not invoke the method). I understand that the primitive can't have knowledge of this, but why does the prim lose the run-type type info? I can't use the output to wire up my Call Parent Method because it generates an error (as expected given the prim's behavior): Is someone able to explain why the behavior is as it is? I've never stumbled across this problem before...

Thanks, Norm. I can't wait to dig into this, I've been waiting for the finished version. One thing I'd like to see an example and brief explanation of is implementing inter-process communication.

I don't want to call this a bug yet because I haven't hammered down how to make this behavior reproducible. But it happens often enough that I thought I'd solicit others to see if they've noticed the same behavior and have any idea on how to trigger it. The problem: when creating class methods which define a property, the property nodes are often (initially) unusable. For example, here's a screen shot showing the property definition for a class I'm working on: And the corresponding VIs, along with a chunk of code trying to use the VIs via a property node. These are new VIs I've just defined, and are in fact the default VIs you get when you create an accessor VI. Notice how both VIs are executable, however the property node is black: it can not be wired. The blackening of the node is normal if you select a property which you do not have access to, however the code which uses the property is in a VI which is a member of the class, so it will always have access, and besides, the VIs are defined as public since I hadn't gotten around to changing them to a more restrictive scope yet. What I've been doing when I come across this is forcing the VIs to recompile by switching a terminal on the connector pane of one of the VIs, thus breaking both VIs, then switching the terminal back. Everything works thereafter. Weird is all I can say. Anyone else been playing this game? Any ideas on what's going on? It doesn't seem to happen all the time... I should add that the code that uses the property is actually acting on a DVR wire of the class...

Good idea on the incremental builds. I'll have to start doing that as part of my tests. The odd thing was that in my case, the error crept up from a source code revision tag which had been stable for months (no code changes had been made). I had someone ask for an old executable I made, so I did an export, built it and boom, error. The same source had literally been used a dozen times earlier to build from (there were no user.lib files, I manage dependencies within scc and they're similarly set to a stable tag). Took me the better half of a week to get this person what he had asked for.

I've seen that "error" many times on 2009. Building applications became the bane of my existence for a while when that error would just creep up and not go away. I never sorted it out, just kept jockeying computers and IDE reinstalls until it worked. It was absolutely infuriating. When I finally got things to work, my installer package had ballooned up in size 2 or 3 times its original size, but I just let it be. Wasn't going to poke that sleeping beast at all, at least I had some kind of deliverable... Application/Installer building in LV is still a rather arcane bit of voodoo in my opinion. They really need to spend more time developing the reliability of that tool, it is my least favorite part of having to deal with LV.

Yes, I've been meaning to check the tool out, had a good chat with the Symbio folks at NI Week. Too bad I wasn't able to snag a version at the BBQ! I haven't downloaded a trial version yet since I know I won't have the time to evaluate it appropriately. Soon though... I also haven't hammered through their pricing scheme. Not sure what version I need and if it's an annual license or an indefinite one tied to the current version?

This is exactly the way I look at the situation, code generation is irrelevant to me. However, I do wish I had the ability to reverse engineer my projects to generate up to date UML which reflects changes I made during design time which I did not account for when initially drawing out my UML.

Agreed, I'd say the crash is the most annoying. I've learned to always create a class icon as soon as I make the class, such that it never requires editing again to work around the bug where you can't edit nested library icons. Still very annoying though.

I'm working on a new re-use library which I hope to have in a semi-complete state within the next month. It will ultimately contain much of what was discussed in another thread, but I figured I would post what I have to date, mostly because all the discussions with people at NIWeek have recently got me pretty excited about the advanced OOP based frameworks that are being worked on. I figured I'd throw mine into the fray for comments as well. It has what I hope to be the next version of my MessagePump framework, and some supporting classes (Callback, and descendants). For the uninitiated, message pumps go by other names such as message loops, event loops, or message dispatchers in other languages. In more traditional LabVIEW lingo, you could recognize a message pump as a consumer portion of many producer-consumer based architectures. I'll point out that there are some completely unimplemented classes in the attachment as well, this is literally an export from the current (incomplete) source code I'm working off of. If you download the current snapshot, you'll find a project file in the root directory, or you can browse right to the examples folder if you'd like. This code is entirely pre-release and not complete. Please do not redistribute it. Of note: The MessagePump is now entirely a by reference class. The public interface handles only DVRs, and does I think a decent job of defining an overridable interface which by necessity must be by value (and is not public). As before I've gone through and made some fairly verbose examples, I think they do a good job demonstrating the fundamental use cases for the class. Speaking of examples, I dislike #2...It's too much too soon and I need to find a better demo case for callbacks. For now though, it's what's we got. If you recall the original MessagePump, you'll notice the pump is now entirely FIFO based (no more posting to the front of the queue), and there are absolutely no built in synchronous posting methods. This was a conscious decision. Finally, unlike the first version which I had been using for about a year before submitting it to LAVA, this version is entirely new and hasn't really been put through it's paces. So if you see something that doesn't seem right, say something...it probably isn't! Note the code is 2010 only. I don't think it can be saved for previous versions as it uses some of the newer features. LabVIEW.Messaging.2.0-PR01.zip Have fun, -Michael

Neat, can't wait to look through this. Odd though that I had to request to join the group despite having been at NIWeek. /waiting...

I'll have to pay more attention to this, somehow missed this thread back when it was active earlier. I started playing with Altova's UModel, for no real reason other than I already had a license for it by virtue of me being an XMLSpy user. Consider me a novice as far as UML goes, I've always done pseudo UML using good old pen and paper before, figured I'd pony up and do it for real this time around.

Now that's pretty cool. I hadn't seen that before. As for XML intermediates, the code I was talking about actually was part of a generic XML reader/writer...so yes! I haven't released the code though, not sure if I can...

I have zero scripting experience, so can't comment on that. But I think you hit it with the time comment, anything you develop will take longer than drudging through the headers by hand. Of course then there's maintenance and validation to account for, but, well, you know. I do have some code that dynamically creates cluster types at will using variants, where each contained element is another properly typed variant. Works recursively and everything (clusters can contain other clusters, arrays, or other "container" types). It does the job by playing with the binary type strings that you get when you flatten a variant. By manipulating those you can pretty much create anything. The rub being of course, that to convert it back to a native LabVIEW data, you need the LabVIEW type, which means you wouldn't need to go through the exercise to begin with. Damned if you do, damned if you don't really. But variants suck, so you don't want to do any of that anyways. Stupid variants

Hi all, Just wondering what your opinions are on the 2010 integrated development environment? I'm loving some of the new 2010 features, but the stability of the IDE has left me...unsatisfied. I'm not (yet) contemplating going back to 2009 for my main development needs, but the 2010 platform leaves me a bit uneasy when I think about starting large projects on it. I only develop on two systems (XP and Win7), but they seem to persist across both platforms. One of the first things I did when I got 2010 is start to design a version 2 of a reuse library I've been waiting on. Some issues that I haven't been able to pin down but happen to me several times a day: In the project explorer, classes/libraries often complain of unsaved members when there are none. Also in the project explorer, items removed from classes/libraries get removed from the list, only to somehow stay attached to the class/lib and often reappear. Seems related to point above, often when trying to save new items (say a new method), the class will complain there are other unsaved items, I'll get prompted, and have the old item reappear in the explorer. Editing the icons of nested classes/libraries is a complete crapshoot. Pretty much have to move any item to the top project level (outside of any containing library) if I want to edit the correct icon. This does not happen with VIs, but for classes nested in libraries, editing the class icon seems impossible if the class is contained. The whole IDE has crashed several times on me while trying to save. No error reports, no investigation when starting up the next time, nothing. IDE just vanishes. Work gone. Worried I'll eventually get corrupt VIs from this. I'm trying my best to be analytical about these things so I can pin down examples of what triggers the behaviors and send examples to NI, but so far I'm coming up empty. -m

In one of the talks at NI week, someone showed using a Diff tool, and they mentioned it is part of the default install. This is news to me, but browsing through the executables in my LV2010 install (or 2009 for that matter), doesn't seem to turn anything up. Anyone have info? Curses, found it, of course in neither location...not in either of the folders. <NIDir>\Shared\LabVIEW Compare\LVCompare.exe Ah the wonders of wildcard exe searches. Doesn't seem to offer any merging, etc though...

Been working with 2010 for about a week now, have any of you had issues with your glyphs and icon templates directories getting wiped (in the LabVIEW Data directory). It's happened on both my desktop and laptop systems. Now the icon editor doesn't have any pre-made glyphs etc, all that's in each directory is a tiny (4 bytes) bin file, Templates.10.0.bin and Glyphs.10.0.bin. I can't be the only one...

Yeah, the lack of being able to put anything other than strings in a listbox/tree has often made my bust out Windows Forms or WPF. In the end though I always end up saying "Screw it, I'll just sacrifice some UI functionality." I just chalk it up to one of the costs of using LabVIEW. The virtues of being in R&D I suppose, UIs don't need to be *too* perfect. The various tree/list controls have needed updating for a long time. They're definitely better than they used to be, but got a long way to go until I'd consider them contemporary with platform natives.

Just like danielsan, I use source code control to handle all dependencies. Everything is set up as an external to a tag via the SCC. I never touch vi.lib/user.lib for anything other than a few of the code bases I use that are distributed through VIPM.

Thanks everyone for a great time, for time. The inspirational speeches, limericks, and drinking songs were a blast. Ready for another day! -michael

Yikes. That's got to be one of the biggest security holes I've seen in a while. I can't really check the code at the moment, but it would appear that pretty much any external (LabVIEW) generated code could be injected into any LabVIEW executable so long as the versions are compatible? That doesn't bode well for, well...anything.

I don't see much of a need for invoke nodes since they can't be piled up one a top of another. Properties are nice since a chain of many accessor VIs can be collapsed into a single node. I wonder if inlining a VI which is also a property works as expected though?