gleichman

QUOTE(lraynal @ Apr 12 2007, 06:52 AM) Because a For loop iterates when all code within the loop completes. It's a the way data flow works.

I still don't understand the problem. VIs can be dynamically called in an exe, in an LLB, or just in some directory as long as the correct path is supplied. For my "plug-in architecture", in development mode, I store my dynamically callled VIs in a dedicated sub directory. During program initialization, I read the filenames in this directory and open a VI ref to each one and store the refs in a USR. Then I use Call By Ref as necessary. For my exes I roll my dynamic VIs into my exe. In the past I have left them out, but for various reason I now perfer to intergrate them in. The same VI that prefetches my VIs from the directory checks if the environment is exe and if it is it searches in the exe for files with a predifined prefix. I always use the same prefix for the dynamic VIs so the code doesn't change between Dev and exe. - Alan

Have you tried mass compiling your old project? QUOTE(JodyK @ Apr 11 2007, 04:35 PM)

How about using the "key down?" event?

QUOTE(BrokenArrow @ Apr 9 2007, 06:45 PM) NO! 8.3 = $$ (for those without a subscription) 8.2.1 = Free

QUOTE(ars_stowers @ Apr 9 2007, 05:00 PM) I am a bit confused. Error 1003: LabVIEW: The VI is not executable. You mention that this happens with projects that use the OpenG Builder. I assume that this means that your program works in development mode, but not as an executable. Is this true? The error code seems to indicate otherwise. Have you checked all of your dynamic VIs to see that none of them are broke (broken run arrow)? There should be no problems sharing VIs between normal and dynamic code. I have done this for many years.

QUOTE(gleichman @ Apr 9 2007, 01:51 PM) A friendly application engineer found the fix for this problem. http://digital.ni.com/public.nsf/allkb/52EA1C0398769358862571C60074FF74' target="_blank">http://digital.ni.com/public.nsf/allkb/52E...62571C60074FF74

I had no problems during the actual installation. Total time to install was about two hours. In the two hours since installing, I have found some problems. The report generation llb "NIReports.llb" was over written over the standard llb. Make a backup of this file before installing if you use the Report Generation Toolkit. Traditional NI-DAQ VIs were removed from my 7.1 installation.

Well, now I know what I will be doing this afternoon. Mindstorms NXT :thumbup: Wii :thumbup: Eleven year old assistant :thumbup: Yard work to avoid :thumbup:

QUOTE(Jim Kring @ Mar 26 2007, 04:30 PM) Would it be wise for NI to change this? These symbols have been in this order since they were introduced in LV8.0. If they changed it, it would break all code that used these symbols and worse yet it you would only know it if you read the release notes and remembered that your code used these symbols ... no broken arrow. The only viable solution would be to add to more symbols in the correct order and that would certainly cause some confusion.

QUOTE(Aristos Queue @ Mar 26 2007, 06:22 PM) First call works well if you only want the case called only once during program execution, but if this is a subvi that needs to be initialized each time it is called you should use a shift register.

Have you looked at the "Configuration File VIs"?

This bug causes typed data entered the time before last to disappear. (Does that make sense?) Here's how it works: Click on cell 1 and enter data. Click on cell 2 and enter data. Click on cell 3 enter data and then click outside of the listbox. Data in cell 2 disappears. To perform this magic trick, your code must have the following. Set the "Edit Position" when the listbox is clicked on. Trap the "Edit Cell?" event. I've attached a simple example (LV8.2) and cross posted to the NI forums (no CAR and no responses). Download File:post-151-1170292612.vi

At least we have water.

I've had a similar problem with Type Defs embedded within Type Defs (LV 8.2). My solution is to open all related Type Defs and then make my changes. If I follow this procedure, LabVIEW does not crash.

That's a cool feature that I didn't know! This would make a good nugget for Darren.

Thank you for the detailed response. After reading your post, I made another version of my test VI "Method 2" that did not transpose the array, but instead indexed the column inside the For loop. This new VI gave the same bad results as before, so it does not appear to be the fault of the transpose array. Download File:post-151-1169307909.vi It's good to know that this will be fixed in the next release and for now I have a work around.

I made my first attempt at using TDMS files yesterday and I had some unexpected results. I was using TDMS files to store data from a multicolumn list box control. When I wired the ItemNames property to the data input of TDMS write, the resulting data file did not match the data coming out of the property. Only after running the data through two for loops did the data save correctly. The following images and VI illustrate the problem. The Data: Method 1: Single write Results: Method 2: Wrap the write in For loop and write one column at a time. Results: The same. Method 3: Add For loop in the For loop that does nothing. Results: Expected data. Download File:post-151-1169298761.vi Is this my bad, a bug with ListBox data, or a bug with TDMS?

It's very impressive, but it ain't NXT. From what I saw in the video, the many controllers used to run the assembly line are the older RCXs from Mindstorms 1.0 - 2.0. Using NXT controllers would probably have made the project much easier, but very expensive. Hmmm ... I wonder what I could make with my two RCX systems and my son's NXT. But first I need to finish installing a new light fixture.

Or you can view their catalog online and not get a crick in your neck www.saltlickbbq.com/. I'm still working my way through the bottles of sauce that I bought there at NI Week. I thought for sure that the sauce was going to end up all over my clothes since the ban of liquid carry-on happened during NI-Week, but it all made it home safe. I could sure go for some Salt Lick brisket.

I'm not a VIE employee (but hopefully an honest engineer) and I have seen a large picture of the Queen hanging in his cube the last time I visted (about a month ago). From my experience with Chris's minions, I don't think the picture does much to reduce the volume of nerf projectiles. In fact, it will probably get worse real soon. :laugh: I think we have lost track of the original subject ... The mis-casing (is that a word?) of LabVIEW. I received two resumes today, both which perported to know "Labview".

This will work. :thumbup: I can get rid of my ring controls all together and use a list box for the left click events and to store the results. Thanks for the example.

Yes, like a right-click menu, but as a left click on a ring control.

It's hard to top the Honda commercial from a few years back called the cog.

I have a UI that uses a ring control. The problem is that usability decreases as the number of items increases. It would be nice if I could categorize the options kind of like the Windows Start menu. Has anyone done something like this?