Aristos Queue

QUOTE(linnx @ Mar 6 2007, 04:10 PM)

DIAdem is overkill and it seems like you get overkill or nothing, there's no inbetween as far as LV's print preview functionality and formatting is concerned.

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)

As far as I tried 8.2.1, many LVOOP bugs are fixed. You should be convinced.

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)

I'm not trying to rub salt in the wounds, but rather, give some perspective in the context of the moment...

Even for one-person projects, source code control is invaluable. For example, you can create an SVN repository on your local machine and checkout a sandbox for working on your personal projects. This will give you a safety net, even if you're not using the corporate repository.

TortoiseSVN makes setting up a local repository very easy, by the way.

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)

Bugs in LVOOP?

LVOOP is a public beta ...

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)

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

A work around is: open only the enum typedef, change and save it and after that open the big application.

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)

Why? Do you want to give me a free copy of 9.0? :thumbup:

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 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. ;-)

A) There's a known issue with building LVClasses into EXE/DLLs when choosing the various "remove" options. Classes were really intended to be coherent wholes and no provision was made for breaking them into pieces when building apps. It's being addressed, but for the time being, you have to include the typedefs (so that the private data control doesn't disappear) and not remove unneeded VIs (since the dynamic dispatch VIs aren't directly called by the caller VIs, the build system thinks they're not needed).

B) Yes, the dynamic dispatch VIs save outside of the EXE/DLL. And, yes, it is cumbersome. The problem is that the DLL/EXE is effectively a single directory internally and so no two VIs of the same name can be saved inside the EXE/DLL. Of course, LVClasses almost always have two VIs of the same name -- that's how overrides work. So as a workaround, we made the dynamics save outside of the EXE/DLL. The diagrams and panels are stripped, as you noted. A future version of LV should address the file name limitations of EXE/DLLs.

QUOTE(yen @ Feb 25 2007, 12:50 PM)

Add that to the fact that I don't have 8.2, so I can't actually see the implementation for myself, and you will see why I'm having problems.

Will you be at NI Week in August?

QUOTE(JFM @ Feb 27 2007, 08:18 AM)

I'm not arguing that it should be possible to add two absolute times, what I'm trying to say is that I would like the TimeStamp data type be able to contain relative values as well.

QUOTE

Taking your two statements together... it would be logically impossible to have very high accuracy for a relative value. For relative offsets, all you need is a scalar value, for which floating point works just fine -- as it maintains very high precision.

Yen asked me two questions. I'll answer them in reverse order...

QUOTE(yen @ Feb 20 2007, 12:24 PM)

And lastly, I was just wondering if there was any significance to your user name (other than the queue part, obviously ).

Refactoring the Queue VIs (which used CINs) to be the Queue primitives was my first assignment when I joined LV R&D. Aristos, as others have mentioned, is Greek for "excellence" or "the best". It also is the root for "aristocracy," which in modern parlance has come to mean "ruling class". So "He who brings the best out of the Queues" would be a good translation.

QUOTE(yen @ Feb 20 2007, 12:24 PM)

Checking my credentials, I take it.

I think I've mentioned before that I don't get to do as much G programming as I like. There are many in R&D who program full time in G -- frequent LAVA poster Darren, for example. I am not one of those. On any given day, the majority of the hours are spent spelunking in the 2 million plus lines of C++ code that make LabVIEW and all of its various modules. My work on the LVClasses means that I've had to make many changes across lots of features, so I've wandered through most of those lines at some point in the last few years. When do I get to program in G? Mostly on test days -- when LV rolls into beta, the R&D team spend a good chunk of time developing whatever we choose to develop using G (and filing bug reports...). That's when a lot of example programs get written.

