jaegen

I have to agree with AQ. I would support changing the sequence structure to have a (much) thinner border, but I think the null wire concept just opens up a whole bucket of confusion. You could always create a null class, with a thin light-grey wire. (I realize that still means you have to create actual connector pane terminals for it). Jaegen

QUOTE (brianlachlan @ Sep 24 2008, 11:36 AM) ... must ... resist ... urge ... to ... feed ... troll ... Jaegen

One related little-known trick: If you change to the "Operating" tool (the little hand) before you first click on a connector terminal, the tool will magically change to the "Wiring" tool permanently, and you can then at least go back and forth between controls and terminals more quickly, since you can click on a control first, rather than having to always click on the terminal first. Jaegen

I have to chime in and say that we (me and my wife) have greatly enjoyed the LEGO games (Star Wars and Indiana Jones - with Batman coming out soon), and Mario Kart Wii. I'll also ditto Darren's remarks re Super Mario Galaxy - it's fabulous. Jaegen

I think you need to right-click on the second "Key Down" registration in the "Register for Events" node inside the "<RFID ch>: Key Down" event and uncheck "Lock Panel Until Handler Completes". You should probably do the same for the node outside the loop as well, just for consistency. Jaegen

LabVIEW is now in the language list. :ninja: Jaegen

This is actually a known bug. Quite annoying, but once you know it exists you can work around it. Jaegen

While I agree with most of his points, as a father of a 4-year old daughter (and therefore having survived through many episodes of Dora the Explorer) I do feel it's my responsibility to point out one thing. He glosses over an important detail in his "broken screen" story: Several scenes in every Dora the Explorer episode feature an animated mouse pointer, which moves around and "clicks" on appropriate parts of the scene. The 4-year old is simply looking for the mouse that's moving the pointer (having obviously been exposed to a mouse-driven computer already). Jaegen

For anyone else who wasn't quite clear what PaulG is getting at: 99942 Apophis is an asteroid that might hit earth someday. Jaegen

There's something wonderful about the fact that the link to the "Bug Fixes" page is currently broken. :thumbup: Jaegen

I've had this exact issue for years and kept forgetting to ask here - thanks! Here's hoping some smart person here knows the answer. Jaegen

QUOTE(crelf @ Feb 29 2008, 11:39 AM) This brings up a small question I've always been a bit uneasy about: Within a given VI, does execution highlighting show us exactly what order things will run in once execution highlighting is turned off? (Assuming there are no other parallel threads running outside of the VI I'm watching). Jaegen

Hmmmm...

It makes me laugh cry.

QUOTE(Justin Goeres @ Nov 5 2007, 08:32 PM) Now can you make it account for "colspan" and "rowspan"??? Jaegen

I'm seeing something similar to this: I built a class hierarchy inside its own library (.lvlib), then built a test project which included the .lvlib and derived its own child classes for some of the original classes. I'm now using the .lvlib in a new project, and one of the "test" child classes is showing up in the dependencies under "Items in Memory" when I load the new project. This child class was a real dependency briefly, as I copied over one of the test VIs into the new project, then deleted all references to the test class. If I recreate the new project from scratch (with the cleaned-up test VI), the test class doesn't show up. Jaegen

QUOTE(hskupin @ Oct 29 2007, 03:39 AM) Henrik, 1. I found the same issues with the command line - here's what worked for me after much trial and error: (the position of the quotes seems to be important) C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe "C:\Program Files\National Instruments\LabVIEW 8.5\LabVIEW.exe" %base %theirs %mine %merged 2. I've actually never used the "Resolve..." command. Just deleting or moving the files you don't want, and making sure the one you do want is named properly will "resolve" the conflict as far as SVN is concerned. Jaegen

Systems.Windows.Forms.Screen doesn't appear to have any constructors. You need to drop a .NET constant (right click on a .NET constructor Refnum output and select Create>Constant), then right click on it and click "Select .NET Class". Make sure the "Show Creatable Objects Only" checkbox is cleared, and the "Screen" class should show up. Jaegen

Could it be related to Known Issue #3IKBUP99? Jaegen

QUOTE(Val Brown @ Sep 17 2007, 02:30 PM) I have to respectfully disagree ... if only because I've already used this trick in (soon to be) running code Jaegen

Confirmed here. In fact, if I uncheck "Allow Debugging", run it (doesn't work), then re-check "Allow Debugging", it still doesn't work. This may be 2 bugs - one which causes the incorrect behaviour when "Allow Debugging" is unchecked, and another due to constant folding which "remembers" the incorrect array after "Allow Debugging" is re-checked. Jaegen

QUOTE(tcplomp @ Sep 15 2007, 08:24 AM) Except that I actually want to use multiple instances of an XControl inside a cluster typedef (along with other stuff) - the VI I attached was just a demo. Jaegen

It appears that an XControl inside a cluster type def never fires the "Data Change" event. The attached VI uses the demo thermometer XControl inside the attached type def. When I run the VI as it is, nothing happens. If I right-click on the cluster and disconnect it from the type def, the temperature rises as expected. Is this a bug? Jaegen

This is definitely my favourite so far. Jaegen

QUOTE(crelf @ Sep 12 2007, 08:06 AM) I think AQ's "friend" didn't realize there was an "Array Size" function built into LV, and was calculating them him/herself with the method shown. Jaegen