mje

Thanks for the feedback!

SuperS_5, your idea definitely works. The unfortunate side is far as that example goes, it requires the parent VI to be aware of the state of the contained VI. Adapting it to hugo's idea though should make everything work the way I'd like. Good ideas, thanks again.

-m

Is it possible to set the cursor for a VI which is embedded in a subpanel? I keep getting a null window error. Example code attached.

I know I can set the cursor on the parent VI, but that's not what I'm after, I'd like to localize the busy state if possible? Something tells me I'm out of luck...

SubPanelCursor.zip

However this is not functioning as expected, the AbortVI returns an error 1000:

I've seen this. It's related to some static reference voodoo, and when you try to allocate new copies of the reentrant VI it doesn't quite work. Banged my head for a while on that one when I was creating my messaging library.

You should be able to do what you need using generic (non-strict) references. Unfortunately this means interacting with the front panel and doing value set/get methods for each item, dealing with variants, etc. Slow, but I doubt you're going to be doing this in a tight loop or anything. REALLY crude proof based off your original code:

You then need to retrieve the control values...Messy I know, but as far as I can tell it's the *only* way to go if you want platform independency.

Keith's proof is really the best way to do it (once the polling is removed) if you can stick with Windows...

That is the most awesome thing ever.

I also don't understand the auto-tool hate. Just diable it?

But it is not better than the quick drop. Those who say otherwise are clearly just wrong.

I'll throw in support for UI/panel "feel" gripes. The icon editor was a huge step in the right direction and I didn't criticize it in 2009 since it was new, but since it's still chock full of bugs in 2010, I feel laying into it is justified. It's a good idea not fully executed, and as a result poorly executed. I won't say it shouldn't have been released in the state it's in, because it is better than the old one, but it is slow and annoying to say the least.

-m

Finally getting to the point where I have something to compile in my latest application, and I actually browsed the emerging *.exe folder as the build is being made for the first time:

I laughed. 1abvi3w si teh h4x!

Ok, back to work (as soon as the build finishes...)

-m

Make a little demo about how easy it is to do synchronization between parallel tasks? A simple example using queues can go a long way to demonstrating this, even a simple producer-consumer pattern.

From the IDE side: long live the quick drop.

Best set of features: Synchronization objects and structures. That upgrade (6.1?) will forever be the best.

Best underdeveloped feature: OOP. I *love* that its here, but it could and should be so much more.

I realize you maybe were being smug owing to the window title, but that does indeed look like it could be LabVIEW 3, back when it was Mac only. Things were...different back then.

This is pretty basic, but any chance you've tried setting the files read-only on disk? A less convenient option might be locking diagrams without a password?

That thought scares me, I don't know if I trust the IDE not to get annoyed when it attempts to modify a read only file. Besides, the library still gets worked on from time to time, I'd rather not have to reset the flags each time.

Therefore it's just LabVIEW putting an erroneous 'dirty flag' on the lvclass. We don't bother to save them, but it is quite annoying.

I'm aware of those changes, and have posted about it before. But in this case, the files actually are changing, hence the need to do SCC reversions. Next time it happens, I'll run diffs and see if there actually is any difference beyond timestamps I suppose.

I've been ignoring them too for ages, mostly because I was developing the libraries in tandem with the core project. But now I'm trying to pin down one of the libraries to a static tag, so I explicitly don't want my library to change, even if it is one of these phantom changes. I've done similar comparisons and seen the same results as you, Daklu.

It would be neat if I could include a library as read only, to force LV to discard any changes it thinks it makes, might be an idea exchange entry brewing...

This has happened to me a few times now, but I'm not sure this behavior is intended or a manifestation of larger problems I've been running into with the IDE.

I have some reuse libraries that have classes in them, these are actual lvlib files that have some public classes exposed.

In a project, I include the libraries, and extend from the classes defined in the livlib files. After working for a bit, I go to do a save all, a bunch of stuff saves. I then go to commit my changes to source code control, and find that my re-use libraries have been modified. So I then shut LabVIEW down, revert the library changes via my SCC, then open up the project to confirm everything is a go, then do the commit proper.

