Jim Kring

QUOTE(dpfan @ Sep 10 2007, 12:51 PM) set

Maybe I don't understand the intended behavior of the "Save All (this Class)" feature (which is available as a right-click option on an LVClass in the Project Explorer). It appears to sometimes save VIs that are outside of the class (in my case, it saved some VIs in a child class). I assumed (perhaps incorrectly) that this feature would only save VIs that are members of the class (and no other VIs -- not even child classes). Can anyone, shed some light on this feature? It doesn't seem to be described anywhere in the LabVIEW help.

QUOTE(Justin Goeres @ Sep 10 2007, 10:01 AM) I found a similar issue that might be related... For multi-page topics, on a page other than the first page, if you click on the post # hyperlink (see screenshot below) to get the permalink to an individual posting that does not work -- it takes you to the first page of the topic. My guess is that this is a bug in the IPB SEO Module.

QUOTE(jaegen @ Sep 10 2007, 09:54 AM) I see the same problem in Thunderbird.

QUOTE(alfa @ Sep 9 2007, 10:48 PM) Can you use the food as bait for catching fish?

I don't think anyone has mentioned this yet, here... In LabVIEW 8.5, you can implement a Functional Global without any loop: Functional Globals in LabVIEW 8.5 - No Loop, No Joke

QUOTE(PJM_labview @ Sep 5 2007, 06:04 PM) Yes, yes, yes!!! This is the beauty of the OGP file format. David, if you have questions about how to do this, please ask -Jim

QUOTE(yen @ Sep 3 2007, 12:16 PM) I've been using MS XML Notepad for a while now and love it! QUOTE(Justin Goeres @ Sep 3 2007, 09:55 AM) BAH! Jim posted over me while I was tweaking my self-reply! Oh well, I'll leave mine here because I have a screenshot Hehe. Sorry

In the "Build Specifications" section of your project file, try changing this: <Property Name="Source[0].itemID" Type="Str">{09BB8071-8023-44FD-80C1-5C2EA6D03A94}</Property><Property Name="Source[0].type" Type="Str">Container</Property><Property Name="Source[1].destinationIndex" Type="Int">0</Property><Property Name="Source[1].itemID" Type="Ref">/My Computer/Main.vi</Property><Property Name="Source[1].sourceInclusion" Type="Str">TopLevel</Property><Property Name="Source[1].type" Type="Str">VI</Property><Property Name="Source[2].destinationIndex" Type="Int">0</Property><Property Name="Source[2].itemID" Type="Ref">/My Computer/supportfile.ini</Property><Property Name="Source[2].sourceInclusion" Type="Str">Include</Property><Property Name="SourceCount" Type="Int">3</Property> To this: <Property Name="Source[0].itemID" Type="Str">{09BB8071-8023-44FD-80C1-5C2EA6D03A94}</Property><Property Name="Source[0].type" Type="Str">Container</Property><Property Name="Source[1].destinationIndex" Type="Int">0</Property><Property Name="Source[1].itemID" Type="Ref">/My Computer/Main.vi</Property><Property Name="Source[1].sourceInclusion" Type="Str">TopLevel</Property><Property Name="Source[1].type" Type="Str">VI</Property><Property Name="SourceCount" Type="Int">2</Property> Note that you have to decrement the "SourceCount" value (from 3 to 2, in this case), in addition to removing the "Source[2]" items.

WAN, LAN, WAP, SAP, stop stop and think how the world shrinks how the computer blinks Enjoy the ride... :laugh:

Hi Anthony, I have just posted my NIWeek 2007 presentations. Michael's presentation is soon to follow (in video format). Thanks, -Jim

QUOTE(alukindo @ Aug 30 2007, 12:19 PM) Hi Anthony, I was just thinking about that, today, as http://thinkinging.com/2007/08/29/should-your-commercial-labview-application-be-cross-platform/' target="_blank">my latest blog posting relates to material from one of my NIWeek 2007 presentations. I'll get these up, shortly. Thanks, -Jim

