A couple of suggestions

[WNM]

Recently I needed to build a VI (under Win98, LV 6.0.2) that was destined to be turned into an application with the App Builder. When I did so, I discovered one aspect of the application that did not behave the same as the VI, concerning the results that �Strip Path� returns. Since I wanted the VI and the application to both be functional I figured it would simple enough to put in a check to see if it was running as a VI or as an application and then handle the Strip Path results accordingly. I went looking for a VI property node item that would tell me whether the code was running as an application or VI and didn�t find one. I tried the NI web site but it was down. I called into NI and (after several annoying minutes on hold lis
tening to a recording telling me how useful and available the NI web site was) asked about how to determine the running environment and was told there was no straight-forward way. I came up with a simple-enough workaround to my problem but there really should be a VI property node item to provide this information.

A second wish-list item concerns �enum� constants. Basically I would like something akin to the ability available for controls and indicators to create a �strict type def� where you can make a change in one place and it will propagate to all places where the item is used. This strict type def�ing of enum constants would logically be coupled to associated enum controls and indicators so perhaps it could be an extension of the strict type def�ing that is already available for enum controls and indicators. [Why do I want this? State machines (case statements within while loops) built using enums are much easier to understand than those built with numbered states but are much
more difficult to add or remove states because it is difficult to update all instances of the enums!]

[jwf]

As to your second complaint, I have an easy work around for your problem. On the diagram drop a global, open the global and put a enum and set it up as you please. Use this global any where in your diagram. Now change it and these changes will take effect everywhere.

[WNM]

While a global used everywhere does allow for easy (global) changes in the structure of the enum, it does not allow different instances of the enum to have differing values. All instances must have the same value, the one dictated by the global. I want a globally-updatable structure with the ability to set independant values.

[David Thomson]

Warren,
Good news on both accounts:

Warren Massey wrote:
>
> Recently I needed to build a VI (under Win98, LV 6.0.2) that was
> destined to be turned into an application with the App Builder. When I
> did so, I discovered one aspect of the application that did not behave
> the same as the VI, concerning the results that �Strip Path� returns.
> Since I wanted the VI and the application to both be functional I
> figured it would simple enough to put in a check to see if it was
> running as a VI or as an application and then handle the Strip Path
> results accordingly. I went looking for a VI property node item that
> would tell me whether the code was running as an application or VI and
> didn�t find one. I tried the NI web site but it was down. I called
> into NI and (after several annoying minutes on hold listening to a
> recording telling me how useful and available the NI web site was)
> asked about how to determine the running environment and was told
> there was no straight-forward way. I came up with a simple-enough
> workaround to my problem but there really should be a VI property node
> item to provide this information.
>
If you use an application property node, then under
Properties/Application, choose Kind. This will return an enumerated
with values of "Development System" or "Run Time System" depending on
whether or not you are running within LV or running a built app. (Too
bad NI tech support couldn't point you there!)

> A second wish-list item concerns �enum� constants. Basically I would
> like something akin to the ability available for controls and
> indicators to create a �strict type def� where you can make a change
> in one place and it will propagate to all places where the item is
> used. This strict type def�ing of enum constants would logically be
> coupled to associated enum controls and indicators so perhaps it could
> be an extension of the strict type def�ing that is already available
> for enum controls and indicators. [Why do I want this? State machines
> (case statements within while loops) built using enums are much easier
> to understand than those built with numbered states but are much more
> difficult to add or remove states because it is difficult to update
> all instances of the enums!]

You are right, this is very useful. It is also very possible. Just
create a typedef enumerated control with the values you want. Save it
to disk. Then, from the block diagram, use "Select a VI" at the bottom
of the pallette and go find the control in your file system. It will
appear as a constant on the block diagram, and will be connected to the
typedef. In this case, you don't even need a copy of the control itself
on your front panel. If you the same on the front panel, you will get a
copy of the control, which you can use to generate constants. One
caution - once you start using these typedef constants, be somewhat
careful about how you duplicate them. If you clone them (CTRL-drag),
the new copies will be linked to the type def. There used to be some
cases for which the copies would look the same, but not be connected to
the type defs. I can't duplicate this behaviour now, so maybe that was
fixed in LV6.

Regards,
Dave Thomson

-------------------------------------------------------------
David Thomson 303-499-1973 (voice and fax)
Original Code Consulting dthomson@originalcode.com
www.originalcode.com
National Instruments Alliance Program Member
-------------------------------------------------------------
Research Scientist 303-497-3470 (voice)
NOAA Aeronomy Laboratory 303-497-5373 (fax)
Boulder, Colorado dthomson@al.noaa.gov
-------------------------------------------------------------

[WNM]

Dave,
You are right on both counts! I don't know why NI tech support couldn't point me at the Application properties/Kind item (I was looking in VI properties) but what you suggested does indeed work.

I'm even more delighted to find that the strict typ def'ing of a control/indicator extends to constants derived from it and then used elsewhere! I've already started modifying VIs to take advantage of it! Thanks!

[Jim_Kring]

In response to your first issue, the following is a tool to detect whether your code is running in an *.EXE

-Jim

[WNM]

Jim,
Thanks for the reply and the examples. I have included a couple of files of my own that illustrate the simple way I used to find the directory that contained either the VI or application that was being run. To run the .EXE version of the VI you'll need to have the LV runtime environment installed (available to all from the NI web site).

Note that included in the same VI is a simple example of how to determine whether or not an EXE file is being run. It, however, is not needed in the determination of the host directory. I've just bundled two examples into one VI.

[JB]

Dear Warren,

this property does exist! Just go to the function palette --> Application Control --> Property Node. By default, the function applies to "App", if not, right-click on the upper (yellow) part of the function --> Select VI Server Class --> Application.

Right-click on the lower (white) part of the function --> Properties --> Application --> Kind.

That's it!

[WNM]

David Thomson on 3/9/2001 (2 days earlier) already provided this answer plus more...