Why is it LabVIEW is modifying the base classes? Is this normal?

When this happens, the library files that are modified are always the base lvclass file and some of the base's dynamic dispatch VIs that I was overriding in the extending class. I'll re-emphasize I had not explicitly made any changes to the base class. Reverting the base class files via SCC has no apparent effect on the project: loading the project again does not trigger any automatic changes to the base files. They just seem to get saved for some reason the first go around?

I don't know what to expect by posting this, it seems I've run into so many weird things in my dealings with LabVIEW OOP, there must be something I'm doing that is just wrong. But surely I'm not the only one though?

-m

Things like this make me wish I had maintained my cert.

Haven't played with pipes yet (too short on time), but I gave up on ever obtaining the standard output. Research into Windows architecture seems to indicate that GUI applications just aren't initialized with the Standard I/O/E streams, so it seems futile to obtain them. I was hoping that launching the application from a command line would make the OS initialize the streams, but no luck so far...

So I settled on creating my own console. Kudos goes to the several posts referred to above, they helped point me in the right direction. Not sure how this will translate if it's plopped in a 64-bit application, if someone cares to test it that'd be great (my guess is WoW64 will take care of everything, but you never know...):

It's a one-stop shop for console output. The snippet will create a console if one doesn't exist already, then write a string to it. You need to supply your own CRLF sequences. The snippet will also change the window title if you supply one.

One bad thing about consoles is they're meant to be attached to a process, and when the one (and only) console exits, the OS kills the process. Hence the VI also disables the Ctrl+C/Alt+F4/Close commands/handlers. This means (unfortunately) that once open, the console will persist until the process that created it returns. If you're in the IDE, it means you need to quit the entire IDE. For an application, the console will vanish when your application returns. Even gracefully detaching your process from the console (via kernel32.dll:FreeConsole) will cause your process to terminate, as far as I can tell...

Cheers,

-m

Native no. Here's a post a little while back that does what you want using magic.

http://lavag.org/top...dpost__p__70995

Thanks! I forgot about that gem...

Can any executable do this? I don't recall ever seeing one able to differentiate.

I'm not aware of being able to do it in other languages/RTEs. You never know though, I thought maybe the presence (or lack) of a standard output might provide a hint as to how the executable was invoked.

I'm curious, what's your use case?

Nothing special. I have a LabVIEW executable that responds to command line arguments. I wanted to print out a usage summary if invoked without arguments. Also want to print out debug messages over the course of execution and allow redirection to files etc. I wasn't sure that if there was a stdout in LabVIEW if printing to it would force it to show if a command line wasn't used. Seems like a moot concern now though.

I'll review the other thread again and see if I come up with anything.

Thanks again,

-m

Here's a quick one: Is there a native way in LabVIEW that I can first of all tell if my built application was launched via the command line? Also, is there a native way to print to the standard output if it was?

Thanks for the info, Paul.

