mje

Definitely not whitespace: XMLSpy works very well, but forces artificial line feeds every 4096 columns. Hence a lot of the "lines" are not real. The <Val> element, for example is a 24248022 character "line".

Odd: &lt;Property Name="NI.Lib.Version" Type="Str"&gt;1.0.0.0&lt;/Property&gt; I'd expect with a version number of 1.0.0.0, for all mutation history to have been removed. Something though is being stored in the <Val> element. Unfortunately since the bulk of lvclass files are encoded binary data, hard to say what. But to answer your question, I've never seen anything like that before. I have a few classes in the hundreds of kilobytes area, but they're also loaded with mutation histories. I understand why mutation history is in LV classes, but I still don't like it. I'd much rather have a defined interface which gives me programmatic control over how LabVIEW creates/copies/mutates my data. But I digress, I can't even say that's the cause of your problem.

Brilliant! Thanks folks. It all works, but... What confuses me is this seems to be adding another layer of wrapping to the variant. When I used to run the code from my original post with the "Long" enumeration selected, I'd get a value of 0 in the Variant indicator. But when I add the To Variant primitive, I now get <Variant: 0>. Does this mean I essentially have a doubly wrapped variant in this case (A variant of a variant of a long)? I believe Tom might have been getting at this point as well. That's all fine and well, but what I find surprising is the code I have downstream in my real use case still works: I have a single Variant To Data primitive, which somehow resolves the doubly wrapped variant data type when I pass through a real bit of data. So that's all good I guess? Either way, things seem to work with the To Variant primitive added, though I can't say it's as I expect. I'm still of the school the invoke node should be able to apply the void type to the indicator as I have no problem passing voids through VIs if I'm not invoking get/set methods through VI server.

If it's any help, I only tend to get the error when visiting via my phone or tablet. I suspect it might be something to do with the rendering of the mobile version of the site?

For the code below: The invoke node fails with Error 1 on me when I execute the "Variant" case. That is Control Value:Set doesn't seem to be able to apply an empty variant to the control. This strikes me as a bug, or is there some esoteric reason this is an intended behavior? LV2010 SP1.

Works for me now!

Just wondering, when building an installer, a version number of at least 1.0.0 is enforced. Is this due to various OS requirements, or something NI decided to do? This has caused some issue, since as I've been iterating over the past few release candidates of my software (which have version numbers of 0.7, 0.8, etc), when an installer is created I'm forced to a 1.0 installer version. This means the user can't install the new version over the old one since the installer does version checking to make sure the new version is greater. So manual uninstallation prior to a new install is required. Not a big deal, mind you, but it would seem this could be mitigated by allowing installers to have lower than 1.0 version numbers. I know I've had a few support calls relating to a "broken" installer despite clear instructions to uninstall first...

Drop a string constant onto the diagram and right click it, then select the '\' Codes Display option. You can create a null/zero bit by typing \00: You can also right click and select Display Style from the Visible Items menu to indicate what style the string is being displayed in.

Yes, the monitors property is a 1-based index, the 0 value indicates whatever monitor is the primary. The workspace property is very useful, it takes into account the taskbar etc to yield the workable area the panel can occupy.

New problem: Using my method, the tool-tip does indeed come to the front of my application windows, but unfortunately brings every window from my application on top of other application windows when I make the call. Not a good thing, this means that inadvertently moving your mouse over an open window in my application will automatically bring it over all others if you happen to hit a hot spot. The property node Ryan indicated is not ideal because it unfortunately applies focus to the tooltip window, making the main window's border flash quite annoyingly as the mouse moves on and off hot spots in the owning VI. Back to the drawing board

Never noticed that property, thanks for pointing it out! I have a feeling that would work as well.

My guess is you'll have to use the xy graph. You'll need to convert your digital waveform to a compatible array, which usually involves either applying a special scaling factor and offset to transform the actual data, or using a secondary scale.