Hmmm, so we can take a hierarchical, by value object tree and cause objects to refer to each other by value...? That sounds both exciting and scary (if I'm understanding what AQ is asking us to try to do). I think that we will need to use MoveBlock in order to get an exact duplicate (handles/pointers and all -- similar to a hard link in Unix file system, I guess) to some graph node and then use SwapValue to insert that hard linked object into the graph (as one of the adjacent nodes some node). But how do we get the memory address of an object (since MoveBlock will only be used for getting a hard-link duplicate of the object)? Am I off base here or am I heading in the right direction?

QUOTE(Aristos Queue @ Aug 29 2007, 09:50 AM) It seems to me (and I still don't understand everything that's going on here, fully) that the feature which should be removed (if we have to make a choice) is the Swap Values function rather than the ability for a child object to have a parent object in its private data. It seems that the "problem" is that the behavior of swapping values in memory is a function of how LabVIEW stores data in memory and this is something that we should generally not have to care about in the domain of dataflow.

QUOTE(yen @ Aug 28 2007, 11:54 AM) You can use any LabVIEW executable to run project VIs (unbuilt source code) in the run time engine (just pass it the VIs paths as command-line arguments). This is a trick that I learned from Jean-Pierre Drolet, some time ago. If you want a degenerate LabVIEW executable, just make a copy of "<LabVIEW>\applibs\lvapp.lib" and rename it as "anything.exe".

You've got insane objects http://forums.lavag.org/index.php?act=attach&type=post&id=6776

QUOTE(Eugen Graf @ Aug 27 2007, 01:42 PM) This assumes that if a VI has no block diagram that it is built as an EXE. However, it is possible that the block diagram might be stripped and the code is running in the development environment. But, it is also possible that the code is running in the Run Time Engine and it has not been built as an EXE (so I'll admit that my solution is not fool-proof either). The only reliable way to tell if something is built is to perform some operation during the build process which only happens during the build process and check for that in the code. I use OpenG Builder to set Version Info (Version Number, Build Number, and Build Date) on a cluster of a VI's front panel (which is a fool proof-way to tell if the code is built). However, for the casual user, I believe that the check for App.Kind == Run Time System is the most reliable mechanism.

Now that SuperFunkyPrivateSpecialSecretForumStuff=LAVA is official (and famous), shouldn't this T-shirt... http://www.cafepress.com/lava3.68429293 ...be added to the main LAVA store on cafepress? http://www.cafepress.com/lavausergroup Thanks, -Jim

QUOTE(jorourke @ Aug 27 2007, 11:42 AM) The most reliable way is to read the Application.Kind property. If it equals "Run Time System" then you're in an EXE (running from the LabVIEW Run Time Engine). http://forums.lavag.org/index.php?act=attach&type=post&id=6775''>http://forums.lavag.org/index.php?act=attach&type=post&id=6775'>http://forums.lavag.org/index.php?act=attach&type=post&id=6775

Enjoy... <object width="425" height="350"><param name="movie" value="http://www.youtube.com/watch?v=DpA2tMrQ4RU"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/watch?v=DpA2tMrQ4RU" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

QUOTE(Aristos Queue @ Aug 24 2007, 01:28 PM) > Ok, Jim. Let's take a deep breath and start from the top. First, is the computer plugged in? Actually, you're supposed to ask the customer to unplug the computer and blow the dust out of the connector because sometimes that causes problems OK... "Open VI Reference" is working now... whew... I was just going crazy Actually, I think that I was attempting to open a VI that was saved in 8.2 from an app built in 8.5 (oops ) I created a simple project (Bug.zip) to test three things at run time: 1) "Open VI Reference" for VIs inside LLBs (works) 2) "Get LVClass Default Value.vi" for VIs inside LLBs (fails) 3) "Get LVClass Default Value.vi" for VIs inside LLBs after using "Open VI Reference" to open a class member and bring the class into memory (fails). Note: I've tried passing both the absolute path to the .lvclass and a relative path of only the lvclass name -- both fail. Thanks, http://forums.lavag.org/index.php?act=attach&type=post&id=6755 QUOTE(Tomi Maila @ Aug 24 2007, 01:06 AM) Jim, I've used class plugins myself since the times of LV 8.20. The way I do it is that for each plugin, I create a single VI that simply returns the class constant. Then simply dynamically open a reference to this VI. If you use certain naming convention for the VIs (as I do), you can search directory structure for these VIs and open plugins as needed. It's very simple way and doesn't require any special features of LabVIEW 8.5 Ya, I was thinking about this. I wasn't a big fan because its yet another VI/convention that I have to add to my plugin template.

On Windows, you can use data-socket, WinInet, or .NET (WinAPI).

QUOTE(Aristos Queue @ Aug 23 2007, 08:32 PM) I just tried (in LabVIEW 8.5) to use Open VI Reference to open a reference to a VI that is contained inside an LLB and that doesn't work in built apps, either!!! Am I going crazy?

QUOTE(Justin Goeres @ Aug 24 2007, 06:30 AM) That gets me thinking... How about marketing LVOOP to new users as "private cluster libraries"? Don't even say "object" and especially don't say "object-oriented programming". Simply teach new users about the features of LabVIEW private cluster libraries and why these features help them write better code. The problem with calling LVOOP "object-oriented programming" is that people will then try to research traditional OOP, and then one of the following can happen: A) They quickly get caught in a bottomless pit of information and get discouraged because there is too much to learn. (I've been a student of OOP for quite some time and don't feel like I fully understand everything about all flavors of OOP.) B) They understand and like traditional OOP and become dissapointed to learn that LVOOP is different. Instead, teach them about the features and then surprise them later by saying "Guess what? You know how to do object-oriented programming in LabVIEW."

OK, now I've hit another brick wall... "Get LV Class Default Value.vi" can't open lvclass within LLB in built EXE The work-around is to distribute each of my plug-ins as two separate files (my_plugin.llb + my_plugin.lvclass)