Ton Plomp

Jup, I'll do the xControls, Aart-Jan will do the LVOOP Ton

Hello All (esp. the dutch), who of you are attending the user group meeting next week in Eindhoven? I know Albert Geven will give a presentation about code reuse and the other topics look great. My colleague and I have already split the agenda between the two of us. Ton

<REPOST alert!> I've asked these questions on the NI forums: Question 1 Question 2 </Repost alert> The scenario is: I'm using LV 8.2 with most of the code inside Microsoft Visual SourceSafe where the database is located on the network. This works OK (sometimes LV doesn't update the representation in the project explorer) But now when I take my laptop off-line and want to open a VI/project LV wants to connect to the SCC-database, this gives an error -2976, but another window (search for vi) is blocking my error window. So I can't click the 'continue' button. But if I click the 'Stop...' button nothing happens This means that I can't work at home... Can somebody reproduce this? A) with VSS B) with another source control system In LV 8.0 I just got error -2976 for every VI but after a dozens clicks I could work. Now question 2 is a minor inconvenience. The 'Getting started' window is modal! Why, what if i open the 'getting started' from within a project or VI. In this case I can't go back to the VI/Project without closing the getting started window... :headbang: Any thoughts? Ton

It is also exposed in the .lvproj file.... <Property Name="SourceItem[0].PasswordToApply" Type="Str">Secret</Property> Ton

Hello Phillip, If you use execution highlighitn on that section (set a breakpoint on the '16' constant) you would see what happens. The output of the for loop only uses the values from the last iteration, in this case nothing! So the VI waits on termination of the for loop but starts with empty inputs! (See: the knowledge base) To have such a setup I recoment a cluster with all the information, with a shift register you can update the contents of the cluster and feed this one to you filename.vi For instance: Ton

Correct me if I'm wrong but you want to do this: Copy a set of code This code has some subcode that is fixed in one location (similar to user.lib, why not use these. You can even move user.lib) You do not want to load this subcode via the search path I see really only one option, refer to these subcode via a dynamic path, this VI holds all the sub-vi's in the fixed path. What cross-links are you expecting when using the search path? Ton

If I understand correctly you have missed one wire: In case 3 where you open the VI-reference you have to tell in which application instance this happens. Your VI (Get Menu Launch VI....) runs in the application main instance, the calling VI runs in a project instance.. And i think that the App.MenuLaunchVI property should be controlled by the local (main instance) application instance, or you should read this name outside the while loop. Because the user app instance has no ManuLaunchVI info. Ton Ton

I have not seen this (well actually I have seen transparency after a copy/paste action) In that case I had a .wmf file opened in MS Word, edited the tranparency and then copy/paste this kept the tranparency in the button. Ton

Maybe some sub-panels with VI's where the BD is removed? Or use a good framework with sub-vis where the more advanced stuff is done. Ton

NI has some time (since february) a knowledge base entrie on this item: NI KB Ton

What you should do is temperarily remove the 8.0 folder to a place where LV 8.2 can't find the VI's, this will force 8.2 to look into it's own 8.2 user.lib. After that you should be able to copy the 8.0 folder back. But better safe than sorry make a backup of both folder's. A good way to test this is making the 8.0 folder read only. 8.2 will than bother you with saving of several items. Ton

(A) is correct (B) isn't A: It only means that the G-Code was correct and still is correct (you don't rewrite your VI's from scratch I think with a new LV environment?), the down side is that the internet server is way old B: LV 8.x has the ability to compile VI's with errors. This was done by ignoring cases which are controlled by a BD constant, the cases that will never executed are removed from the compiled code (an enhancement of the diagram disable structure) A problem arose here. What if you had some VI's in a not executed state which you wanted to call dynamically (thus by name), in LV 7 and prior these would be loaded into memory and could be called by name. Now in LV 8 the BD constant is replaced by an invisible FP control, making the compiler think that the case could be executed. So to maintain compatibility with the prior version the code is changed. Ton

Download File:post-2399-1158310854.vi

Now in LV 8.2 you get a message about the saving of the root.mnu, it looks like it is moved from menus\default\root.mnu to personal\LV data\8.2\pallettes\menus\default\root.mnu I'm not sure what is happening but maybe you can create a new root.mnu in you personal folder which has everything you want? Ton

Hello Michael, I've done something the other way around, use the project to structure my hard-drive, the only thing is that it is not fool proof (VI's missing references etc....) If I remember I'll try to dig the code monday and post it. You can use a .NET event that is triggered when some items are added to a folder (their was a discussion on forums.ni.com on this subject some weeks ago) Ton

I'm not sure if that is the result I want (a bug being ignored). But I think NI will improve the mathscript node step by step and eventually will cover these things. Ton

I use this code: Found it on the NI-ftp site and modified it a bit, the down side is that it uses .NET doesn't work on all computers. Ton

So that means no more shift register!! Ton

First I have no experience with Mac/finder. Error 10 is a duplicate path error, I've only seen these when copying a file into it's own, or creating an existing folder. Maybe it is an access rights thing. A quick test might be a VI with only an open file vi, this will launch a browser so you can open the file, if this still give an error (and you can open the file with another application) it might be a bug. Ton

Hi Stan, your VI doesn't open well on my machine but I think this is totally normal, you are creating an array of 2 G datapoints. With just normal U16 datatype you need a memory of 4 GB, for standard floating points (DBL) you need 16 GB memoryspace (timestamp 32 GB). The reason LV stops and not creates a 'normal' error is because the memory managemend is violated, it could be that LV just executes and want to allocate the memory, your OS is handling that (and can create extra memory on disk. What if LV continued and you didn't check for an error (even more the standard way to initiliaze an array has no error output then the function of your program was totally unreliable. Ton

You have to select the Project:******.lvproj line, this will give you the reaction you want! Ton

With Darren's Nugget I've confirmed that the VI is loaded into the exe but there is still an invalid app Ton

Yes, in the project window you have to select the files you want to check in / out and right click OR use the Tools\Source Control\Check In (or Out) This is usefull for checking in a lot of files. Ton

Hi Dany, in my opinion a user who knows how to execute an executable from the file browser knows how to run an executable in another way. Or are you disabling the windows key, ctrl-alt-del, ctrl-esc? Might it be possible to create a user account with almost no rights just to run your program? Maybe you can use the .net browser and run that one as a low-righted user? Ton

Hi All, I'm working with AartJan on this issue and ran into a rather strange item. Let me describe what I do: -I set the INI settings of the LabVIEW executable I want to connect to -I launch the exe -I try to connect to the VI server inside the exe (this will fail sometimes with error 68 connection refused) -I load a normal VI (not in the exe) into the executable application instance In the VI loaded via VI server I try to determine which application instance I'm in. I do this with the following code properties: App.Name App.Kind The VI does not return a name (or error), but the app.kind is invalid. I have never seen this before but the same code inside the executable runs normal, and the development VI that loads the app. instance and this vi reports the correct items... Does anyone have seen this behaviour (app.kind=invalid)? Ton