Jim Kring

QUOTE(Aristos Queue @ Sep 13 2007, 06:41 PM) That's what I expected -- that LabVIEW does not have a "feature" that I need. Basically, I have a cluster of siblings and I want to iterate over them (without defining a redundant cluster of parents having the same size as the cluster of siblings). I guess I'll have to go the variant route... again. sigh...

QUOTE(jpdrolet @ Sep 13 2007, 03:48 PM) It is the http://en.wikipedia.org/wiki/The_Answer_to_Life,_the_Universe,_and_Everything' target="_blank">Answer to Life, the Universe, and Everything.

The naive side of me expected that the Cluster to Array function would work for a cluster of relalative (sibling) LVClass types, upcasting the LVClass elements to the first common ancestor (e.g., I can use Build Array on related LVClass types and the output array will upcast, in the way I described). I'm I naive or is this a bug?

QUOTE(Aristos Queue @ Sep 13 2007, 11:36 AM) Oh yes, that's a great way to document your compiled binary code

I going to try something radical to see if it catches on... I have created a new wiki page for this bug, here: Move on disk feature crashes LabVIEW. The nice thing about the Wiki pages is that you can categorize them. For example, a bug can be a member of both the LabVIEW 8.2 Bug and LabVIEW 8.5 Bug categories. Right now, there is no way to achieve this by having bug's in discussion forums -- it can only be in one forum. And, wiki pages can have discussions, so we can still have the great discussions around bug reports similar to what we have now.

QUOTE(LV Punk @ Sep 13 2007, 10:29 AM) Yes, it's saying "this section of the code needs coments and/or rewriting"

QUOTE(Aristos Queue @ Sep 13 2007, 06:01 AM) Here's some ammunition that might help push it through. Just say... "Anyone (using LabVIEW) who doesn't see this as a critical feature (for free labels) is obviously not commenting thier code enough!"

QUOTE(orko @ Sep 12 2007, 01:30 PM) Oops... I thought I had the latest version, but nope Nevermind :laugh:

QUOTE(orko @ Aug 23 2007, 01:13 PM) Currently, Dependencies are excluded from the search. However, I'm finding that I really want to include them in the search. Fixing this is just a matter of setting ExcludeDependencies = FALSE when calling the MyComputer.GetAllDescendents() method.

QUOTE(Justin Goeres @ Sep 12 2007, 11:08 AM) You're hyperlink should be... http://forums.lavag.org/You-can-t-add-Auto-Populate-folders-in-classes-t9019.html#entry35624 not... http://forums.lavag.org/You-can-t-add-Auto-Populate-folders-in-classes-t9019.html#35624 Could this be related to the recent forum problems? [uPDATE] hmmm... you're link is fixed now. Strange.

QUOTE(ragglefrock @ Sep 12 2007, 08:38 AM) A) LabVIEW was a Mac program before it was a Windows program. B) Do LabVIEW user really want integral control over everything?

QUOTE(Christina Rogers @ Sep 12 2007, 08:28 AM) Thanks

QUOTE(Christina Rogers @ Sep 12 2007, 08:10 AM) Thanks, Christina. I'll keep testing and see if I can reproduce the problem -- it might be related to this issue (which I can reproduce): http://forums.lavag.org/Project-that-won-t-let-go-of-some-LVClass-Dependencies-t9047.html' target="_blank">Project that won't let go of some LVClass Dependencies.

drawl

Here is a test project called "TestProject". Note that it depends on the OpenG Class Templates for LabVIEW Object-Oriented Programming being installed using VIPM (but does not requite the Endevo GDS to be installed). Download File:post-17-1189555403.zip Note that it has a Parent class with two child classes Child1 and Child2. If you remove either Parent, Child1, or Child2, they will stay in memory (as seen under the Dependencies>>Items in Memory) until all three classes are removed from the project.

I'm seeing a strange problem with my LabVIEW project. Here's what's going on. I have several classes that were created with the OpenG Reference Object Template. If I have my project open and I load one of these classes into memory (either by opening the LVClass or opening a VI that calls a class member), the LVClass gets added to the Dependencies>>Items in Memory folder. However, when I close the LVClass (or the VI that calls the class members) it does not get removed from the Dependencies>>Items in Memory folder and I have no way of getting rid of it. Worse, if I save the project, close it, and then reopen it, the LVClass still shows up in the Dependencies>>Items in Memory and gets loaded into memory. Has anyone seen anything similar?