So I have a few VIs which I use as fancy tool-tip windows. Basically really small front panels that get moved around at will when the user moves their mouse in the owning VI. The tool-tip is set to a floating window via the VI properties, runs without borders, title bars, etc. There's no fancy Win32 stuff going on behind the scenes for these VIs. When I need the tool tips, I set the position via VI server calls, then make a call to FP.Open(False, Standard). Occasionally though, my tool-tips loose their "floatiness" (buoyancy? topness?). See the bottom part of the image below: I end up with not so helpful tool-tips as they end up hiding behind the front panel they're acting as tool tips for. Has Anyone seen this before? Anyone know what might be causing this behavior? -m By the way, I'll add that I have a work around wherein I call User32.dll:SetWindowPos each time I set the position of the tool-tip: But this seems like something I shouldn't need to do since the VI's properties are set to floating. Even when the problem arises, the FP.Behavior property still returns Floating despite obviously not being floating... Warning! Random conjecture ahead: I have no idea what causes this, but I've finally narrowed down a reproducible case which triggers it (sorry, can't post the application online). Ultimately I have a situation like this. 1. My main VI is open. All is happy. Sunshine, lollipops, all that good stuff. 2. The user asks to open a new VI, which is a second independent VI running asynchronously. That VI does some Win32 wizardry to make itself look like a tooltip window: (Those are calls to User32.dll:GetWindowLong and User32.dll:SetWindowLong). 3. I go and do something else in another application. For now, let's say I interact with my Chrome window so I can post on Lava. 4. I go back to my main VI. Move my mouse and my tool-tip window is now suddenly at the bottom of the z-stack. Darn.

There isn't one. But the bug in Format Variant Into String__ogtk.vi arises from the use of a legacy VI in which gives rise to the error. Sorry, haven't used the OpenG libraries in a while and don't have them currently installed, but the offending VI is the one circled below: I believe the NI replacement would be VariantType.lvlib:GetTypeInfo.vi and its associated typedef control. I'll also point out that it is pretty trivial to implement your own Format Anything method once you start using the GetTypeInfo call. A simple case structure on the returned type and you're off to the races. Here's some code I've been using for the last year or so: Wouldn't be too hard to extend that to duplicate all the functionality of the OpenG VI.

I believe all of these issues arise from the OpenG library not being able to distinguish between timestamp and waveform types. In my opinion the legacy OpenG VIs which now have NI equivalents should be retired to avoid errors like this.

Hoping someone can help me out here, it's been a while since I've actually done any DAQ in LabVIEW. I have a DAQmx task which I might reuse an arbitrary amount of times. When it comes time to start the task, I do a registration on the EveryNSamplesAcqIntoBuffer event, then go off and start the event. Something like this: When I'm done, I unregister for events, and stop my DAQ. Works beautifully the first time. When I try to restart the task, I get an error: So it seems that despite calling the Unregister For Events primitive, DAQmx still thinks that the task has a registration pending. Is there a special step I'm missing that I should know about when dealing with DAQmx tasks? I should note, I have a workaround, wherein I only register for the event when I first configure the task, not every time I start the task. But it seems like I should be able to do it the other way where I register when needed, no? Or is it a case of once a DAQmx task is registered, the only way out is to clear the task and start again?

I can indeed do as much, but that only appears to modify the number of visible rows by resizing the tree. The scrollbars still size to the contents of the "old" columns, so the user will always be able to scroll out to the blank column. The best I can do is size the empty column to a few pixels wide. Unfortunately it's looking like I have to delete and recreate the control. Unfortunately this might introduce defects if I forget to set the new control's properties exactly the same as the original, so I've been holding off on doing that. Yet another "I hate LabVIEW UI elements" vote...

I have a tree control in one of my user interfaces which I just removed a column from. The problem now is that I can't seem to convince LabVIEW that I actually don't want that column. My tree always has an empty column at the right, and the scrollbar always sizes for this column: Surely there's some way of convincing the IDE I actually don't want that column? Short of replacing the control and reconfiguring a new one (hoping I don't break anything in the process), I can't think of any other way...

The lack of any reflection in LabVIEW OOP has been one of my harshest criticisms of the system since it's inception. I for one would welcome our new reflective overlords... I'm not saying I don't like LVOOP, I love it. But there are some features that are surely lacking compared to more mature OOP implementations. We can be forgiving though since LVOOP is in its infancy. The fact that it even exists, I consider a triumph worthy of praise to those at NI who pushed it through development. -m

Sounds fun. Just wondering if these mystery breakpoints perhaps occur inside in-place element structures? Several times I've observed strange breakpoint or stepping behavior when in IPE frames. I find doing any debugging in them is at best rolling the dice unless I wrap all of the code in a subVI, and place my breakpoint in the subVI scope.

Excellent ideas. Thank you both.

Is there a native way of determining what the localized decimal separator is? I have a combo box which I'm hacking up to be a pseudo-numeric control, insomuch as I want to be able to enter any positive real value, or allow the user to select from a set of pre-determined special values which are text. So I populate the Strings[] of the combo box with the relevant strings, and leave it to the user to enter any numeric values on their own. When the value changes, I parse the value for a numeric if it's not one of the matched strings, then re-write the parsed value back to the control to make sure whatever is being displayed matches with the value I'm tracking on my data wire. Works pretty well. The only problem is the user can of course still enter anything they want in there. If I have the strings "Fee" and "Fie" available, the user can enter "Foe" by typing it in. This doesn't cause a problem since I parse and write back to the control, but I'd like to be able to have it be more like a numeric control, where you can't enter invalid characters. Try to enter any non-numeric related character into a numeric control, you can't do it. I could easily implement this via the Key Down? event structure frame, but how do I distinguish what a valid decimal character is? In a North American locale I'd allow a "." character, but in France I wouldn't, for example. I'm aware of the %.; %,; and %; codes which help with scanning an entire string for a number, but in this case I'm trying to match only a single character and I don't think they are of much help.

Yes, I was referring to the actual Object value (not a reference). My understanding of an Object is there's a hierarchy of version numbers for the data in the object, insomuch as each level of an object's inheritance has an associated version number for the contained class data. Come to think of it though, the same could be said for the qnames I guess. I suppose what would be ideal is if I could pass in any Object (value) and have a primitive that returns the qname and version of that object. However it might be interesting to also retrieve an array of qnames/versions for each level of the object's inheritance chain. Not sure what I'd do with that information off the top of my head, but that's never stopped me from academics before.

Absolutely. It would also be great to be able to get back an array of version numbers for the class hierarchy of any arbitrary Object. I at one point had code that makes an attempt using the flattened data, but wasn't terribly robust... The qualified name and version numbers would go a long way to making any custom serialization code very robust in that we could use the embedded information in the actual class data.

I don't believe there is a built in call that does this. Your code looks very similar to the code I've been using to do the same thing. As far as I know the only way to do it is decode the binary strings in the flattened data: