Jump to content

jpdrolet

Members
  • Posts

    367
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by jpdrolet

  1. QUOTE(Aristos Queue @ Sep 17 2007, 04:37 PM) Thanks for the statement of the rule. Can you elaborate on other rules on Variant comparison? As to why the same data is stated different when hosted in different typedefs?
  2. QUOTE(crelf @ Sep 14 2007, 01:15 PM) It seems to be a bug or at least an inconsistent feature... When evaluating Variant [Path "ABC"] == Variant [Path "abc"] it returns True which is the expected value on Windows, while flat data are different .
  3. QUOTE(crelf @ Sep 14 2007, 10:02 AM) You need a comparison that would match TRUE if and only if compared the appened element. NaN will be different from all elements including the appened one. However, while NaN != NaN, you will find unexpectedly that Variant[NaN] == Variant[NaN]. Is that a bug or a feature? It seems that variant comparison strictly requires the same type but makes a typeless comparison on flat data.
  4. QUOTE(PJM_labview @ Sep 13 2007, 04:57 PM) An error cluster won't match because the type is different, I32 vs CDB for the "error code". To be sure to have a different type, index an array element and bundle it in a cluster for variant comparison. By the way, anyone ever wondered why error code 42 is "Generic Error" ???
  5. QUOTE(young grasshopper @ Sep 12 2007, 03:28 PM) Nice solutions have been proposed but I just want to say that using enums as numbers is a bad practice. Enums should be used as labels and your programming should not depend on their numeric values. In few months when you'll look at your diagram and ask "when does the state machine make a transition to the state 'do_this'?" and you won't find any state enum on the diagram set to 'do_this'.
  6. QUOTE(Justin Goeres @ Sep 12 2007, 02:49 PM) I think an even lesser known trivia is to use Scan from String to read an enum string
  7. QUOTE(yen @ Sep 10 2007, 02:19 PM) I'd say that if someone has access to the EXE and its INI, security is already seriously breached... The VI Server can be stopped programmatically using app property nodes so it is good to stop it at program initialisation. However one can still drag and drop any VI on your running app (or execute the command line) to run a VI to reenable the VI Server programmatically...
  8. QUOTE(Eugen Graf @ Aug 27 2007, 04:42 PM) Does it work when a VI with its BD is run by an application?
  9. I don't like embedded cases so the following structures most closely look like an elseif structures: http://forums.lavag.org/index.php?act=attach&type=post&id=6681
  10. QUOTE(alfa @ Aug 14 2007, 05:24 AM) alfa, June 2006: 97.7% of population are at animal level. alfa, April 2007: 97.73% of population are at animal level. alfa, August 2007: 98% of population are at animal level. I clearly see a trend here... At current rate, 100% of population will be at animal level in 2½ years.
  11. QUOTE(Aristos Queue @ Aug 7 2007, 02:14 PM) The For Loop executes N times and the While Loop executes N+1 times when not stopped by the VI output
  12. QUOTE(rkanders @ Aug 2 2007, 09:14 PM) OpenG Config VIs are only a variant wraparound vi.lib's Config VIs. I've benchmarked that the latter are the real performance hog, e.g. the data handling of keys and sections. I'll admit that the variant wraparound could benefit some performance optimization itself but it would be marginal unless the data handling kernel is improved.
  13. A linux flavor is coming too. MPX
  14. Variant to Flattened String and Flatten to String both act exactly the same when used on typed data. When used with a variant input, Variant to Flattened String returns the flattened string of the data contained in the variant, same as is contained data was input to Flatten to String When used with a variant input, Flatten to String returns the flatttened data of the variant, e.g. the flattened data of the contained typed data plus the flattened type descriptor of the the typed data. When you send that thru TCP, the variant is exactly reconstructed with its contained typed data so it is safe to use.
  15. QUOTE(PaulG. @ Jun 27 2007, 10:04 AM) He can but He won't. Why would He break His omnipotence?
  16. When you open the VI reference, wire 1 to the option input. From the help for Open VI Reference: QUOTE
  17. I am still confused... Can you fix THIS: http://forums.lavag.org/index.php?act=attach&type=post&id=6238 Please?
  18. QUOTE(Ben @ Jun 25 2007, 06:15 AM) In fact, the leak was not localized until you observed it in the first cut...
  19. QUOTE(xtaldaz @ Jun 20 2007, 07:36 PM) It can't be him, the Twilight Zone is the fourth dimension (da da du du da da du du). Anyway, the Universe has yet found a faster way to maximize its entropy...
  20. Your approach is correct. The use of variants wouldn't help much since you would still have to retrieve either the format string or the displayed string of each control anyway. You can take a look at OpenG's "Format Variant into String" that formats a variant scalar input into string. You can specify the format string either at the input or as a variant attribute.
  21. Strictly speaking there is still a possible race condition in your fix since nothing garantees that the char offset terminal is written before entering the loop and reading its local. The safest way to implement this is to add a shift register in the for loop and feed it with the char offset wire. http://forums.lavag.org/index.php?act=attach&type=post&id=6148 You can now see that you don't even need a local except for display purposes
  22. QUOTE(crelf @ Jun 14 2007, 05:02 AM) Never heard of http://www.crystalinks.com/holographic.html' target="_blank">The Holographic Universe?
  23. QUOTE(LV Punk @ May 31 2007, 07:32 AM) May I remind you that G stands for Graphical, not Grafenberg... Edit: Google returns 3180 results for "lapview". even lapview.com
  24. I still want a LabVIEW interface for this!!!!
  25. There is an easier method to access the property node of the ring, using the "link to" RMB item: http://forums.lavag.org/index.php?act=attach&type=post&id=5960
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.