Aristos Queue

QUOTE(Ben @ Mar 27 2007, 03:14 PM) Ah... the power to edit LV resource files... http://forums.lavag.org/index.php?act=attach&type=post&id=5326''>http://forums.lavag.org/index.php?act=attach&type=post&id=5326'>http://forums.lavag.org/index.php?act=attach&type=post&id=5326 For the brief time it existed, it had a value equal to pi... I know... it was kind of an irrational choice.

QUOTE(Rexxar @ Mar 28 2007, 01:06 AM) For bool (the C++ keyword) there is no size standard. The language defines it as a keyword so that the compiler can choose the size that is most optimal for the platform. On most platforms, you can call a function that has a bool parameter by configuring the Call Library Node as if the function had a uInt8, but bool can be larger if that provides better alignment on the platform. For BOOL, which is fixed as a 32-bit integer I THINK you should be able to configure the Call Library Node as if the function had an int32. In both cases, use the "not equals zero" primitive to get the boolean evaluation. DO NOT use "equals one" -- true is defined as any non-zero value, and you may get values back that are other than zero or one.

QUOTE(njkirchner @ Mar 27 2007, 04:26 PM) Yes. Data traveling on a class wire will always dispatch to the class of the data, not the class of the wire. That is the very definition of dynamic dispatching. The classic demo: Drop a constant of Parent and a constant of a Child. Drop a Build Array. Wire both constants to the build array. You get an array of Parent. Wire that to the border of a For Loop (indexing tunnel) and wire the inside to a dynamic dispatch subVI. Run the VI and watch as the first iteration calls the Parent version and the second iteration calls the Child version.

QUOTE(Tomi Maila @ Mar 27 2007, 12:32 PM) I'll look into the rest of your suggestions, but on this one --- I do want the subpanels to be running. There's a bug in Details Display Dialog.vi that I've been unable to overcome. I make two calls to the subpanel VI. The first call the subpanel resizes and lays itself out and returns to the caller what size the caller should be -- the caller is in charge of displaying the Continue or Stop or whatever buttons. The second call would be to run the VI while it is in the subpanel. But when I try to run the VI in the subpanel, I keep getting an error about the VI not being in a state compatible with the Run method. No idea how to fix this. If you know how to debug it, I'd love to see it.

FYI... the prototype for the revised error.llb is now available: http://forums.lavag.org/Prototype-replacem...empt-t7090.html

QUOTE(Tomi Maila @ Mar 27 2007, 01:50 AM) The division would be between sections that NI wouldn't change the interface between versions and sections for which NI might completely blow away the interface. Up to now, the general principle of vi.lib has been "if it is in the palettes, then it needs to have the same functionality version to version or provide mutation code so that the user's diagram gets modified to have the same functionality (to the degree it is possible to do so). If a VI is not in the palettes, you can rewrite it as needed." If NI starts deploying LV classes that are part of standard libraries, there are going to be interfaces that must be stable version to version and there are interfaces that might be completely blown away. In the prototype of the error class hierarchy that I posted (different LAVA thread), there are two classes that handle the <err> and <append> tags respectively. Those are internal components, and in my vision, if you inherited from them, you shouldn't expect that the API stays consistent version to version of LV. Anything with the user-def symbol is a promise from NI to remain stable and functional with the same API. QUOTE(Jim Kring @ Mar 27 2007, 02:23 AM) My guesses are that its either a confidential feature that you don't want to disclose or its because NI doesn't think that we need by reference objects -- I hope it's the former. Almost... it's because these are the glyphs that LV classes add to LV... and we haven't added references. Whether or not this may happen in the future is an open question. QUOTE(Tomi Maila @ Mar 27 2007, 01:50 AM) I think there should be [a reference glyph]. Consider someone writing a device driver for a device. Very propably a referece to the physical device will be used as private data. So actually the wire acts like a reference and not like a value... The glyph for "refnum" is the document with the folded corner. I don't know how this came to be the glyph for it, but it's used *everywhere* in LV, and used fairly consistently. (Yes, it is also used to indicate "file" which makes "file refnum" sort of interesting, IMHO.) I'd expect that whoever created the reference class would decorate it with the appropriate symbol -- ie, Endevo might have a mark, and dqGOOP might have a different mark. These would only be appropriate if there were a functional difference between reference classes created by the different toolkits. If an individual customer creates a reference class of his/her own, the mark would want to be different again since the class wouldn't be usable in conjunction with the hierarchies generated by the aforementioned tools. If LV ever creates a native reference type, then there'd be a glyph from us to represent LV reference, but as nonesuch exists, it didn't make sense to try to glyph it now (is "glyph" a verb? Hm... perhaps "iconify"? "draw"?)

