Jim Kring

When running as an executable (in the run-time engine), "Get LV Class Default Value.vi" produces Error 7 (file not found) when attempting to open an *.lvlib file located inside an LLB file. However, it has no trouble with LLBs when running in the development environment. I've also seen a similar problem trying to use "Check if File or Folder Exists.vi" (trying to check if a file inside an LLB exists doesn't work when running from a built EXE).

QUOTE(gmart @ Aug 23 2007, 09:15 AM) That's very cool. However, it provides only convenience for app users, but not security for app developers. It seems that it should be technically possible for NI to define a virtual subdirectory scheme inside of LLBs. This is possible, already for ZIP, TAR, and other archive schemes. Then the class members could be segregated into virtual folders inside the EXE (which is really just a special LLB) file.

QUOTE(jaegen @ Aug 23 2007, 08:50 AM) Actually, it is still possible to unbuild a LabVIEW executable app into its constituent files. When building an app with LVClass's that causes the VIs to be outside the executable, the VIs will still (by default) have thier Block Diagram's removed (which is not quite "out in the wild"). It just waives it in our faces that built LabVIEW applications are by no means monolithic.

QUOTE(orko @ Aug 22 2007, 04:27 PM) This is because your top-level VI is set to Open Front Panel When Loaded. The ProjectItem.VIReference property that is being used in the utility opens a reference to each project VI in order to get its fully qualified name (with library prefix, if a member of a library). You can't simply use the project item name, since it might be a member of a library/class/xcontrol/etc. There is a ProjectItem.VIReference(NoLoad) property that can be used in 8.5 (which doesn't actually open a reference to a VI if its not already loaded into memory), but this property doesn't exist in 8.2 Here is a version that should work in 8.5 without opening the FP of VIs set to Open Front Panel When Loaded. http://forums.lavag.org/index.php?act=attach&type=post&id=6722''>http://forums.lavag.org/index.php?act=attach&type=post&id=6722'>http://forums.lavag.org/index.php?act=attach&type=post&id=6722

