Aristos Queue

Actually, GPIB uses error code zero, so be careful with that idea. Error 0: Error connecting to driver or device. I have no idea what conditions make this error code be returned, but there you have it. One of those legacy things from years ago.

I didn't quite grasp the reasoning for LabVIEW Value Class. Why can't the LabVIEW Reference Class inherit from the existing LabVIEW Object?

The autotool works much better in 8.2. That nervous twitch in your mouse hand that you've developed over the last 4 years to hit *exactly* the right spot to get the right tool may now be a liability instead of an asset. Kidding aside, I don't think you should have much problem moving your VIs forward. Your biggest barrier will probably be what most folks have complained about -- the palettes got a serious reorg in 8.0.

A code disable structure would not achieve the effect -- if it isn't compiled into the code then when the subVI is missing the VI isn't broken. You could put the subVI into a case structure that is wired with a control (not a constant!) whose value is FALSE. Then it would be compiled in but never executed. But as Kring points out, all they'd have to do is load a VI to fill in the missing subVI. I'm not sure why this is a problem... in previous versions of LV, you could load the VIs even if they were inside the EXE using various magic tricks. It's only recently that you couldn't -- and more people have complained about not being able to access the VIs inside the EXE than have complained about not being able to access them. Now, there is a game that I can play on the C side of the code that I've used a couple of times for hiding VIs... I have the equivalent of a string control whose value is the save image of the VI and then I load the VI from the string instead of loading from disk. Thus there is no VI anywhere on disk that is the VI that I'm loading. I have no idea if any such mechanism exists on the G side of the code. Has anyone ever done something like this? And, now that I think about it, Express VIs generate VIs that are saved inside the caller VI. I wonder if there'd be a way to hide other VIs in there with a custom built Express VI? I've never used the Block Builder Toolkit, so I don't know if this is doable or not. All of these suggestions are a bit of a longshot, and probably not easy even if they would work. Sorry, Jimi, but with AppBuilder I'm pretty much in the dark. It isn't an area of LV that I've paid attention to much, though it appears that with LVClasses I'm going to have to go learn about it more than I had expected. :ninja: What if you just created an LVLibrary that owned your entire application and made all the VIs private to the LVLibrary? Then even if others managed to load them they couldn't run/call them.

Or, you can not use a Global Variable and thereby not pick up an extremely nasty habit. Global Variables are easy to write and painful to debug, especially if anything starts happening in parallel. Stretching just a bit for a slightly harder solution (functional globals, events, queues) will help you a lot when it is time to debug the problem.

Because you don't have scripting. The VI can only be edited on an installation with scripting. The VI can be executed on any LV.