QUOTE(prayami @ Mar 26 2007, 05:39 PM) Search in the palettes for the "First call?" primitive. Wire that boolean output to your case structure. That prim will return true the first time it is called, but false thereafter. If you stop the VI running and restart, the prim resets.

QUOTE(Tomi Maila @ Mar 26 2007, 04:54 AM) You're half right. You're wrong in saying we don't need it. There's going to be lots of cases of needing this. You're right in saying that you should inherit from network error. The resolution of these: the class "network error" should inherit from user-defined error. There's going to be plenty of places where the G code needs to cross out of LV internals and into LV externals. All the driver groups etc are externals. As for the missing glyphs -- these are the LV class glyphs only. Not the entire iconography of LV. You mentioned XML. Why not TCP/IP? Or the glyph for file path? The iconography for the rest of LV is available on the website. This is the LV class additions/standardizations only. And there's no glyph for references included. Guess why... ;-)

QUOTE(Tomi Maila @ Mar 25 2007, 03:46 AM) I don't see any that have a blue background. All should have a transparent or white background. Which browser are you using?

QUOTE(yen @ Mar 24 2007, 04:57 PM) Thanks, but it is mostly not my artwork. I used to draw clipart for a job. Now I'm just a consumer of it. ;-) Save your thanks for people like NI's Laura Hayden.

So, after trying to post these VIs a few weeks ago, getting (rightfully) turned down by LAVA gurus for submitting prototype code to the finished code repository, and then accidentally mass compiling my VIs in a non-shipping build of LV (you can read the whole debacle here), I'm ready to try this again... I have ready a replacement for error.llb. This replacement uses LabVIEW classes to (in theory) massively extend the power of the General Error Handler.vi without adding to the in memory footprint of that VI hierarchy and simplifying the existing code. Great theory, huh? If you use LV8.2, you can download it from here: http://forums.lavag.org/index.php?act=attach&type=post&id=5290 INSTALLATION INSTRUCTIONS While NOT running LabVIEW, delete your existing LabVIEW 8.2\vi.lib\Utility\error.llb and unzip the attachment in its place. You probably don't want to actually delete error.llb -- just hide it somewhere that LV can't find it (don't just change the file extension). To uninstall, delete the unziped files and put the original error.llb back. Note: this replacement works fine for MS Windows. It frequently crashes the Macs with Intel chips. I do not know about Mac PowerPC or Linux -- I strongly suspect (based on MacTel crash logs) that they work fine and the crash is just on the MacTels, which are not officially supported by LV8.2. This entire project a prototype, not a finished product, so do not use this in any product you intend to ship. This is released for your use under the same license that NI uses for anything in vi.lib -- you can modify, copy, distribute, etc, to the same degree that you could with any VI that is in vi.lib. Any rights that NI reserves vis-a-vis vi.lib apply to this download. WHAT DOES THIS REPLACEMENT DO? The error code cluster is LV's tool for passing error information through a diagram. Eventually, these clusters are displayed by the General Error Handler.vi (aka the GEH) in nice human readable form. Some years ago, the DAQmx team asked about the possibility of displaying charts/graphs in the GEH for certain types of errors. This was shot down because the already-complex GEH would be bloated trying to have custom displays for various errors, and the maintenance of tracking which dialog went with which error code would be a headache at least. In LV8.2, LV introduced classes. Classes allow the data on the wire to define the behavior of nodes, so that a given subVI call will actually invoke different subVIs based on the data on the wire. This seems like a great solution for DAQmx's request for the GEH, except for the overhead of replacing all the error code clusters in LV with a LV class. Ug. This replacement for error.llb allows us to hide a flattened LV class in the Source string of the error code cluster. This string, which already carries formatting and encoding data, can be unflattened in the GEH and then acted upon. The advantage is that different types of errors can then be made that have their own error displays WITHOUT adding any code to the GEH itself. In fact, the existing GEH code can be simplified rather significantly. A user would only pay the price of having another handler in memory if his/her code actually generated an error of that type. That's important if the capacities of the GEH are to be significantly expanded. HOW TO MAKE YOUR OWN ERROR TYPE An example of a new error class -- one capable of displaying pictures in the GEH -- is attached here: http://forums.lavag.org/index.php?act=attach&type=post&id=5291 The project file included with the .zip file shows User-Defined Error.lvclass. You should generally make any new classes inherit from that one. A LV class cannot be inherited from when it is running, and you'll find that the base class "Source Error.lvclass" is frequently locked because it is used by various parts of LV internally (we do write a lot of LV using LV). The User-Defined Error.lvclass should (*ahem*) never be used as part of LV's internals and thus is unlocked and available for inheriting. Picture Error.lvclass inherits from User-Defined Error.lvclass. You can follow the basic idea of Picture Error.lvclass to create your own error class. Create a new class. Make it inherit from User-Defined Error.lvclass. Edit the class' icon to suit your taste. Consider following the new iconography guidelines. Add any fields you need to your class' private data cluster. Create a VI in your class that is the subpanel that will be displayed in the GEH. The subpanel must match the conpane of Picture Error.lvclass:Details Display Dialog Picture Subpanel.vi. (This is a prototype -- I've used the 5x5 conpane here because I've added and removed various terminals so many times and I occassionally overflowed 4x4...) The "Error.lvclass" input can be safely downcast (use the To More Specific node) to your specific class type... the code guarantees that this downcast will always work, so don't worry about the error out (there are tricky aspects to handling errors that occur in the error handler itself...). Use New>>Override VI to override Get Subpanel.vi. Edit your new VI to return the subpanel that you created in the previous step. Now go use your new error where you will. If you look in LabVIEW 8.2\vi.lib\Utility\error.llb\ you'll find a .lvproj file that was used for defining the new class structure for errors. In that project, you can see the functions that are currently available in the palette, plus 4 more that would likely be added to the palettes if this project becomes more than a prototype. You'll also see two other classes of errors that are already used in the GEH to handle existing special cases. FEEDBACK WELCOME I welcome your feedback on this prototype. The code works in LV8.2 (on Windows at least). I do not have any inkling of when, if ever, this would replace the error.llb that ships with LV, but it is something that I'm investigating. Specific areas of interest: I'd really like for the subpanels to be live and running so that complex error information could be displayed with animation or interact with the user. I've written the Details Display Dialog.vi to make two calls to the subpanel VI -- one to size the subpanel, the second to run the subpanel. But I keep getting error that the VI is not in a runable state when I call it the second time. Someone with more knowledge of subpanels might make this work. Improvements to the API. I don't particularly like the conpane for the subpanel, but I've tried to make it as extensible as possible, so that as much code can be reused by people who add new overrides as possible. But as you can see, a lot of code was duplicated in the Picture Error.lvclass subpanel from the default subpanel VI. Feedback on how much memory this actually takes up normally vis-a-vis the existing GEH when handling run of the mill error clusters. Thanks.