QUOTE(Aristos Queue @ Aug 22 2007, 04:16 PM) I've jumped in head-first, but only recently. Several "planets" have aligned: The Endevo GDS makes editing classes so much easier and I'm happy to have access to by-reference classes in the project. The OpenG Class Templates for Object Oriented Programming give me the assurance that I can tweak the by-ref templates. LabVIEW 8.5 promises more features and better stability :-) I'm bugged by the fact that building EXE's requires so many hurdles (segregating class hierarchies due to dynamic dispatch VI name collisions. I'm in the middle of building an EXE out of my big app with lvclasses, right now (pulling what little hair I have left out). I'll have more to say in coming months, once I can spend more time in 8.5... Thanks for your tireless effort on LVOOP. It's really great and going places

QUOTE(orko @ Aug 22 2007, 04:06 PM) Can you explain what you mean by this? Do you mean the top-level VIs in the project, the menu-launch VI, or something else? Thanks,

QUOTE(orko @ Aug 22 2007, 03:26 PM) Post your improvements, Joe! That's how open source works

QUOTE(Tomi Maila @ Aug 22 2007, 03:33 PM) I am dynamically loading plug-ins (child classes of a base class). I was using the .lvclass path as the "path to the plug-in". I then obtain the plug-in object (typed as a generic LabVIEW object, using the aforementioned technique) and then call To More Specific Class to convert it to my base class.

Is there an equivalent to "<LabVIEW 8.5>\vi.lib\utility\LVClass\Get LV Class Default Value.vi" in 8.2? I tried down-saving this VI from 8.5 to 8.2 and it complains that the function doesn't exist in the shared library (LabVIEW.exe). I have tried using the "LVClass.Open" function, in conjunction with the LVClassLibrary.DefaultInstance() method, but the "LVClass.Open" function fails (error 53: Manager call not supported) in a built executable (dispite the fact that the help docs claim that this method works in the run-time engine). Thanks,

Ask and you shall receive... Place Locate in Project.vi in the <LabVIEW>\wizard folder (create the folder if it doesn't exist), restart LabVIEW, and then you'll have a File>>Locate in Project menu item that works as advertised. :thumbup: http://forums.lavag.org/index.php?act=attach&type=post&id=6719 Cheers, -Jim

QUOTE(orko @ Aug 22 2007, 11:20 AM) Regarding download and activation of Community Edition, Endevo's website has the following info: QUOTE Download free trial (14MB zip file), for LabVIEW 8.2.1 Download free trial (14MB zip file), for LabVIEW 8.5 To activate the free (!) Community Edition use this license key: COMM-UNIT-YEDI-TION-2007

QUOTE(orko @ Aug 22 2007, 09:13 AM) Joe, try here: http://goop.endevo.net/GDS/''>http://goop.endevo.net/GDS/' target="_blank">http://goop.endevo.net/GDS/

Hi Jan, Thanks for the great product and also for your support of the LabVIEW community! I know how tough it is keeping up with all the changes as each new version of LabVIEW is released. Cheers, -Jim

Here's a tutorial on how to mashup two of my favorite development tools Using Beyond Compare as your TortoiseSVN Diff Program for ZIP Archives

QUOTE(brian175 @ Aug 21 2007, 07:38 PM) Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

I just heard through the grape vine that this error message will probably be "fixed" in a future version of LabVIEW. So, faking the execution state to avoid the error message is probably safe. Here's a version with better error handling. http://forums.lavag.org/index.php?act=attach&type=post&id=6705 http://forums.lavag.org/index.php?act=attach&type=post&id=6704

QUOTE(lavezza @ Aug 20 2007, 06:38 PM) I'll probably just wait for the 128 core machine.

Here is an example VI (saved in LabVIEW 8.2.1) that attempts to enable execution highlighting on itself. If you run it, you will see the aforementioned error. http://forums.lavag.org/index.php?act=attach&type=post&id=6695 http://forums.lavag.org/index.php?act=attach&type=post&id=6694

When I try to write to the Highlight Exection property of VI ("VI::Diagram::Highlight Exection" property) I get Error 1044 (VI is locked). Why does this give an error? I can press the execution highlighting button on a VI's toolbar when it is running. Anyone know how to this? My use case: I want to create a custom probe that can turn ON/OFF execution highlighting on the VI in which the probe is placed.

QUOTE(Omar Mussa @ Aug 19 2007, 08:47 AM) Probably having to order beer by the 'l'. Mmmm.... :beer: QUOTE(Irene_he @ Aug 19 2007, 08:13 AM) You have no idea that people from Europe (maybe not all, but some) have reversed logic , when they write ".", they mean ",". Ohhh, so Europeans actually are writing long run-on sentences. You learn something new every day. I think I see the pattern, here. Then, do the 'pause' and 'stop' buttons on European remote controls work in opposite fashion, too? We Americans miss so much, since we don't speak European. But, I do love European food -- there's a good restaurant that Michael takes us to that has the best Euros. http://forums.lavag.org/index.php?act=attach&type=post&id=6684

QUOTE(i2dx @ Aug 19 2007, 12:12 AM) 33.903 posts isn't very many (how do you make a fractional posting, anyhow?) QUOTE(Aristos Queue @ Aug 18 2007, 11:18 PM) You didn't even mention the LAVA logo appearing on the LV splash screen. There were just so many wonderful things, that it's hard to keep track! Yes, that belongs on the list, for sure

QUOTE(Aristos Queue @ Aug 17 2007, 05:52 PM) But if your test harness calls private members of a class then the test harness must be a member of the class -- but, it shouldn't since this violates the "test harness never gets distributed with your production code" rule. It's too bad that LVOOP classes are so unfriendly to test harnesses

QUOTE(Eugen Graf @ Aug 16 2007, 01:25 PM) Try these green VIs: http://forums.lavag.org/index.php?act=attach&type=post&id=6654 http://forums.lavag.org/index.php?act=attach&type=post&id=6655 Cheers, -Jim

QUOTE(Tomi Maila @ Aug 16 2007, 01:17 PM) It's a good thing that we all use source code control. SVN>>Revert is just a right-click away

QUOTE(Aristos Queue @ Aug 16 2007, 11:25 AM) > May I suggest that what you really want is polymorphic tunnels on subVIs? YES! YES! YES! YES! YES! YES! I've wanted the typeless (polymorphic -- edit-time type propagating) control/indicator for years! I've got a million things I want to do with this! It's one of the (undiscovered) pillars of LabVIEW code reuse! Expect to see a whole wave of new OpenG VIs follow suite. > But I'll pass your suggestion along to the folks that own these primitives. Thanks. I won't say no to that, either QUOTE(wevanarsdale @ Aug 16 2007, 11:26 AM) I believe Close Reference supports arrays in LabVIEW 8.5. That's great! I also noticed that there's a green VI in the palette that also supports arrays http://forums.lavag.org/index.php?act=attach&type=post&id=6653 Cheers, -Jim