LabVIEW VI Analyzer: Expose Error Highlighting feature of the UI to toolkit API.

[SherL]

Hello,

So as it is The VI analyzer has some limitations:

1. You can't fully customize the toolkit as some functionality is still not exposed as an API.

2. You can't build an executable with a VI analyzer.

I was hoping that NI could expose some more API that would allow for programmatic control of the error highlighting feature of the VI analyzer.

This will allow for creation of a more standalone application rather than being piggy-backed into the LabVIEW environment.

Thanks, Sher

[wiebe@CARYA]

>This will allow for creation of a more standalone application rather than being piggy-backed into the LabVIEW environment.

VIAnalyser uses scripting. If a VIA executable was to be made, it would still require the development environment to do the scripting. A lot of scripting is simply not available in the RTE...

[crossrulz]

What kind of executable are you trying to build?  VIA is meant for static code analysis.  It makes no sense at the compiled level.

[wiebe@CARYA]

A VIA executable could make sense for instance when making a CI (EDIT: Continuous Integration) machine. That machine could run the VIA executable in stead of LabVIEW development.

[SherL]

Hello crossrulz,

We are building test machines deployed across several MFG sites worldwide.

Whenever we deploy these machines we remove the development licenses but sometimes these machines needs software improvement from time to time. So we still need to make sure test engineers across sites adheres to our standard programming practice as such the need for an executable.

Hello Weibe@CARYA,

Yeah, it is kind of unfortunate though that scripting limits this capability among other features in LabVIEW?

But isnt Report Generation Toolkit also part scripting? But I did remember creating an executable with the toolkit in.

Thanks for all the reply!

[wiebe@CARYA]

Yeah, it is kind of unfortunate though that scripting limits this capability among other features in LabVIEW?

Yes, I could live with full featured scripting in executables. It makes a lot of sense that it isn't possible though.

But isnt Report Generation Toolkit also part scripting? But I did remember creating an executable with the toolkit in.

No, RGT isn't even remotely related to scripting. It use references (VI Server. not scripting), and maybe (not sure) there is an express VI that might use scripting to generate code. It does not need scripting in any way to generate reports.

[AristosQueue (NI)]

> but sometimes these machines needs software

> improvement from time to time

Doesn't that mean that there's a full IDE available to do the edit? I am curious what kinds of changes can your test engineers make without the IDE that would still require VI Analyzer to check?

[AristosQueue (NI)]

This seems like it need to be split into two separate ideas. The first idea about enabling VI Analyzer to be standalone from IDE is probably not going to happen -- there's no support for block diag references compiled into the run time engine, and that is deliberate and inviolate. The second idea about exposing more error highlighting API seems like a reasonable request. But then you mention that exposing the error highlight API is only needed in order to facilitate building VI Analyzer as an app, so I'm going to ask that we decline this whole idea. If the error highlighting API is useful on its own in the IDE, please refile it as its own idea with an explanation of what it is that you want to be able to highlight that you cannot highlight today.

[wiebe@CARYA]

I think a VIA executable has a use case (not sure if that is proposed).

If developers world wide get a VIA executable, that would enable them to test there code with that executable in the development environment. That would make the VIA executable just a distributable, embedding all VIA settings of (for instance) the software lead. That would force all development teams\sites to use the same settings, that can't be tempered with (on purpose or by mistake). Just thinking out loud...

It would not require scripting features in the RTE, as the VIA executable could invoke the methods on an application instance of the development system. I'm not sure how VIA is set up, but that might not be too difficult.

[SherL]

Hello AristosQueue,

The full IDE is installed, yes, but our Custom interface Teststand calls the RTE during production mode.

When there are tester ECO due to addition/removal/change of test codes, that is when on site test engineers can do the development.

However, we need to make sure that "our" standard programming practices must be followed regardless of who is doing the edits.

I would be inclined to file a separate idea for the highlighting part. Just in case you guys are able to pick it up and be able to do the changes on the next iteration of the toolkit.

Thanks, Sher

Hello

[Darren]

Declined for reasons listed by AristosQueue in the idea discussion thread:

"This seems like it need to be split into two separate ideas. The first idea about enabling VI Analyzer to be standalone from IDE is probably not going to happen -- there's no support for block diag references compiled into the run time engine, and that is deliberate and inviolate. The second idea about exposing more error highlighting API seems like a reasonable request. But then you mention that exposing the error highlight API is only needed in order to facilitate building VI Analyzer as an app, so I'm going to ask that we decline this whole idea. If the error highlighting API is useful on its own in the IDE, please refile it as its own idea with an explanation of what it is that you want to be able to highlight that you cannot highlight today."