The iconography staff for LabVIEW has worked out a set of glyphs for describing LabVIEW classes. This is the first public draft. Over time, LV will be using these glyphs in icons it develops for internal features, and we're recommending this common iconography to customers. Your feedback is welcome. http://jabberwocky.outriangle.org/LVClassG...yphsFromNI.html PS: You'll note that the feedback of LAVA was taken in the case of "abstract class". No, I didn't include the blender icon. ;-) I did get permission from Jim Kring to use his icon.

Here. It goes 7 to 0 then 0 to 7. How to offset the sequence so that it goes from 0 to 7 and then from 7 to 0 is left as an exercise to the reader. It is saved in LV8.0.

I tried for a few hours to come up with something... didn't do so good. First thought: Let's use Mouse Up and Mouse Down to ignore the Value Changed event. So when we get Mouse Down, we'll set a boolean that says "ah, we've started gathering data." Then, on a Mouse Up, if the boolean was set, we should actually acknowledge a Value Changed event. That doesn't work because you don't get a Mouse Up event if the user releases the mouse while not over the control, even though the value keeps changing while the user holds down the mouse button, even when not over the control. So, I thought I'd get all clever and do this: on Mouse Enter, enable the knob. On Mouse Leave, disable the knob. Silly me, I thought this might stop us from changing the value of the control once the user left the region of the knob. I could thus register a Value Changed on Mouse Leave and on Mouse Up. Nope. Value happily keeps changing if you programmatically disable the knob while the mouse button is already down. Ok. So then I used Mouse Enter and Mouse Leave to control the value... On a Mouse Leave, I'd set a boolean to false. While that boolean is false, if there were any Value Changed events, I'd just set the value right back to the old value. That worked, except for the horrible redraw problem -- lots of flickering from old value to new value. So I tried creating a second knob stacked exactly on top of the first knob. That second knob would be hidden any time the mouse was not over the knob pair. On Mouse Leave, I woudl show the second knob, with its value set to whatever the value of the first knob was at the moment the mouse left. That was great at getting rid of the flicker -- but there was still the damn value tip strip. There's no way to hide, supress or disable that tipstrip. ARGH. Anyway, my final VI is attached to this post. Anyone want to try carrying this further? By the way... what we really need it seems is something akin to what is on a String control. A string has the option of "Update value while typing." Normally this is turned off, but you can turn it on if you really want a Value Changed on each keystroke. It seems like we'd like on knobs/sliders to have "Update value while dragging" --- and have it also default to off. (Though it would have to default to On for existing contols to provide the same behavior in existing programs).