I only have two large-scale projects that I've developed using LabVIEW. One is a game that I built early on in my LV career and have tweaked a bit from time to time, but it is still pretty poor style. The other is a 300 VI hierarchy that scans all the VIs on a computer (or multiple computers), parses their block diagrams and builds a database to discover which nodes are most frequently used and which nodes are used in conjunction with which others and what sort of conjunction (which are wired together, which are in the same struct, and which are in the same VI). I've used this tool to find performance hot spots that need optimization in LV and to change the palette layouts -- when I can show that two nodes are *always* used in conjunction then it strengthens the argument that they should be on the same palette.

I don't program in G to the level of most of you. But I am a very strong programmer in whatever language I pick up, and G is no exception. More important, to this conversation, than how much I write VIs is how much I debug VIs. I get about one CAR every day from various users (more when we're in beta). The bug that the user files may be about some small corner of their code, but I see the entire VI, and frequently I can see corner or edge cases that aren't going to be handled properly. I get called in to debug problems with instrument drivers "that just have to be a bug in the LV compiler" that turn out to be a data value not being set properly. I don't get to write much in G, but I do know all the mistakes that can be made. And I think my LabVOOP team has provided a critical tool for preventing a wide swath of those bugs.

Since the release of LV8.2, my G programming has increased substantially. Some of that is the demand for examples for OO, which not many people can write yet. More of it is my own interest in using G is increased. How far can I push the LabVIEW classses? What can I do now that I couldn't do before? Is there some piece of code that was hard or confusing before that a class hierarchy can clarify? I've lately finished refactoring the General Error Handler.vi using LV classes, with positive effects on memory footprint, complexity of diagram and functionality. I don't know if I'll actually ship that or not, but I like seeing the cleansing effect on some otherwise very tangled code.

Do I use LVClasses in my own work? Yes. I worked for five years on that design because I considered it such a fundamental gap in the strengths of LV. In my opinion, LVClasses are the right tool more often than they are the wrong tool. The two tools that I've developed for my own use since August both use LV classes.

I made sure that LVClasses were available in the Base edition of LabVIEW when a lot of others were pushing for them to be in the Pro edition only. Many other developers looked at LVClasses and saw an advanced programming tool that could only be used by those with years of experience. I look at LVClasses and see a tool that a customer should be learning in Basics I. Before they create their first VI they should create their first class. I don't honestly think that we're at that point yet, usability-wise, but I intend that LV classes will get there within the decade. I get a lot of pushback on this that the random scientist or engineer with no programming background has no clue what a class is or how to use it. I point out that they don't know what a front panel or a block diagram is either, and yet they figure it out from our interface.

I don't think that I could've worked for 6 years on that project without a strong amount of belief that my team was bringing something fundamentally *better* to the table. Yes, I said better. You won't hear that from Marketing or from most CLDs, or, indeed, most users in general. The value of the classes to LV programming is something that is becomming apparent to one developer at a time. Darren had his epiphany only a couple of weeks ago when he was working on an XML parser. Within NI, the value of the classes is catching on -- the next version of LabVIEW will see LV classes at the heart of AppBuilder, the MathScript node and the Getting Started Window.

In short, I believe this: LabVIEW classes are an outright replacement for clusters in most situations unless you have to be backward compatible with old code or you're passing across DLL boundaries. LabVIEW classes should replace many uses of the typedef (but not the strict typedef or the custom control). Whereever "type like" data is connected to a case structure -- an enum, or a string ID -- that is a place where classes can improve the readability, the maintainability and the probability of correctness of a VI.

I do believe in classes. A lot.

And now, if you'll excuse me, I have a bug to fix. A coworker has presented me a 1260 VI hierarchy involving 49 LabVIEW classes. And one of those VIs doesn't want to load in the latest development build. "It worked fine last week, but now is broken. I tried to pare it down, but everything seems ok if I take away any of the other 1259...." :ninja:

Using File>>VI Properties>>Description is a good idea since the text entered here shows up in the Context Help window when people are using your VI as a subVI or browsing the palettes. That description is intended for VIs that will be used as subVIs for other programs.

