Darren

There are a couple of internal errors in LabVIEW called "DWarns" and "DAborts". You'll get that dialog on launch if a DWarn or a DAbort occurred on the previous run of LabVIEW. A DAbort is a crash, but a DWarn could be some internal error that LabVIEW logged, but LabVIEW was still able to continue operating normally. If you click the "Investigate Internal Error Now" option, you'll be taken to a webpage that will perform a search of the NI Support site to see if that internal error has any KnowledgeBase entries associated with it. Assuming your error does not, you can submit your log file to NI Tech Support, who sends all of these error reports on to LabVIEW R&D. If you can reproduce the DWarn/DAbort with some simple steps, it would also be helpful to submit a sample VI (if applicable) along with the error log. Hope this clears up the issue, let me know if you still have any questions. -D

The 8.2.1 installer is a full installer, so all of the VIs it installs are already mass compiled in 8.2.1. The install takes longer than an 8.20 install since the 8.2.1 installer actually uninstalls each 8.20 component before it installs the 8.2.1 components. -D

QUOTE(gleichman @ Apr 9 2007, 02:51 PM) There are other Report Generation Toolkit LLBs that get overwritten by the 8.2.1 install besides NIReport.llb. I recommend uninstalling the toolkit first, then installing 8.2.1, then reinstalling the toolkit (this problem is mentioned in the 8.2.1 readme). -D P.S. - We are looking at ways to ease the LabVIEW/RGT integration pains in a future LabVIEW version.

QUOTE(crelf @ Apr 5 2007, 03:12 PM) I'm guessing jaec gets his crack from here. -D

