Aristos Queue

QUOTE(orko @ Mar 11 2007, 10:53 PM) REALLY?? (watch me jumping up and down excited) Where did you hear this? Who do I need to encourage?

QUOTE(orko @ Mar 11 2007, 04:12 PM) Oh, I hope not. This is the absurd part of LVOOP, not necessarily the useful part of it. Weirdness like this exists in many corners of LV or any formal system. The "tongue twisters" I've presented here result from the worst possible presentation of a concept, rather than a clear explanation of of the concept. Just having a bit of fun, not trying to scare anyone off.

QUOTE(yen @ Mar 11 2007, 01:12 PM) I suppose I should phrase it as "Each control has a default value. For each data type, there is a default default value for controls of that type."

QUOTE(PaulG. @ Mar 8 2007, 06:38 PM) I would've expected all of LV to be rated G. ;-)

QUOTE(crelf @ Mar 9 2007, 08:17 AM) Hm... you just made me think of something sneaky... see attached VI (saved in LV8.2). Open the top level VI of the attached LLB. The VI has a numeric control on the FP and a numeric indicator on the FP. Run the VI and the value of the control will be doubled and put into the indicator. But the block diagram has no visible wires connecting the two FP terminals and, indeed, nothing but those two FP terminals and a free label that says "Look ma! No wires!" EDIT: Even better... look at the VI Hierarchy window and note that there are no subVIs shown. Yes, I am going to file a CAR about this...

QUOTE(yen @ Mar 10 2007, 05:51 PM) You gotta love modern LV. Just be glad that we decided to call it "dynamic dispatching." In Java and C++, this behavior is called "virtual," which would have given us "virtual virtual instruments." In LV, each control has a default value. Each data type has a default default value. Which means that a LabVIEW class -- which is a data type whose default value is defined by the default value of a set of controls -- has a default default default value. Let's suggest that someday we add the ability of a LabVIEW class to set its default value by running a VI at load time -- a feature requested by more than one user. Child classes would be able to override and extend the parent class' default value. You might initialize that value using a CBR to a run-time chosen subVI. That would give us "dynamic dynamic default default" values. Then, if we add templates to the whole structure, we might end up with a dynamic dynamic dynamic dispatch VI which overrides the default default default default value of the class. N layers of indirection is never enough. And now you understand why good tech writers are so valuable.

QUOTE(yen @ Mar 10 2007, 05:48 PM) The bits of old programs themselves work and call OS APIs that exist. That doesn't mean that the application conforms to the installer security requirements, standard directory names, and the UI standards of the new OS.

QUOTE(zen @ Mar 10 2007, 05:04 PM) Here's where I think you want to go: a) Remember that .lvclass files have all the functionality of .lvlib files -- classes are just libraries dedicated to the purpose of defining a data type. Given a path to your class, use the VI Server interface to get a list of all the VIs that are members of the class. This will only work inside the LV editor environment (and not the runtime engine), but that's ok for your purposes. Now you can call each of those methods... but... b) ... a VI with a dynamic dispatch connector pane cannot be passed currently to a Call By Reference method. The wire will break. This is a deliberate choice on R&D's part to make sure that in the future we can correctly support dynamic dynamic dispatch. To dynamic invoke these methods today, create a non-dyanmic (static) VI that calls the dynamic VI on its block diagram. Then invoke the static VI in the Call By Reference node. c) You can execute dynamic dispatch VIs directly using the VI's Run method. This might be a better choice for you in general since running the Run method would allow you to invoke VIs even if the conpanes are different.

QUOTE(Tomi Maila @ Mar 10 2007, 05:07 PM) Untrue. The necessary modifications to make LV run in Vista -- just the LV editor environment -- is a list several tens of pages long. Many applications are having to make significant changes to comply with new security regulations and installer behaviors.

QUOTE(Mike Ashe @ Mar 9 2007, 01:50 PM) You see... I knew you'd find http://forums.lavag.org/index.php?s=&showtopic=4225&view=findpost&p=25584' target="_blank">those music note icons useful soon enough. :ninja:

I've seen this kind of bug in development builds of LV when the inplaceness is improperly calculated and some function ends up writing on top of the constant string instead of making a copy for itself. Never seen it in a release build -- those sorts of errors usually show up pretty fast -- but it is possible. Post your VI and let's see what you've found...