If you want to document how to use your VI for an end user, then there are several options. The obvious is putting comments directly on the front panel. You could also fill in the Help Path (again in File>>VI Properties>>Description) to point to any HTML file. If you do that, then the menu item Help>>Help for this VI will be ungrayed. Clicking on it will launch the HTML file in a browser. Also, if you popup on individual controls, you can set the description for that single control. This text will appear in the Context Help window (when the CH is open) when the mouse is over the given control.

QUOTE(yen @ Feb 19 2007, 01:20 PM)

I have seen several VIs with embedded animated GIFs, but I can not find the example you're talking about. Can you upload it?

See correction to my earlier post.

QUOTE

So there is no general way to test if my object is of certain runtime type or it's decedent in a compiled application.

To do inheritance testing, use the To More Specific primitive. If it return an error, then you don't inherit from the given type. That does not give you generic runtime type testing (you have "test if this runtime type inherits from this compile time type" but you don't have "test if this runtime type inherits from this runtime type") but it solves most cases. And, yes, it works in the runtime engine.

QUOTE

Don't get me started on this topic again. I've ranted enough elsewhere. Basically, I found out late in the release cycle for LV8.2 that *all* the .lvlib reflection API was dependent upon components that only exist in development environment. Writing properties (aka scripting) was always dev-only, and that makes sense. But reading properties? That's generally available for all controls/VIs/etc at runtime. But not libraries. And because classes are types of libraries, we have the same deficiency. No one objected for libraries since they really only provide namespace control and a reflection API is much less useful for them. For classes, however, being only in dev is a major functionality loss. It was too close to release to change when I found out, so I couldn't raise objections, and now it is entrenched. Digging our way out of this is non-trivial. That's a big reason I've been so responsive in this thread -- trying to get as much runtime functionality as possible written in G as a workaround for the missing built-in functionality.

On your original question of custom controls: In LV7.0 and later, open Example Finder and search for "animated gifs". There are examples showing integration of animated gifs into custom controls. Just one of many fascinating things you can do with custom controls, but one that is less well known.

QUOTE(Tomi Maila @ Feb 17 2007, 12:17 PM)

It seems that some of these LV Classes related scripting nodes don't work in build applications. I fail therefore to find the parent for my objects at runtime in a build application. Is this by design or is there a bug.

Tomi

By design. No scripting works outside of the dev environment. You can build scripting into DLLs, but those DLLs will only operate when called within a development environment of LV. Reason for this: There is no compiler in the runtime engine... it is for running, not editing.

QUOTE(Tomi Maila @ Feb 16 2007, 03:18 PM)

How about changing the pattern so that this "wireless" singleton object is embedded as private data of another wired object.

That might be a second pattern. I'll think about the issue.

QUOTE(Tomi Maila @ Feb 16 2007, 01:32 PM)

Hi,

Assuming I understood the pattern correctly the singleton pattern makes no sense as one cannot pass the singleton object to subVIs. One is limited to using the singleton on a single block-diagram only and cannot pass it anywhere as one cannot place a class control or indicator anywhere. I think this is a severe limitation to this pattern.

p.s. This post was inspired by the discussion on private typedefs in http://forums.lavag.org/index.php?showtopic=6293' target="_blank">another thread.

You don't have to pass it anywhere. Just access it directly in the subVIs. The whole point is that there is but one of these so it doesn't have to be passed around. If this is not desirable for some application, then this is not the pattern for that application. There are a good number of times when absolutely guaranteeting that one and only one exists is valuable.

QUOTE(Tomi Maila @ Feb 16 2007, 11:13 AM)

Is there any other way to find out the parent class hierarchy of runtime class in question other than using LV Class Library (private) scripting nodes?

Those are private functions? Really?

I don't use the G code interface to classes much, but I thought all of the scripting access for classes was wide open public. But, to answer your question, no there's no way to get the hierarchy otherwise. Well, you could by brute force type testing, but that would be ridiculous.

QUOTE(Tomi Maila @ Feb 16 2007, 11:13 AM)

You know, I honestly have no idea.