Jim Kring

In my opinion 8.0.0 is not useable, due to the bugs -- the 8.0.1 patch is absolutely necessary. However, after 1 hour to install LabVIEW 8.0, it is not reasonable to spend 2 to 4 (or more) hours mass compiling.

Please cast your vote.

Yep, it's a good advice, thanks. In the end, I have emulated the pane behavior I was looking for by creating a transparent path control that covers all the FP. When VI is frontmost, the path control goes invisible, allowing the user to manipulate the rest of controls as usual. When VI is not frontmost, the path control goes visible and so it catches the files the user drag'n'drop from Windows.

Maybe not the cleanest solution, but it works.

Thanks everybody,

Aitor

Aitor: I've used this technique on several occasions -- it works very well.

Don't forget about Mac:

ftp://ftp.ni.com/support/labview/updates/...0.1_Updater.dmg

ftp://ftp.ni.com/support/labview/updates/...adme_8_0_1.html

And Linux:

ftp://ftp.ni.com/support/labview/updates/...lv801-linux.tar

ftp://ftp.ni.com/support/labview/updates/...adme_8_0_1.html

Status Update: Fixed in 8.0.1

Status Update: Fixed in 8.0.1

Status Update: Fixed in 8.0.1

You can just associate "Value Change" event to the control path. It works well. See attach VI.

I agree with Adnan. Use the Value Changed event for this.

It is a good idea to always close any explicitedly opened refnums!

Rolf Kalbermatter

I think that you wouldn't want to close the process reference in the "spawning" VI, since this could kill the process (since Auto Dispose == TRUE). What I usually do, is pass the reference to the spawned process (via Set Control Value) and let the process (explicitly) close its own reference.