QUOTE(Aristos Queue @ Sep 11 2007, 02:50 PM) That's a great point and is very applicable to what I am doing. I think that I'll try to go this route. Thanks, -Jim

QUOTE(Jim Kring @ Aug 24 2007, 02:12 PM) 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. I just realized that the problem with this (a single VI that simply returns the class constant) is that the VI that returns the class constant must be a static method otherwise it cannot be called using a Call By Reference node. The means that if you plan on having multiple levels of plugin inheritance, you have to make sure that each subclass uniquely names the "GetClassConstant" method (e.g., GetClassConstant_Motor.vi and GetClassConstant_StepperMotor.vi, if StepperMotor is a child of Motor) since static methods cannot have the same name in two classes that are part of the same inheritance hierarchy.

QUOTE(gmart @ Sep 11 2007, 05:20 AM) I misspoke (it was late when I wrote that). Yes, all VI dependencies are added to the build. What I meant to say is that in order to target VIs to a specific destination, they must be beneath My Computer (and no longer in the Dependencies). And, as I mentioned, OpenG Builder treats support files differently from VIs and is able to handle wildcards and recursion. For example, you can do things like add a folder's contents recursively, but exclude any folders that are named ".svn" or "CVS". You can also do things like include all files named "*.ini" from the "configs" folder. These sorts of features are the reason why people want autopopulated folders in the LabVIEW Project Environment. I mentioned to Christina R. that "Smart Folders" (similar to Smart Groups in Apple XCode, iPhoto, iTunes, etc.) might be the best way to achieve this easily in the LabVIEW Project environment -- they allow you to define a rule set that determines whether items are members of the group and appear in the folder. [uPDATE] One more thing that I found annoying is that LabVIEW's builder only lets you exclude vi.lib, user.lib, and/or instr.lib. It would be nice to add other locations, for example, paths beneath the project root. This would facilitate building plug-in architectures and components that are linked to each others sources in the same project structure, but are built seperately. Thanks,

QUOTE(Aristos Queue @ Sep 10 2007, 07:39 PM) IMO, autopopulating folders address use cases for building EXE's (and other build targets) that might be better addressed by more features in the build rules system. In the LabVIEW project environment, anything that is a Dependency (or not explicitly in the project under My Computer) is excluded from the build. This requires that anything that should be included in the build be put under My Computer, and the only "dynamic" way to do this is with auto-populating folders. This is in contrast to the way builder works -- e.g., it supports the use of wildcards and recursion when declaring support files and automatically includes every VI dependency unless it is found under an Excluded directory (the user can define which directories to exclude). :2cents:

QUOTE(Aristos Queue @ Sep 10 2007, 07:18 PM) Can you confirm whether or not it saves child classes? IMO it should not save child classes -- that's a little bit upside-down (I think). Hmmm, I think that this could possibly be caused by LabVIEW thinking that some child class dynamic method VIs are subVIs of the parent class. I haven't done much testing to confirm this (I only noticed it once earlier today). But, now it's way too late for me to still be at work, so I'm going to sleep on it... Thanks,

QUOTE(Val Brown @ Sep 10 2007, 06:37 PM) Val, You might consider signing up for a Gmail account and use Google Reader as your RSS client. It works very well - give it a try http://www.google.com/reader/ Cheers, -Jim

I'm going out on a little limb here (by calling this a bug), but I can't see any good reason why the "Find Callers" dialog (right-click on ab LVClass and choose Find Callers) is not resizable. And the "Find SubVIs" dialog, too...

When items are missing from a LabVIEW project, it is very difficult to find these missing items in the Project Explorer, especially if they are several levels deep beneath folders. I would expect that these items be accessible by clicking on the "Resolve Conflicts" toolbar button (which has the same icon that is used as a badge for missing items, by the way). Additionally, I would probably rename the "Resolve Conflicts" toolbar button to "Resolve Problems", with "problems" being "conflicts" and/or "missing VIs" -- hmmm... maybe I would just name it "Resolve Conflicts and Missing Items".