Note that LabVIEW 2010 does not support the reverse process (automatically replacing a .lvlibp with a .lvlib), so be sure you really want to do this before you make the change! (We have an open support case with NI to do just that. The AE wrote a scripting VI that does much of this, but it doesn't yet work for certain pieces.)

I noticed as much. I switched to a packaged library and it went off without a hitch*. In addition to the inability to go back to an lvlib, I don't see a clean way to switch from say a debug version of the livlibp to a release version.

*Except for a pair of internal .cpp errors during the course of the build, but LV does that so often for me I don't feel like it's working right unless I see an error dialog in response to any arbitrary action beyond wiring or dropping VIs. But that's another story, and despite the errors, the packaged library does get produced and is usable...ish.

In our case we found the following with packed project libraries in 2010:

1) Projects took much, much longer to open (20 minutes in one case!) after we replaced .lvlibs with .lvlibps. (Yes, the project mentioned was big but it didn't take nearly that long to open when we just had a .lvlib.)

Yes! I'm finding the same. My project opens pretty snappy still, but when I open a VI to edit it, it is very slow. The entire IDE begins to crawl, to the point where window dragging becomes painful or even impossible in some cases. Not impressed.

For these reasons (worse performance instead of better, lack of flexibility to revert callers to link to .lvlibs--which is exceptionally limiting and was in our case quite costly to fix, no benefits whatsoever), we managed to revert our .lvlibps to .lvlibs (the AE's tool got us most of the way) and have abandoned .lvlibps entirely, at least in their current instantiation. Honestly, I wish I hadn't wasted my time with packed project libraries as they are in LabVIEW 2010. That was just a big mistake on my part.

I'm about ready to throw in the towel as well after only a few hours. The edit-time performance of the IDE is just plain unacceptable now that I've started dealing with the packaged library. I'm also concerned about switching out debug/release versions, or committing any changes since reverting to a normal library as you implied is not supported.

-m

Recently when I was in a discussion with a colleague of mine, the issue of packed libraries came up, and I’m getting a little nervous. A few questions:

What happens to namespaces? I have LibraryB.lvlib that uses classes from LibraryA.lvlib. If I make LibraryA into a packed library, do the inheritance chains in LibraryB all break because instead of LibraryA.lvlib:SomeClass.lvclass, I now have LibraryA.lvlibp:SomeClass.lvclass? That is can the packed library serve as a drop in replacement? It’s not too big of a deal if it can’t, I can go around and change all the classes this one time.

What happens if a packed library include the same VIs from another library which is also used by a project that uses the packed library? Say LibC.lvlib is used by LibD.lvlibp. If I then need both of these in my project, do I run into problems because ultimately two versions of some of LibC will exist? Or does namespacing prevent the ambiguity from arising (though at the expense of having multiple copies of the same VIs in different namespaces, which I might add can become very inefficient with common re-use objects)?

I see the benefits of packed libraries, but I’m also very skeptical that they won’t complicate the project or just make everything implode on me. After reading through threads like this one I get the impression I’m not the only one with some questions about these beasts.

I’m still having trouble convincing myself that packed libraries bring anything useful to the table that a normal library won't do-- or which won’t be offset by the headaches which will be caused . I’m looking to see if anyone will point out pitfalls that won’t be immediately obvious when I get around to at least trying to implement packaged libraries.

Thanks,

-m

Resurrecting this...

I needed to evaluate the version number of my objects at run-time so I've been parsing the flattened data and came across a slight inconsistency in the discussion.

a) The PStr is a length byte plus the text, so that is 17 bytes, not 16, and thus padding is required.

b) The first byte, 0x12, is the total length including padding: 18

c) The second byte, 0x10, is the total length not including padding: 16

d) Thus 18 + the two length bytes = 20

Take for example the Bacteria.lvclass we have been discussing, which yields the following flattened string (in hex words):

0000 0001 1210 4261 6374 6572 6961 2E6C

7663 6C61 7373 0000 0000 0000 0000 0000

The name section is highlighted in blue. The first byte of the name section (0x12) is the length of the entire name section including the size byte, but excluding the padding. The following byte is the length of the first PString, etc as described before, however I'll say that when dealing with qualified names, the colon character is not encoded (rather the qualified name appears as two distinct PStrings, with the colon appearing in neither). There is an additional word of padding added after the name segment to align with a four-byte boundary, then the four version words are present.

For example, a class called MyClass.lvclass produces the following bytes:

0000 0001 110F 4D79 436C 6173 732E 6C76

636C 6173 7300 0000 0000 0000 0000 0000

Note the name section is shorter (0x11 bytes), and the padding has increased to three bytes to align with the boundary. In both cases, the version words start at 0x18 bytes (red).

Both of these examples are generated by just dropping a class constant on the diagram, hence the 0.0.0.0 version number (and the first four bytes == 1).

Now what struck me while playing with this is that there seem to be two levels of default value. For example, if we now take the wire and operate on it explicitly, but make sure the class value is still default, we get a different data string (using MyClass.lvclass again):

