PJM_labview

I did notice this feature and I have to confess that I am not too found of it. For instance if I have a dark banner on my children class and I use a white font for the banner text I end up having the parent banner color "leak" through (which does sometimes makes the text unreadable). PJM

I am seeing something very similar in my project as well (although restarting LV do NOT help me at all). Thankfully in my case I do not (yet) have to wait 3-5s but more like 1-2s. I also use a lot of classes (both by val and by ref) and there are over 3K VIs in that project. When I have this project open and I do an edit in a VI I see the hour class between each edit. Like you I also have a fast computer. My workaround, at the moment, is to no longer use my full project (unless I have to) but to only open the class I want to edit (resulting in less stuff in memory) and this way everything is back to normal. I am also seeing this as well. It does sometimes resolve itself (meaning I regain control of LabVIEW) but not always. I have situation where I try to drop a node from a palette or create a property nodes and LV get in that mode and it never recover (no matter how long I wait). I then have to restart LV, open the project, create a blank VI, create the nodes I want in the blank VI and then copy then from the blank VI to the VI I want them to be (if I try again directly in the target VI, LV hangs again). Pretty painful. Oh, and another things I am seeing is LV crashing when probing wire with large cluster (like the one you got in a large state machine). Note: I do not have any network drive involve in this. Note: All of this happen with LV 2009 f2. PJM

I will be in the San Jose one next week as a mentor. PJM

This look very impressive Francois! PJM

Adding my 2c here. I think I have experienced a lot more locks in LabVIEW 2009 than in previous LabVIEW version. I have a utility allowing me to bypass the lock and erase the file (or folder), unfortunately this is no longer working well (if at all) with LabVIEW 2009 locks. PJM

I would be curious to know the answer to that question as well as I had to trained several users in one of my customer about the meaning of that message and about the fact that they should not close that "MATLAB Command Window". PJM

Oops, I never realized that native English speaker never got that "pb" abbreviation. I shall be more careful in the future... Thanks Antoine for the translation PJM

My customer tried to isolated it but he was not very successful. One of the work around that has worked for me in the past (when dealing with this issue [1502]), was to isolate the lvclass with problems in a separate virtual folder in the project, then create a separate rule (as dynamic VI) in the build spec. We were initially successful with this approach (after we pealed off all we could except the dependencies and ancestor from the project) but as soon as my customer started to add back the other classes in, they also start to brake with error 1502. I would LOVE to be able to isolate this issue so I could submit it to get it fixed. Regarding the error 6, I have a pretty good handled on it now and I know what to do to get rid of it (basically target build should be short [ie: c:\Build] and rename all VIs that are too long if this is not sufficient). I completely agree with that. PJM

I don't think that this is the case (but I will check to be sure). In our situation, the lvclass contain a DVR to a strictly typed cluster. Something that I forgot to mention is that this is happening with LV 2009 service patch one. PJM

I have a very similar thing happen to my customer. He use a lot of classes and he keep getting error 1502 (Cannot save a bad VI without its block diagram.) [Note: Everything run fine in the IDE, nothing broken]. He spent several days trying to fix this, without success. For now he has to enable the debugging flag to be able to build an exe. Between this error (1502) and error 6 (file I/O=Path too long), building an executable is getting really difficult. This really need to get fixed. PJM

Sorry, I missed that post Did you ever got that fixed? Note: The "Compiling Hierarchy" is running in the IDE and should eventually finished after sometime. After it does, I think that VIPM should no longer show that "connecting to LV" status. Thanks PJM

This error 6 is actually a major pain in the behind when building executable in LabVIEW 2009. I think that LabVIEW should be smarter about it and detect when the path is too long and if necessary rename/relocate the offending VI(s) so it just worked. For most people this solution would be ideal. For people doing some more fancy stuff like calling VI dynamically by path in the build executable, a log file (containing the original and new VI name/path) should be created. At the very least, the error message should be improve to point the person attempting to build the executable in the right direction ("Generic file IO error" is really not descriptive enough). PJM

Graeme, That "AppEXEConfig.vi" is pretty cool and interesting. I learned something. Thanks PJM

An answer to both "question" is FIRST Robotics. Dean Kamen started this as a mechanism to get kid interested in science in general (and in computer science since there is a programming part to the challenge). NI, from a year ago, has become a partner and is donating cRIO with LabVIEW copy for programming and controlling the robot. There might be other effort(s) from NI side, but I do not know about it. PJM

Since we are side tracking into SF... I just watched Avatar (in 3d) yesterday and this is a visually amazing movie. All of you geek/nerd (pick the one you like the best ) should go and see it. PJM

I did not looked at that part of the code, so no I don't know. But I suspect it used the scripting method to read tag data. PJM

As far as I know, the image data does not have layer information but instead the "merged" (flatten) layer data. It is my understanding the the layer data is stored as tag in the VI file and they are not accessible through the get as image data method. PJM

Nice trick with the NI_Library:thumbup1:. I did not know about it. I think that the new icon editor works very well (and is faster) if you use template, icon text and existing glyphs. For everything else, it is a lot more difficult to use than the old one. PJM

Congratulation Chris.

New Feature Request: * I think the "Insert case here" should duplicate a separator case (a case named "---------- UI ----------" for example) so all the necessary wire are already connected (error, application data, queue, ...). Alternatively, create a new command called "Duplicate case here" that does what I explain above. * The caseselect windows title should have the VI name in it so it is easy to know which one I am looking at when I have more than one case select editor opened. I actually think that nothing else beside the VI name is needed. PJM

Thanks, This is good to know. PJM

Thank you VERY much. I guess I have been so disappointed by this new feature that I did not post all the issues I found with it. I will do that quickly here: If you have an array the direction key use to navigate the array are not working properly (only the down one is working). If you try to use the navigation key to navigate a long string or long path (not completely visible) this work badly (all keys are not working). When you detach a cluster that is small enough to completely fit on your screen, you now get scroll bar on the detached probe where there should be none (this is very annoying). Finally, when I probe a very large cluster data structure I experience performance issue [sever slow down] on the first run (it might be an issue link to updating the data value [or tip strip] on the left side of the probe window). Again, thanks a lot for that ini key. PJM

I use Paint Shop Pro too (although I have not upgrade to the latest version). PJM

Are you using some tools that have some scripting in it? I know (because the RCF use to have this pb) that using some scripting action will flush your undo buffer and you end up with only one undo (regardless of what you set the ini settings). Just a though. PJM

François, Good catch. You should probably report that to NI there (http://decibel.ni.com/content/groups/enhanced-icon-editor-2009) because I think this is an issue with already existing underlying IE code. Thanks PJM