I'm not useing the CBRN because I need the plugin to run in parallel to the rest of the app - if I use the CBRN then I need to wait until it's completed exectuion for my main to keep running (don't I?)

You could create a "wrapper" VI for the CBRN that you invoke using the run method. Make the wrapper VI reentrant and pass 0x08 (prepare for reentrant run) to the "options" input of Open VI Reference, when you open the wrapper, to allow multiple instances of the wrapper (and therefor multiple plugins) to be spawned. Make sure to set Auto Dispose Refnum to TRUE, so that the lifetime of the wrapper is decoupled from the VI that spawns it.

I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

As Jean-Pierre mentioned, VI Server knows whether a VI reference was opened strict, and it uses this to know whether you can or cannot use a CBRN to invoke the VI. What I suggest that you do, is open two seperate references: one strict, and one non-strict. Use the strict reference, only for validating that the VI's con-pane is correct (matching your plug-in conventions). Use the non-strict reference to invoke the Run method. Make sure that both references are opened before closing the strict reference, or you may incur the overhead of loading the plug-in VI into memory twice.

BTW, why are you not using the CBRN to invoke the plugins? If you are enforcing a strict con-pane adherance of plug-ins, then this might be the best approach.

it could be a problem with your terminal block. they sometimes go bad.

I have tried this manually, by renaming .svn to _svn, but with no effect.

Thanks for testing this. It's too bad that it didn't work.

Hi all,

When I try to MassCompile directory under Subversion control LabView try to Mass Compile FOOBAR.vi.svn-base file in .svn subdirectory.

This spent a lot of time and it isn't exactly what I want to do...

It is posible to set some MassCompile Option to force ignore .svd directory ??

Thanks a lot,

Vladimir

You might try installing TortoiseSVN with the .Net Hack option, which can be selected during installation and causes the .svn folders to be named as _svn instead. This might (I have not tested it), cause the mass compile utility to ignore the _svn folders -- there are several instances where LabVIEW ignores folders and files whose names begin with an underscore.

You don't have to sit next to him every day! Is there some long-standing joke I'm unaware of that I should be giving him crap about?

Even if there wasn't, now's a great time to start one

Jim,

The two links you referenced no longer work. Can they be fixed?

TIA,

Warren

We are looking into it. A transfer of the site to a new server has given us some grief and we have not yet been able to resolve this issue. Thank you for your understanding.

Jim, since you didn't put any smilies there I'll assume your question is serious and respond by saying that if the birth date in Pat's is correct, that means that he was only 3 when the man in the picture (which I shall refer to as J.K.) founded NI. Does that help you recognize him? And just to be on the safe side - .

Assuming that any of my questions are serious is a huge mistake. And, if you think about it, there was a Smily in my post.

What I have done in the past is put a free label where I want a comment, but only put in a number (1, 2, etc.). Below all my code I have a very large free label with a numbered list of comments. This allows the code to be fairly compact but still fully commented. It might not work for everyone, but it works for me.

Pat

Hey, Pat: you look very familiar (). Have we met?

To parse your input string, why not split the string at the "space" and handle the two parts separately?

Personally, I'd definately go with Jim's method - the "unit" of data is a very underused feature of LabVIEW, and (as Jim says) as long as you keep your units consistant, it takes care of itself (eg: wiring a control in meters and a control in seconds to a divide primative will yeild a solution in m/s - if you wire that to an indicator with units other than m/s will give you a broken arrow).

And, if you want a pure number (without physical units) in your application, just drop a Convert Units node downstream of the conversion VI that I posted.

First write the units string to the Numeric's UnitLabel.Text property. Then write the value (as a string) to the Numeric's NumericText.Text property. Make sure to write the properties it in exactly that order, otherwise you will might write the value in the '"previous" units and then convert to different units. This technique is very nice, because it will generate an "incompatible units" error, if you try to write to units that are not known or of different base units.

Download File:post-17-1140297695.vi

kjimcarrey: Try zipping up your attachments into a single file. This will make it easier for others to download and help you.

From page 83 of the upgrade notes: http://www.ni.com/pdf/manuals/371780a.pdf

*****************************

File Size Improvements

Saving VIs from earlier versions of LabVIEW in LabVIEW 8.0

significantly decreases their file size. The file size of VIs you save in

LabVIEW 8.0 is about 55% less than the file size of the same VIs in

LabVIEW 7.1. The file size of LLBs in LabVIEW 8.0 is about 20% less

than the file size of the same LLBs in LabVIEW 7.1.

*****************************

Pretty cool stuff

Joe (orko)

zlib compression has been around for years. It's about time.

Nice toy to know about. Have you used this in any non-trivial applications or is this a spelunking souvenir?

Yes, I have used it in non-trivial applications.

i heard rumors, LV 8.0.1 is allready in the queue?

maybe this will kill the remaining options very soon?

Scripting exists. Scripting works. Scripting makes scripting.

The only way (right now) to take away scripting is to make scripting not work.

But, NI needs scripting to work, since NI uses scripting. So, scripting will remain.

The only way to kill so-called *unauthorized* scripting is to fix significant problems in LabVIEW security, which is a tradoff that I will gladly accept once it arrives, and I will send NI my most sincere thanks and appreciation. We are already seeing some security improvements with Project Libraries in LabVIEW 8.0.

Cheers,

:worship: LV Merge! :worship:

We can only wait and hope that it is in the works behind NI's curtain...

Joe (orko)

Text merge is easy. LabVIEW merge is very hard. Don't expect it to come from NI, unless they will make money off of the feature.

It's a long time ago that I tried lvdiff, but a comparison alone is not really enough.

For it to be really useful, I think it should be possible to also create patches (from cvs for example) and you should have the ability to apply those patches to a set of VI's.

Feel free to write a LabVIEW merge tool and post it here, once it's ready.

Hi Jim,

I have to say I am a bit surprised, 37% for LV8... I am not using it at the moment because I heard to say that it's not totaly"dry".

Do YOU have any comments about the results ?

TiTou: Well, I did cross-post this question to the LabVIEW forum on the developer zone. There are a lot of beginners there, who might only have a copy of LabVIEW 8.0.

What are you thinking about stability and usefullness of LV8 against LV7.1.1?

I have an Dev.Suite with auto-update, so LV8 is availabel. But my main job is a rather big existing project. During beta phase of and later with the final LV8 I did some tests updating parts of my app. Maybe I did not took enough time, but my impression was, it's not worth the hassles.

So for the moment I'll stay with 7.1.1.

Any hints/comments?

Greetings from Germany!

--

Uwe Frenz

Uwe: Personally, I am probably going to wait for the 8.0.1 bugfix. However, I am just one guy -- take a look at this poll to see what others are thinking about migrating to LabVIEW 8.0.