Dinamicly create vi in a builded application

[Attila]

Hi!

I created a module for my application what uses vi scripting technology for dynamically create controls in a new vi.

This is a wonderful feature of labview, but when i build my application and run the exe file, i get an error with code 53.

The Source text is varying.

In my example: I get this error when i try to create an object: 'New VI Object in Visualization.lvlib:mod_create_UniConstans.vi'

Is there any way to build an application when i use the vi scripting?

[LAVA 1.0 Content]

QUOTE (Attila @ Sep 19 2008, 01:21 PM)

Hi!

I created a module for my application what uses vi scripting technology for dynamically create controls in a new vi.

This is a wonderful feature of labview, but when i build my application and run the exe file, i get an error with code 53.

The Source text is varying.

In my example: I get this error when i try to create an object: 'New VI Object in Visualization.lvlib:mod_create_UniConstans.vi'

Is there any way to build an application when i use the vi scripting?

I think you can not build such an application- if possible you coud "just" make an exe and with this exe you could make new LabVIEW code, without LabVIEW licence. That's probably not the wisch from NI...

[crelf]

QUOTE (Attila @ Sep 19 2008, 07:21 AM)

I created a module for my application what uses vi scripting technology for dynamically create controls in a new vi. This is a wonderful feature of labview, but when i build my application and run the exe file, i get an error with code 53.

That's not enough info to diagnose the issue - please post your code.

[Attila]

QUOTE (martin@aerodynamics @ Sep 19 2008, 02:25 PM)

I think you can not build such an application- if possible you coud "just" make an exe and with this exe you could make new LabVIEW code, without LabVIEW licence. That's probably not the wisch from NI...

In this case this is a useless feature of labview.

If I can not build such an exe than it's just a game for the developers. It should rather to NI allows us to create vi to the memory and disallow to save that to the disc.

Sorry for my English & thanks the reply.

QUOTE (crelf @ Sep 19 2008, 03:28 PM)

That's not enough info to diagnose the issue - please post your code.

The code is very simple: Just place a "New vi" of app_control_plus to block diagram and build it.

[PJM_labview]

QUOTE (Attila @ Sep 19 2008, 08:43 AM)

In this case this is a useless feature of labview.

I would have to disagree. Not being able to do scripting in build application does not make it a useless feature. You can create countless of helper tools using scripting that will make your job as a LabVIEW developer a lot more efficient (just search that forum for several example of such tool).

In regard to your particular use case, what were you trying to do? There might be alternatives in achieving your goal without using scripting.

PJM

[crelf]

QUOTE (Attila @ Sep 19 2008, 11:43 AM)

The code is very simple: Just place a "New vi" of app_control_plus to block diagram and build it.

Works fine for me in 8.5.

QUOTE (Attila @ Sep 19 2008, 11:43 AM)

If I can not build such an exe than it's just a game for the developers.

I don't agree: ability to build doesn't necessarily track to the value of the code. There are plenty of situations where I don't (and never plan on) building code (eg: internal tools that install into the project folder).

QUOTE (PJM_labview @ Sep 19 2008, 12:44 PM)

You can create countless of helper tools using scripting that will make your job as a LabVIEW developer a lot more efficient.

PJM_labview beat me to it

[PJM_labview]

QUOTE (crelf @ Sep 19 2008, 10:13 AM)

PJM_labview beat me to it

This got to be a first on LAVA (that I actually answer faster than you on a topic) ...

PJM

[Attila]

I guess you are right, this can be helpful. We can develop useful scripts for own work.

But in my situation this isn't the right way, when I want to make an end user application with this technique.

I will do my job with an alternate way.

Thanks the replies.

[crelf]

QUOTE (PJM_labview @ Sep 19 2008, 01:30 PM)

This got to be a first on LAVA (that I actually answer faster than you on a topic) ...

You've got an advantage: you're closer to the phsycial LAVA server

[Francois Normandin]

QUOTE (crelf @ Sep 19 2008, 03:00 PM)

You've got an advantage: you're closer to the phsycial LAVA server

Are you sure of that?

http://lavag.org/old_files/monthly_09_2008/post-10515-1221855818.png' target="_blank">

Depends where in Canada...

[Yair]

QUOTE (Attila @ Sep 19 2008, 06:43 PM)

In this case this is a useless feature of labview.

If I can not build such an exe than it's just a game for the developers. It should rather to NI allows us to create vi to the memory and disallow to save that to the disc.

Scripting isn't officially a feature of LabVIEW. NI does not support it and not all of it is implemented.

In any case, you should note that the problem is not with saving the VI. The problem is that after you create the diagram, that diagram needs to be compiled into machine code. The compiling code is only found in LabVIEW, not in the run-time engine.

As the others mentioned, if you explain your actual use case, another solution might be offered.

[Aristos Queue]

QUOTE (Attila @ Sep 19 2008, 06:21 AM)

Is there any way to build an application when i use the vi scripting?

I'm surprised there was any debate on this question.

No. Scripting is not compiled into the runtime engine (lvrt.dll). The editor and the compiler are missing from the runtime engine. You can only do scripting -- if you have the appropriate license or have found a back door -- in the development environment. There is no secret key that will allow you to do scripting in the runtime engine. Not even NI developers can do scripting in the runtime engine. It is a feature of the full development environment only (labview.exe).

Any property or method that makes a change to a VI that requires recompilation of the VI will fail in the runtime engine. Many others that require an editor environment will also fail.

[mike_spacex]

Not sure if it's against the labview development license so I never developed it, but I did consider making a tool for test engineers to make simple modifications to their UIs or create one from scratch in a way that the scripting was done on a different computer (running the LabVIEW developement envir.) then the created VI would be exported to their machine and loaded dynamically in the run-time environment. It would just be a slight modification from a tool I built to help developers using my software architecture to quickly design and deploy UIs using an easy drag-&-drop interface. I was planning on using the VI property 'FP.Get Image' and transferring the image data through Network Shared Variable to an interactive viewer on the engineer's system. When he's satisfied with the changes, the "server" scripts the necessary block diagram code then saves the VI to a network file server so it's available for the 'client' system to copy locally, load, and run. I planned on limiting functionality to create, destory, and move controls and indicators on the UI and specify their linking to monitor and control parameters in his system. Definately possible, but is it legal? If you're curious what the developer's tool looks like, I attached a screen shot.

[Yair]

I'm not sure if it's against the license (at least if you're using an older version of LabVIEW to write the scripting code), but I haven't looked at the EULA and I'm not a lawyer.

By the way, if you can make a case for needing scripting and you ask nicely, NI might actually give you a scripting license. I've heard of people who got that, but I have no idea of the details and I assume it's a small amount of users.

FWIW, there are also other ways to do dynamic GUIs (e.g. picture control, making "enough" controls, etc.), but they each have their own set of problems.