Re : Re: Re : conditional disable no longer works

[cgibson]

Attached is an example of this problem. The main application calls a driver source distribution in an LLB. It is not possible to run any but the default case of the driver LLB from the EXE application.

[JeffL]

cgibson,

If I open your project, add a conditional variable to the project (in properties) of CUSTOMER (a value of B) and build the executable, it finds the B code just fine. This is the expected use of the conditional disable.

[cgibson]

Hi Jeff,

It is not clear to me what you did that made it work.

I presume that since you are making an executable that you are putting the conditional symbol in the main application project. On my machine this does nothing. In other words I can set the CUSTOMER == B in the main project all day long and the executable will still call the A case in the driver. (This makes sense since the conditional disable is a compile time setting and there are no conditional disable cases in the main application.)

If you set the symbol in the driver project, and then made an executable of that project, then this defeats the purpose of the exercise. The driver is not meant to be an executable. The driver is meant to be some form of LLB that will then be accessed by the Main application with VI server techniques. Since LV 8.2, it is not possible to access an exe or a dll as a LLB and use VI server techniques. We are using LV 8.6 and will be going to LV 2009 or 2010 before too long. What remains to us is the Source Distribution, which does not process conditional disables.

[StephanieA]

I was also able to get this to work following what Jeff did using LabVIEW 8.6.

To accomplish this I right-clicked on the Project:Main Application.lvproj and selected Properties. The Project Properties box pops up and I then selected Conditional Disable Symbols. I entered in 'CUSTOMER' for the New Symbol and 'B' for the New Value and Added the symbol. I then built the executable and after browsing to the llb, I was able to select Get LLB Value and have the String display 'Customer B Driver.'

Does this help to clarify what we did to make your application work?

[clendon.gibson@canrig.com]

Yes it does. Thank you.

Unfortunatly, this does not work for me.

Seeing these responses, I have carefully tried to retrace your steps in the example. I do not get the same results.

The only discrepency I can see is that I am using LV 8.5, not 8.6. (I posted that I was using 8.6, but that is not correct.) Does this make a difference?

These are my steps:

I unzipped the file I posted here. I went in to the resulting folder and open the Main Application project. I added the conditional disable symbol "CUSTOMER" set to the value B. I did this by opening the Properties dialog under the Project menu and going to the Conditional Disable Symbols section. I then built the application with the existing Build specification "My Application". I made no other changes. Once the build is complete,I exit LV.

When I run the build, I browse for the driver.llb that came with the zipped example. When I hit the Get LLB Value button, I get Customer A.

I have done this three or more times taking pains to check for typos and other silly mistakes.

This brings up a question.

Are conditional disable symbols retained by the final executable? This would seem to be necesarry if they can set the correct cases in code that is loaded after the application is built and that has itself not been compiled.

I think that the solution proposed does not really fit the bill. Since the conditional disable that controls the driver function lives in the application, we would in effect have multiple versions of the entire application. If a customer's situation changed such that a new driver was needed, we would need to deliver a whole new application, rather then the plug-in which is where the real changes exist. (Ok maybe not the whole application, but at least the binary for the main application. It is certainly doable, but does seem contrary to the idea of a plugin archetecture.)

This can be readily resolved by adding an option to the build process to exclude unused conditional disable cases from Source Distributions.

[rolfk]

I think you are barking up the wrong tree here. Conditional Disable is a compile time setting, so will even apply at the time before you build an executable. As long as you run this in the development environment the disabled VI will be of course still on the hard disk at the expected location, but as soon as you build a distribution or executable, LabVIEW throws out all this code to reduce the foot print of the result.

It would seem to me that you do not really want to do compile time disabling but rather runtime disabling. In that case you should instead use a normal case structure that selects which code needs to be executed. If the issue is that your application could get broken because some of the included code may be referencing unavailable functionality, you can overcome this by using dynamic calling of the problematic VIs.

I have used this method regularly to create a plugin type interface that was referencing potentially unavailable drivers such as ActiveX or DLLs that depend on other secondary DLLs that might not be available on certain computers.

The idea is to use VI server to call into the specific VI whenever that is needed. If you architect the whole thing cleanly you only need one dynamic caller and the according top level VI(s) for the plugin drivers. Of course it's the idea that the calling code should know when it can call a particular plugin instance based on automatic detection or user configuration, but if that goes wrong you simply get a run time error from the Open VI Reference or Call by Reference node and can handle that accordingly.

[clendon.gibson@canrig.com]

Hi Rolfk, Bark! ;-) A runtime selection means I have to add support for that in my existing main application. This extra code is also making a decision in run time that does not need to be made then. We already know what the correct decision is at compile time. Why put extra code in to the project which then has to be supported and debugged to handle a decision that only needs to be made once? At least that is my situation. I can see the benefit in your case where everytime you run you need to check for the presence of the DLLs or otherwise handle it if they are missing. One way to resolve my issue is to make three seperate plugins. I do by hand what I would like the conditional disable to do automatically. (i.e. select at compile time which code to distribute...)

[Intaris]

---

clendon.gibson@canrig.com wrote:

I think that the solution proposed does not really fit the bill. Since the conditional disable that controls the driver function lives in the application, we would in effect have multiple versions of the entire application. If a customer's situation changed such that a new driver was needed, we would need to deliver a whole new application, rather then the plug-in which is where the real changes exist. (Ok maybe not the whole application, but at least the binary for the main application. It is certainly doable, but does seem contrary to the idea of a plugin archetecture.)

---

Yes.  You would need a different binary for different conditional disable settings.  This is what the conditional disable structure is for.  Think multiple platform support.  Here you CANNOT compile all paths, so those you currently do not want will NOT be compiled into the exacutable.

What you want to do is something else so you will need to use a different tool.

Shane.

[Intaris]

---

clendon.gibson@canrig.com wrote:
Hi Rolfk, Bark! 😉

---

It used to be possible to load a VI into memory via the command prompt by calling "MyApp.exe -Extravi.vi" or something similar.

You can abuse this (assuming it still works) to load a VI you are calling (same names, but loading from different locations via command prompt) when starting the program.  I think you MIGHT have to have a dynamic link to the VI (static link might prevent the original app loading at all thus throwing a spanner in the works) and you need to make sure the VI you are trying to use as a plug-in is NOT included in the executable.

If you load the executable without a required VI you'll thus be missing the functionality.  If you need to deliver a new set of functionality, you create the new VI and create a new shortcut with the appropriate command line parameters for the app and you're good to go.

I'll see if I can find an old link on the subject.

Shane.

PS Woof!

[Intaris]

I just tried this out in LV 2009 SP 1.  It still works.

If I create an EXE called "Small.exe" which calls (directly, not via reference) a VI called "Piggy 1.vi" and build it, everything is normal (Piggy 1.vi is included in the build).

If I create a command-line with "Small.exe" "\Version1\Piggy 1.vi" (two double-quoted entities on the same command line) then the program will load with the NEW VI instead of theold one.....

This way you can SELECTIVELY override certain VIs in an EXE via command line.

I smell a nugget.

Shane.

PS HERE's an example.  Run the "Small.exe" and then run via shortcut with "\path\Small.exe" "\path\Piggy 2\Piggy 1.vi" set as the command-line and see the VI included in the build being replaced with the newer one.