Home Community Idea Exchange LabVIEW Ideas Idea

LabVIEW Idea Exchange

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
SherL

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

Submitted by Member on ‎03-17-2019 11:02 PM 15 Comments (15 New)
Status: Declined

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."

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

View All (2)
15 Comments
wiebe@CARYA
Knight of NI Knight of NI
Knight of NI
‎03-21-2019 03:10 AM
‎03-21-2019 03:10 AM

The idea of having a distributable VIA is a sound idea. (Not even sure if there are alternatives for that.) When working in teams, that would be a nice to make sure everyone uses the same standard.

 

AFAIK, an executable can do scripting, but it needs the development environment to execute it. As I read the idea, that is what was proposed. So, not impossible.

 

Mixing two ideas is not very practical. If I where OP, I'd post as two separate ideas, and put the lessons learned from this idea into them. The minute an idea is misunderstood, chances of kudos plunge... So better make them crystal clear.

Search LabVIEW like a graph!
0 Kudos
AristosQueue (NI)
NI Employee (retired)
‎03-21-2019 11:12 AM
‎03-21-2019 11:12 AM

Why not distribute your VIA code as a PPL instead of an EXE? You're still going to have an IDE to make edits. The PPL gives you packaged up code that you can run in the IDE. No need to mess around with complex remote procedure calls to the IDE from an EXE.

0 Kudos
wiebe@CARYA
Knight of NI Knight of NI
Knight of NI
‎03-22-2019 02:44 AM
‎03-22-2019 02:44 AM

@AQ: That might work for OP. I'm not that into PPL nor VIA (yet, on both)...

Search LabVIEW like a graph!
0 Kudos
SherL
Member
Member
‎03-22-2019 03:33 AM
‎03-22-2019 03:33 AM

Hey AQ,

 

We are actually experimenting on using LLB instead with a password-protected BD.

This way not the entire project library is distributed but just snippets of.

What do you think?

 

Thanks, Sher

 

0 Kudos
AristosQueue (NI)
NI Employee (retired)
‎04-11-2019 11:49 AM
‎04-11-2019 11:49 AM

@SherL Should work. Now that LV has backward compatible runtime engine, I've been moving more of my own stuff to PPLs for deployment, so I tend to think in those terms these days for deployment and leave LLBs for editor envionment (especially because LLBs have limitations when trying to package multiple classes together because of the namespace issue). But I don't do very much of that work -- even in my personal projects, I'm more of a tools vendor, not an app developer -- so you may have the same success with LLBs.

0 Kudos