QUOTE(Irene_he @ Mar 7 2007, 11:09 AM) I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form (it means you're using variables that can be accessed outside the dataflow and all the problems therein that have been discussed to death elsewhere). As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog. My opinion.

QUOTE(linnx @ Mar 6 2007, 04:10 PM) LV doesn't have any print preview capacities. Diadem is a separate product that built its own. You can use the VI's invoke method "Print to HTML" to dump the contents to your HD and then launch a browser window to see the preview, or build your own viewer of the image files that LV generates. It's not a case of "overkill or nothing." It's a case that a very expensive piece of software, Diadem, added a feature to display the print preview of a diagram. But they're working with the same LV as everyone else.

Right click on your array control's FP terminal and select Create>>Invoke Node>>Reinitialize to Default. This will drop a node that, when executed, will reset your control to its default value.

http://forums.lavag.org/index.php?act=attach&type=post&id=5136 "I know something you don't know..." For those moments when you're tempted to break a non-disclosure agreement because you've just seen something really cool.

QUOTE(tibobo @ Mar 6 2007, 06:06 AM) Trust me, Tomi has filed a list of bugs that *aren't* fixed in the 8.2.1. He's found arcane and bizzare behaviors in all sorts of aspects of LV. Yes, many bugs are fixed in 8.2.1. But you won't convince the man who knows the range of issues that remain.

QUOTE(Jim Kring @ Mar 4 2007, 11:06 PM) Merely because I didn't use the SCC this time does not mean I don't have the tools to do so. I was just dumb. :-(

Some things are just not meant to be... The LAVA gurus quite correctly rejected my submission to the code repository. Not the right place to submit "proof of concept" code. So I was going to post it here. Since the post wasn't yet available, I took the time to look through the code one more time, and I found some more stuff to tweak to improve the setup. So I made the changes. But one of the dangers of being in R&D is that sometimes you launch the wrong version of LV. ... my VIs are now saved in a not-yet-released version of LV, more importantly, a version for which Save For Previous is not operational at this time. Ah, joy. When SFP is fixed, I'll post those VIs. If one of the code reviewers still has one of the versions I submitted earlier, don't post it... I really would rather put up with the later changes. *sigh*

The revised error.llb and commentary was sumitted here: http://forums.lavag.org/downloads.html&showfile=83# Attached to this post is a demo of the revised GEH capabilities. Unzip the attached file and run Picture Error DEMO.zip AFTER you install the posted error.llb.zip (as described in the link). Comments appear on the block diagram. The real magic is down in the revised version of "General Error Handler CORE.vi" Comments welcome.

CompareIt! from grigsoft: http://www.grigsoft.com/wincmp3.htm This is a spectacular text file comparison tool -- syntax highlighting, easy movement of changes in one file to the other file, and a slew of other features. Download for trial, $29 to buy. And if you don't speak English, the tool is available in many languages. This is a great tool for C/C++ developers, but has become useful to LV programmers who need to diff LVLibraries, LVClasses, XControls and LVProjects. Not to mention readme.txt and various HTML help files. I've used this software for years, and talked NI into buying a site license for it -- it's that good.

QUOTE(i2dx @ Mar 1 2007, 01:09 PM) Oh, I hope we tested it better than *that*. But, yes, it is brand new. The bulk of LV became dramatically more stable from 8.0 to 8.2. Getting beta customers or NI internal developers to use LV classes before release was pretty challenging... it's one thing to ask people to try to use a new feature. It's quite another to get them to change their entire LV mindset just for a beta. NI usually has lots of internal developers working on projects using the beta, which helps ensure the stability of the product. It's a level of software testing that most software development can't get, and I think that's pretty cool that we do. But for LV classes, nobody wanted to go first. There are currently four major NI internal projects that use LV classes (that I know of), so we should see much more stability going forward. Heck, the Getting Started Window is now written with LV classes, so if we break, LV won't even get off the ground. That sort of thing will help keep them at the forefront of tested features in the future. ;-)

I *think* that any code placed in the "App Exit" event case of a VI is guaranteed to have a chance to run before the application exits. That was certainly the intent of the design -- we don't "terminate with extreme prejudice" any VI until after there's been a chance for those event structures to execute.

QUOTE(ad_dekkers @ Jan 28 2007, 11:35 AM) Please contact NI tech support and file a bug report. If you don't mind sharing the entire VI hierarchy. We do investigate crashes on these large hierarchies when customers are willing to share their VIs. What version of LV?

QUOTE(yen @ Feb 28 2007, 01:49 PM) I suspect that come August you'll be asking for a piece of NI software, but it won't be LV9.0. (that's my provocative comment for the month... make of it what you will...) QUOTE(yen @ Feb 28 2007, 01:49 PM) I was planning on being at the last one, but that didn't work out. If I'll be at the next one I'll be sure to seek you out, but I don't think I need a private lesson, just to do some actual work to get the concept. :laugh: I ask only because I think (schedule not yet finalized) there'll be presentations teaching LabVOOP at NI Week.

You know, a lot of people have a knee-jerk reaction to reject "dot zero" versions of software. I like to tell these people that LV7.0 was the most stable version of LV ever when it was released. And then they ask about 8.0.... *sigh* Use 8.2. And please forgive us for 8.0. Every software team has bad days. We tried to pack ours all together in a couple months so that we wouldn't have any more bad days for the next several releases. ;-)