0000 0001 110F 4D79 436C 6173 732E 6C76

636C 6173 7300 0000 0001 0002 0003 0004

0000 0000

Now we've recorded a version number of 1.2.3.4, and we also have a data segment (in green). The data segment starts with a U32 stating the length, which in this case is zero, meaning no data, or a default value (for this specific version?).

Now if we actually operate and store non-default values, we get what I'd expect according to the documentation and discussion in this thread:

0000 0001 110F 4D79 436C 6173 732E 6C76

636C 6173 7300 0000 0001 0002 0003 0004

0000 000C 4009 21FB 5444 2D18 1234 5678

The data string stores the length (0xC) followed by twelve data bytes.

Figured I'd clarify this. A default value does not always produce a version of 0.0.0.0. Example code is attached, LV2010.

-m

TestBinaryObjects.zip

Never used WebServices either, but can you not encode several pieces of data into a single input? Encode it on the client and interpret it in your VI. Ugly I know, but I don't think you can get around the hard limit of available connector types.

You pretty much need to use a variant, or of course have an army of polymorphic VIs which demand every type be accounted for.

I have done what you're describing using variants. They do have meta information, which you take advantage of. I don't have the info handy, but there is a library meant to handle variants, I believe it is called VariantType.lvlib and is somewhere in your vi.lib/utilities folder. A word of caution though that since these VIs are not on the palette NI might change them some day...

The key is recursion. Take the variant, act accordingly if it is a primitive type (bool, double, etc). If it's a complex type (cluster, array, waveform, etc) do what you need to do then recurse on the contained type(s).

Note because variants do involve a lot of copying, this can get prohibitive for deep/large data structures. You will never get as good performance as doing a "hardwired" VI for whatever your type is.

I ultimately abandoned my variant approach because serializing my main data structures could take minutes using this method (compared to seconds by keeping things type specific). I still use it for simple or small data structs though.

Gotcha. The answers are indeed "yes" to both, a library containing several classes.

Cheers

-m

Any ideas on how to coax more information out of LabVIEW on this one?

When I open my library, immediately the dirty little "*" appears in the project explorer. Trying to close the project prompts me to save my "changes", shown above. If I save the file, the time stamp on the file indeed does change, but the contents do not. This means the project is forever dirty.

Running a checksum recursively on the library folder shows no changes in any of the file contents. However, when the file is included in a project, the problem does not happen.

Ideas?

Thanks, I'll see what I can do. I think I'm working with a different problem as the property names or VI names most definitely had not changed. Something else is amok here...

Resurrecting this thread...

In particular, my VIs using property nodes of class DVRs will often break because somehow a property node "blacks" out. What I mean by this is the property node text will be black, and it will be impossible to wire up anything to the value part of the node. I'll have to go back to the VIs that define the property node, force some kind of recompilation (usually by swapping connector pane terminals back and forth), which will then usually allow the property node to work. I've had methods in library classes break because of the property nodes used in their methods when working on child classes, forcing me to go in and re-compile the library VIs when nothing in the base class has changed. This can get particularly infuriating with complex hierarchies...

If this is the problem that I think you're describing, I've got a fix which is still being reviewed. (The person doing the code review has been out sick for a few days). The basics of that problem is that behind the scenes the properties have different names for if it's dynamic and static and some property nodes weren't getting updated when you change the properties from dynamic to static or static to dynamic. The problem only happens when you change the class input before you change the class output. This is CAR 248637 if you're interested.

I've managed to capture a case where the problem I described happened. This is the aftermath of it:

I was working on a child class when a base class method (above) broke because of a property node. I had been making several changes to the child, so while I don't think anything in the base class was explictly operated on, I could be wrong. The property node methods definitely were not touched. The node just...broke, taking all my class implementations along with it.

The node magically fixes itself if I open the VI that defines the read method and force a recompilation by swapping a connector terminal back and forth, for example.

I'm wondering if I can possibly get this code to NI to evaluate if this is indeed the same problem addressed in CAR 248637? Mr Mike perhaps?