I've never seen that show before...that is definitely my kind of show! Just to get a clarification on the rules...you have to use all 6 numbers in your solution exactly once? And only simple operations (add, sub, mult, div) are allowed? The target number is anything between 0 and 999? What's the name of this show? Looks like it's an old show, and I'm guessing they have other categories on the show besides math (judging from the encyclopedia or dictionary on the host's desk). Good stuff, -D P.S. - I've already written LabVIEW code that solves a puzzle like this, although simpler. I have a game called Numbers Challenge where you are given a card with 4 numbers between 1 and 9, and you have to try to reach the target number (anything between 0 and 20 is possible) using only simple operations and all 4 of the numbers on the card. I wrote a VI that proves that all targets between 0 and 20 are possible with every card. A math whiz gave me the game a long time ago, and I didn't believe him when he said any number between 0 and 20 was possible with every card...but LabVIEW proved he was right!

Here are a couple of screenshots to illustrate the method I described. These are actually snippets of code from the VI Analyzer UI. Here is the code during initialization of the main UI that bundles control references into the typedef cluster...these are references of any controls and indicators that I need to programmatically manipulate throughout the execution of my UI code: http://forums.lavag.org/index.php?act=attach&type=post&id=5392 This cluster is wired to the border of my main event structure for my UI. In any case of the event structure where I am programmatically manipulating UI elements, I simply unbundle whatever references I need from that cluster. If I have a subVI that needs the references, I pass the cluster into the subVI via its conpane, and then unbundle whatever references I need within the diagram of the subVI, as seen here: http://forums.lavag.org/index.php?act=attach&type=post&id=5393 I hope these screenshots help illustrate my method. It's very easy to deal with front panel controls with VI Server when you have access to any of the control references you need at any point on the diagram. If there's another control I need access to, I simply add it to the Bundle By Name (and the typedef). To make things easier for me, I also keep the control references organized alphabetically in the typedef cluster by changing the Cluster Order whenever I add elements to the cluster. This gives me an alphabetized list whenever I operate-click on an Unbundle By Name to select the proper reference to unbundle. Let me know if you need any more clarification on this method. -D

The way I get around this issue is to create a typedef cluster containing control references to any control I wish to programmatically manipulate within my application. I bundle by name all my control references during code initialization, then unbundle the references whenever I need them in other places in my VI. If I need any of these references in a subVI, the typedef cluster is on the conpane of the subVI so I can unbundle the reference(s) I need within the subVI. Since it's a typedef, I can add control references to it as I develop code. This avoids any array searching for references and makes the code very fast. This is the approach I take in all my UI VIs (i.e., any app where I will be programmatically modifying UI elements). -D

...and while we're talking about breakpoints, don't forget the nifty "Remove Breakpoints from Hierarchy" feature in LabVIEW 8.2 that will remove all the breakpoints from the hierarchy of a VI, so you don't have to go searching for any breakpoints you may have left in the diagram of your VI (or any of its subVIs) while debugging. -D

Hey now, the fact that I work at NI has absolutely nothing to do with the fact that I'm totally pwning all of you in the LAVA arcade... -D P.S. - And to further fuel the flames, I will go on record as saying that there is NO WAY you people can EVER dethrone me as the LAVA arcade champion. NO WAY! Well, I guess you'd have a chance if Michael reset all my scores...

I've only made it to level 14, and I noticed that the left-most pipe seems to be the "fake" one. I only determined this by losing, then clicking "retry" after losing, since the "retry" lets you start over on the same level you just lost (unfortunately, your score is reset). -D P.S. - As for having "waaaaay too much time for playing games in the arcade", I'm currently in the middle of 5 weeks of paternity leave, and my older kids (not the newborn) *love* to watch me play [wiki]LAVA[/wiki] arcade games. Plus, it's a good time-killer when trying to rock a baby to sleep...

Sounds like a good feature request...the List Folder function currently does not support specifying multiple patterns on the 'pattern' input. -D

Wow, I didn't know the menu ring worked with Call By Reference nodes. But I just tested and apparently it does. -D P.S. - In my original post, I mentioned that the order is "top-down"...actually, the top of the hierarchy of calls appears at the bottom of the list, and the direct caller of the VI with the breakpoint is at the top.

Assuming you're not dealing with dynamic VI calls, you can view the call stack ring in the toolbar when a breakpoint is hit in a VI. It's normally the font ring, but when you have a running VI that is paused at a breakpoint, it becomes a call stack ring, with a top-down list of the VI call hierarchy all the way down to the VI with the breakpoint. -D

This same question was posted on the NI Forums last week. I don't know if it was by the same guy or not. Here's my reply. -D

Unflatten has been pretty stable for me in LabVIEW 8.2. But fine, here's another way, although this one is 48x48 pixels instead of 32x32: This was my first idea, and would probably be the easiest to wrap with one of these mythical "XNodes" I keep hearing about. -D

Hmm...I know nothing of these mysterious "XNodes" of which you speak, but I can accomplish what you want with a built-in function and a hidden string constant: There's an empty string hidden underneath the function and wired to to the required binary string input. You can wire whatever you want to the type input, and you'll get the default value of the data type as an output at the "value" terminal. Turn this thing into a Merge VI, give it a nifty icon, and voila...a "default value retriever". If you insist on an XNode (which, again, I know nothing about), you could wrap this trick up pretty nicely and just use the automatic type propogation of XNode terminals, if in fact such a thing existed...it would get rid of the hidden string constant, anyway. I know this won't get me a pitcher of beer, but maybe a bottle of ginger ale? -D

Hi John, I don't have a way to copy the "attributes" from one control to another...it seems you would just need to create a VI that uses property nodes to get/set all the appropriate properties of the controls. As for the tree contents, I wrote this VI a while back that will duplicate the contents of one tree control into another. It's attached below, saved in LabVIEW 8.0 format. Let me know if you have any feedback, since I plan on shipping this VI in the vi.lib\tree folder in a future LabVIEW release... Hope this helps, -D Download File:post-4441-1169769387.vi

I posted a VI Analyzer test on the NI Discussion Forums that will detect any terminal on the diagram that is a Variant data type that also has a coercion dot. See here. -D

Hmm, apparently I didn't quite grasp the effect my retirement from nugget-writing would have on the LabVIEW community. You guys go ahead with whatever plans you make for writing your own nuggets, but as you can see here, my retirement lasted all of a week. Yes, the nuggets will still be (occasionally) cooking... -D

Ah, ok. In that case, I don't know of anything you can do other than to extract each item out of the serial string and cast it to the appropriate datatype, then bundle all of those individual items into a cluster. I don't think you would be able to use Unflatten from String directly because the string data doesn't directly correspond with a cluster datatype containing all those elements. -D

Are you looking for the Bundle By Name function? That seems to be what you could use to replace all the other code in your VI. -D

Make sure to let NI support know that it's not actually a bug, but an error in your code. -D

The string you're generating for the Value of the tree is incorrect. When the value goes down to 1, the text you display in the tree is "Cycle A - 1 execution", but if you probe the string you're wiring into the Value property, it is "Cycle A - 1 executions". Since this is not a valid tree tag, no line is selected. Also, I would recommend keeping an array of the tag names assigned to each row in the tree, and changing the Cell text for a row as it's changed, instead of re-writing the entire contents of the tree every time the number for a single row is changed. -D

Yes, this method is handy. It's only available in LabVIEW 8.0 and later. If you need this functionality in LabVIEW 7.x, there's a VI that does exactly the same thing in vi.lib\tree. -D

Maybe that has something to do with the fact that LabVIEW is way more comprehensible than C++? -D