Good book. I have it on my shelf. Another in similar vein, is Timelike Diplomacy. A marvelous book about a hardware engineer who created a temporal feedback loop in a D-flipflop and a moment later a monolith appeared bearing the inscription "Thou shall not violate causality within my historic light cone. Or else." That initial feedback had formed an AI that propagated itself back in time. Quite a fun novel, with the premise that causality is not absolute, merely a good idea (particularly when there's a near omnicient AI enforcing it).

Perhaps it should be retitled "LabVIEW for Everyone-With-Arm-Strength" But perhaps we shouldn't give it a hard time ... I look at my desk and notice that Kring's book is almost exactly the same size as my "The Complete Reference: C++ Third Edition", and Kring's text is WAY more comprehensive and comprehensible than the C++ text.

I have this vision of a very plaid universe. In all seriousness, though, did anyone catch Jeff K's presentation at NI Week 2006 about his proposed asynchronous wire (aka "Jeff's Wire") and the transtemporal three-dimensional stack of block diagrams that would accompany it? That's a vision of LV that will really mess with your head for a bit.

Well, he's not my boss, but he is a customer of mine. That's sorta like a boss with some layers of indirection. I think you'd use a dotted line on a formal organization chart.

In a bit of role reversal, when I joined LAVA, I was advised by several folks not to post anything more than small demo VIs to LAVA because of language that didn't clearly maintain NI's intellectual property. MichaelA and I had a bit of a talk about it, and finally decided to avoid any question by posting anything that might have IP value on my personal website and link to it from here. I don't think that any group is happy with anyone else's legal verbage, and everyone is terrified of being sued or having their code claimed by someone else, etc. etc. etc. So if you're bothered by the IP language over on ni.com, you might try my trick... post the VIs themselves to a site whose IP language you trust and then post to ni.com with only links to the VIs instead of the VIs themselves. Seems to me like a way to leave the lawyers out of it and let us all get back to code development.

Well done.

This doesn't fullfil the design requirements. The FPResize Manager Implementation.vi is using a timeout value on the event structure. This turns it into a 200ms polling loop, which is exactly what I was avoiding by writing the Notifier implementation. The goal was a VI that uses zero CPU time when the user isn't actively clicking on stuff. You did manage to encapsulate the functionality better than I would've expected, but at the cost of using dynamic events, which pushes the technical difficulty of using this API beyond the knowledge of almost all users. The Notifier solution is something that I could explain to people because they've seen Notifiers and they can figure out the Event Structure. Trying to teach dynamic events has proved... difficult. There are good programming reasons why the dynamic events are set up the way they are, and they have extreme power, but they're complex beyond usability most of the time (and, yes, by "complex beyond usability" I do mean the fairly short list of steps of "enable dynamic event terminals, drop a register event node, wire everything, and configure the user event case"). Here it is back in LV7.1. Download File:post-5877-1165336751.vi

You don't. There is no way to specify the address of anything in LabVIEW. Just wire it through. If the compiler detects that the data that flows in eventually flows out then the compiler will take care of making it use the same memory space. If the wire forks at some point, the compiler will decide whether a new copy is needed or whether a single allocation can fulfill both branches of the wire (if, for one simple example, both branches are only reading the array, not modifying it). If a copy is made, then it is because a copy is needed to do the code that you've written. If you don't need it, the compiler shouldn't allocate it. You'll find that the bulk of LabVIEW users will stare at you blankly when you start talking about addresses and pointers in memory. That's because there's no reason for them to pay attention to such stuff when working in LabVIEW in all but the most extreme situations. The nature of dataflow is pretty cool from a computer science perspective: Memory is allocated where the wire starts, and deallocated where it ends. Along the way, new copies spawn as needed for the code written. There are caveats to the above and moments when really advanced programmers trying to squeeze every drop of performance will turn on various advanced tools to tune the memory allocations, but even then they are just tuning when copies get made, not explicitly handling memory addresses. But in the vast majority of cases, LV will do a better job scheduling memory than a person could in such a highly parallel environment. Automatic memory management. Parallel code execution. Optimal thread scheduling. Just some of the benefits of a dataflow language.

Nonsense. Don't knock a perfectly good feature just because it doesn't serve one use case. In this instance, you can't reasonably package this behavior as a subVI since the event structure is going to have to have other cases specific to whatever events are being processed for this particular dialog. The undertaking of creating a "manager" subVI -- which dynamically registers for panel resize on another VI and then uses VI server to call the "do the resize" functionality -- is overkill compared to just putting the management in whatever dialog you happen to be writing today. I'm not even sure that if you took the effort to create the manager subVI that the API you'd end up with would be less work than just adding the necessary code to each dialog. So, given that there's only going to be one Notifier running through this diagram ever, the case that you link to never arises.

Jim: Test cases would be a simple class, a class owned by another library and the all important LabVIEW Object class. LVObject is actually encoded slightly different to guarantee that even if you clever users try to name a class "LabVIEW Object" that we can still distinugish the real LV Object class. The encoding for most classes is: name = length | cpstrlist cpstrlist = [lenghth | text]+ length = a single character (byte) (where | means "followed by" and + means "repeat one or more times as needed) The encoding for LabVIEW object is simply name = length | "LabVIEW Object"

Those tools won't tell you about a LVClass. They predate LVClasses. Unless someone has issued a patch that I don't know about.

I knew it was possible to do without polling. Just took a bit to put it together...

No no. It's LabVIEW. We spent most of LV8.0 working on the underlying artificial intelligence. It now mostly writes itself. It has been generating libraries that it thinks it needs for some time now. By now, it should've generated all the library VIs that people on OpenG, NI, LAVA and DevZone combined could think of to write. Unfortunately, it sucks as an artist. Its icons are all text or plaid and its dialogs make a Linux command line seem user friendly. We'd let it ship more libraries, but it does take time to clean up the UI. That's really all we programmers do these days. Oh, and fix the text. LabVIEW decided that most human languages sucked and only deigns to speak to us in Esperanto. Since none of us speak or read Esperanto, we spend hours studying diagrams so we can rename the VIs as whatever it is that they do. It's not really arrogant, more like a teenager out to prove it knows more than its parents. Really, the only disturbing sign so far is the 200 node VI that took hours to puzzle out. It generates a stereogram that if you stare at it long enough displays the words "Hal9000 is my hero." As a side note, LV's only comment when we asked it why it didn't have perfect automatic wire routing was, "The rat always complains about the path to the cheese. But the cheese is happy the path is not so direct."

You could also do something like this: On your event loop, create a boolean shift register whose value is a boolean. Initially the value is FALSE. Set the timeout of the event structure to 150 milliseconds. In the panel resize event case, turn off panel drawing. Then set the boolean to TRUE. In the timeout event case, test the boolean. If the boolean is TRUE then update the control sizes and then enable panel drawing again. If the boolean is FALSE, then do nothing. The result is that as long as panel size events come quickly then the timeout event will never fire. When the panel resize events quit coming then you can update. At 150 ms, you'll still get nice smooth drags if the user pauses. This does turn the event structure into one that polls every 150 ms, but since it does nothing except test a boolean, it shouldn't be a burden to your CPU. I suspect that you could get rid of the polling behavior by being clever about posting a user event with a timestamp but I'd have to play with it to get it right. Something about a shift register with a timestamp that the resize event updates, then posts a update UI event. As long as the current value of the shift register is before the value of the timestamp when the user event fires then the user event updates the panel sizes, otherwise it does nothing. Or something like that.

The VIs are saved without block diagrams when you build an EXE or library unless you explicitly tell AppBuilder to retain them. Even then the diagrams cannot be loaded by the app builder -- without the editor present, there's no ability to load the diagrams. Front panels can be stripped as well.

Take a look at the General Error Handler.vi. In and among its inputs is the ability to filter the wire value but still output the formatted string of the error so you can dump it to a log file.

All the numeric conversions are either simple bit reinterpretations or IEEE standards for floating point behaviors. I cannot name any programming language that treats type coercion differently. In C, for example, assigning an unsigned int to a signed int will give a compiler warning (equivalent of the coercion dot) but will simply assign the bits without modification. High bit of the unsigned integer becomes the sign bit of the signed integer. None of the behavior is wrong. It is right, by definition, as long as it is consistent.

You should've heard the headbanging when I first heard about this behavior. The workaround to "establish custom destinations for all the VIs to sit next to the EXE instead of just the dynamic dispatch VIs" should work. But this has to be addressed sooner than later.