Jim Kring

My guess is that it will increase around August

My bet is that it is a vi.lib thing.

I see that Mr mec (a.k.a "one hit wonder"), signed up for a new user account to anonymously spoil a very good joke. :thumbdown: PS - Excellent work, Michael! Yes, ehhhxcellent. :worship:

Right, and we only punish people who do the wrong thing. And since michael has not been punished, he must have done nothing wrong. :thumbdown:

Since I was addressed directly, I will respond. I had no knowledge of this and I am extremely upset. Michael must take us for a bunch of fools, if he thinks we are going to sit back and let this happen. I have notified my attorney, to better understand our rights and the implications of Michael's decision -- I will let you all know, as soon as I hear back.

We're just putting colin through a mild hazing ritual. He seems like a fun guy, so I'm sure he's up for it.

Michael wrote: > the undesirable posts are not removed by NI, so carefull about what hornet's nest you poke a stick at. Wow, being warned and a stung in the same post -- he ain't jokin' around

It's hard to tell, yet.

Colin, Here we go again. First you're feeding the homework hustlers and now this. Cheers, -Jim PS - PPS - Hmmm, Einstein was Jewish -- apha is off to a quick start. I wonder how long it will take before we get to enforce Godwin's law, this time.

Wink.

Status update... Status: Filed with R&D CAR#: 3VSACUV2

If you mouse down on a multi-column listbox column header and move the mouse slightly, while keeping it within the bounds of the column headers, it will cause the listbox vertical scrollbar to scroll up. Presumably this behavior is intended for selecting a row and dragging it up, above the upper-most row; in which case, you would definitely want this behavrior. I believe that the fix, is to filter this behavior if the user mouses down in the column header, rather than a (data) row of the listbox. <OBJECT CLASSID="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" WIDTH="212" HEIGHT="168" CODEBASE="http://active.macromedia.com/flash5/cabs/swflash.cab#version=5,0,0,0"> <PARAM NAME=movie VALUE="scroll_bug.swf"> <PARAM NAME=play VALUE=true> <PARAM NAME=loop VALUE=false> <PARAM NAME=quality VALUE=low> <EMBED SRC="http://forums.lavag.org/index.php?act=Attach&type=post&id=2498" WIDTH=212 HEIGHT=168 quality=low loop=false TYPE="application/x-shockwave-flash" PLUGINSPAGE="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"> </EMBED> </OBJECT> Test VI: Download File:post-17-1143588737.vi Status: Filed with R&D CAR#: 3VSACUV2 Download File:post-17-1143588422.swf

LabVIEW 8.0 stores palette edits in the LabVIEW Data folder (usually found in My Documents). Try looking in there -- you might want to delete all of this palette data.

Woo hoo :beer:

Status Update: This issue has been forwarded to R&D, for possible fix in a future release CAR#: 3VQD413A

The cat's out of the bag now, thank you! I hate keeping secrets (being a pretty "open" guy). Let me just say that I am very excited about this book (please, pardon my intrinsic biases). Jeffrey and I started out on the very solid foundation provided by the 1st and 2nd editions, we had a truly amazing team of technical reviewers, and LabVIEW (especially 8.0) is a truly great product that's full of amazing features (and, most of us have not even scratched the surface). Yes, Jeffrey is the fellow that planted the open source seed (for me at least) -- here is a link, were you can read up on the history of OpenG. I was very honored to be asked, by Jeffrey, to co-author the 3rd edition. Lastly, some weight has definitely been added to this book, as it has gotten quite a bit thicker Cheers,

There is a bug in That causes a failed conversion of the common path ".." (parent directory) to the specific (Mac OS X) path "::".Bug demonstration (only fails on Mac OS X) Download File:post-17-1143395405.vi Common Path to Specific Path.vi (with fix applied) Download File:post-17-1143395568.vi CAR#: 3VQD413A

Use the Application Item Tags. In this case, you want to use APP_SEPARATOR. Download File:post-17-1143199460.vi

Colin, Welcome to LAVA My favorite part about LAVA is that it is independent. It is not censured (NI can delete your postings for arbitrary non-disclosed reasons on the NI forums). I also like LAVA because contributions are licensed under the Creative Commons Attribution 2.5 License -- but, if I post on the NI forums, then NI has the right to (re)use my posting for whatever purposes they see fit (including possible marketing material), per the Terms of Use of the NI forums. I also like LAVA because it is a community created by LabVIEW users, for LabVIEW users -- it is community effort and participation at its best. Cheers,

Chris: Thanks for the heads-up on this. It's never too late for a good solution to a common problem :thumbup:

Sorry, I should have been more explicit. I was not trying to detract from dqGOOP -- I was just answering your question about whether OpenG, or anyone else, could legally use a similar implementation. IMO, a pure G GOOP implementation is best if it is open. Stay tuned, interesting things to come.

Darren: Thanks you for the answer, extra effort, and CAR number. Five more stars, for you

As you mentioned, dq was not the first to use queues for GOOP. And, the author has stated publically that it is a combination of ideas mentioned first elsewhere.

Right, you will need to make the input a Variant, which anything will coerce to, and then extract the string value of the variant using the Get Strings From Enum function in the lvdata (LabVIEW Data Tools) package.

Yeah, and purple's a fruit. mmmmm.... purple.....