Leaderboard

This post has been promoted to an article

If anyone thinks the State Diagram Editor was a good tool and want it back, vote up!

Send me the LabVIEW source and I'll propose something <crusade starts here> Since, by our own admissions, we are both guessing as to what and how LabVIEW does what it does. It's a bit fruitless to put forward solutions and, to be frank, it's not our issue. All we can do is put forward "requirements" and let NI find the solutions-such is the nature of closed source!. Very difficult is not an excuse not to do something though. IF this was enabled by whatever means was required it would (I think) open up a whole host of other events that the event structure could handle and maybe we could get the overhaul that events have been crying out for for several years. Wouldn't it be lovely.to have OnLoad, OnLoaded, OnUnload, OnPanelOpen, OnBringToFront et. al that all the other languages have? Or how about VISA events that can be wired directly to the event structure for proper event driven comms <crusade ends here> Indeed. There are lots of functions that have the proviso that it runs in the UI thread, not in run-time or loads panel into memory. If it is stated in the help what the limitations are, then it is up to the developer whether to utilise it or not.

Hmm... We don't see either excessive build times or long delays when editing class methods (except under special circumstances, such as we are making the first edit to just deployed real-time code, but that has nothing to do with classes). The class properties dialog does still take too long to populate. For the record, I just looked at one of the simpler RT controllers and it has more than 60 classes in the hierarchy. We are using LabVIEW 2011 presently. (A very special case where we did have problems that did have lots of classes was really an issue with the DSC Module during the build process and we have a workaround for that. I think this is not an issue in 2011 anyway.) One thought I have is that we use many interfaces and a few implementations of the Factory Method Pattern that together dramatically reduce source code interdependencies. Before we did this deployments on RT in the development environment very often didn't even complete. Now these deployment issues are a thing of the past.

As long as you use exactly the same name to obtain the notifier, it's the same notifier regardless of which VI obtains it. Unless you pass the notifier refnum around, though, there's no way to only obtain it in one place. For every time you obtain the notifier, you should release it; LabVIEW maintains an internal counter of how many times it has been opened/closed and only when that counter reaches zero can those resources be freed.

I'm sure you're probably aware of this, but what I've done in the past is use the Mouse Up event on the control, and then check to see if the ROI has changed from what it was previously. Still nothing wrong with catching this event.

We've posted a Knowledge Base (KB) article on this subject; Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams, which explains, in some detail, why the VI password protection feature is implemented as it is and the alternative available when stronger protection is required. We also plan to add a link to this KB in our product and/or help documentation, where appropriate, as part of our next major release. Our aim is to do our best to help users be aware of the issue and understand their options. I will monitor this thread for a bit and respond to questions or concerns as needed. Sincerely, Roy Faltesek Senior Group Manager LabVIEW R&D National Instruments

...wow well that site is interesting. FYI it seems that the NI forum has found it as well. http://forums.ni.com...p/310730/page/6 For those of you that are interested the site appears to take a VI and overwrite the password with a known one, and then recalculate two hashes needed. It seems to me the person that owns that site must have some inside information from NI about the file structure. Not necessarily in how to parse the blocks of data (I can see that) but I'm not sure I would have been able to determine the two hashes that need to get recalculated when the password is changed.