QUOTE(pockey @ Mar 22 2007, 03:50 AM) Looks like something tried to shutdown as part of LV exiting last time, and LV didn't uninitialize correctly. I wouldn't worry about it unless it becomes common. I'll report the problem about the read-only directory. We ought to handle that better.

QUOTE(Darren @ Mar 22 2007, 05:00 PM) True. But the fact that you're totally pwning the arcade has a great deal to do with the fact that you work at NI. It's a little known fact that all our candidates for hire must be able to demonstrate competency on at least one game in the LAVA arcade. Having said that, yes, I do wish some of the metrics about "time spent playing" were less available.

QUOTE(pockey @ Mar 22 2007, 02:39 AM) My only guess would be that maybe you don't have permission to write to that directory. Is it read only or something? Other than that, I have no idea. Having said that... check if the log file actually got written out (in spite of what the error message says). If so, go ahead and post the log file here. Maybe we can puzzle out what happened.

QUOTE(Neville D @ Mar 19 2007, 02:37 PM) I didn't know about this VI -- I tend to be familiar with the language and not so much the libraries of VIs written in the language. But I opened it up... seems that, yes, the functionality is the same as that requested, but it's a pretty inefficient implementation. I played hide-the-dots with that VI for a while (if you're unfamiliar with that game, it's where you use Tools>>Profile>>Show Buffer Allocations to optimize LV code -- called hide the dots because you try to get down to as few dots on the terminals as possible) and I found a lot of places that could be improved. If he's looking for speed, I think that the VI I posted will be substantially better. The Mean Pt by Pt.vi has more functionality than mine, but for what rkesmodel is attempting, I don't think he needs any further functionality.

This is kind of a dumb post, but I need a rules clarification from those who have higher scores than I on the game Plumber 2 ( http://forums.lavag.org/arcade.html&code=play&g=62 ) At level 14, there are multiple destination pipes. It appears to me that one of these pipes is a real destination, and the other is a fake and if you route the water to the wrong pipe, you lose the game. Is there any way to distinguish the real destination from the false destination? Is it random which is the real one, or is it always the same one and you just have to learn which is the real destination at each level and remember the next time you play?

QUOTE(rkesmodel @ Mar 17 2007, 01:11 PM) You'll get less data movement if, instead of using Rotate 1D Array, you track which element needs to be replaced on each call. Start the value at zero, increment on each call, and reset to zero if it equals the size of your array. That way all that you do is substitute the value of the array instead of moving all the elements of the array. Attached is example VI (saved in LV8.0).

I moved my mouse to the other hand when I'm at home. It took a bit to get used to, but now I can hand the mouse off easily from one hand to the other. This avoids too much stress on one wrist and lets me rest one side when it gets tired.

QUOTE(leblanc @ Mar 14 2007, 03:58 PM) Merely because LV has OO capacities does not mean that 20 years of libraries have been rewritten along OO principles.

QUOTE(Aitor Solar @ Mar 14 2007, 07:37 AM) You're absolutely right. It wuold be crazy. So make sure to tell me if anyone does it. Then I'll make sure we never do something like for-loop-with-break.

QUOTE(jaegen @ Mar 13 2007, 10:38 AM) It could be that the bg color is all the OS allows us to change. That would almost make sense -- I know that with the selected text, when you set the bg color in the system table, then the selected text color is calculated from the background to always be a visible color. I don't know about the unselected fg text, but it seems reasonable that it would be a calculated value as well.

QUOTE(Michael_Aivaliotis @ Mar 12 2007, 05:57 PM) Well, that's one option. Or I could just say, "Silly user, don't do that." But I think the best solution would be if I go change the default background for all VIs to diagonal multi-color stripes so that no matter what wire color/pattern you choose you can always see it against the background. Don't you think?