how do i get the reference to frontmost vi

[i2dx]

another question:

i have some self written tools (like automatic tunnel wiring wizard, etc ..) but all these tools lack of the possibility to use them directly from the tools menu for the frontmost vi.

Using the "Active VI" property will give me back a reference to the tool-vi, not to the frontmost vi i am working on. what i do now is, to open an application reference, look for all vis in memory and show all these in a listbox, who do not have callers and let the user (me) select the top level vi.

but that's not the best solution, i think and if someone knows how to get the reference to the frontmost vi i would really appreciate some help.

best regards,

cb

[Jim Kring]

another question:

i have some self written tools (like automatic tunnel wiring wizard, etc ..) but all these tools lack of the possibility to use them directly from the tools menu for the frontmost vi. 

Using the "Active VI" property will give me back a reference to the tool-vi, not to the frontmost vi i am working on. what i do now is, to open an application reference, look for all vis in memory and show all these in a listbox, who do not have callers and let the user (me) select the top level vi. 

but that's not the best solution, i think and if someone knows how to get the reference to the frontmost vi i would really appreciate some help.

best regards,

cb

2927[/snapback]

The Application Control library of the OpenG Toolkit has two VIs, which are useful for this:

* Find VI with Focus

* Find Frontmost VI

[Norm Kirchner]

Acutally the ActiveVI property does not return the reference to the tool.

It returns the reference to the vi which has had an object selected in it.

See attached VI. I run the VI and it stays on top, and whenever I need it to work I select the objects to be operated upon, and press the button in the tool and it modifies the elements that have just been selected, just like in the tunnle wizzard.

For those of us who like to have our BD terminal lables (non-icon style) line up to the right for controls this is the utility for you. Just leave this running in the background and whenever you have a few control terminals whose lables you want to right justify and align w/ the right edge click the button. IT IS VERY MESSY IN THERE SO USER BEWARE.

~,~

Download File:post-208-1102280175.vi

[David Boyd]

IT IS VERY MESSY IN THERE SO USER BEWARE.

~,~

2937[/snapback]

Norm, you crack me up. :laugh:

Now everyone knows the REAL reason why I locked the BD on the tunnel wiring tool... You call THAT messy...? ('Course, judging by some clues, you already know what's lurking back there...)

Dave

[Mike Ashe]

Now everyone knows the REAL reason why I locked the BD on the tunnel wiring tool...  You call THAT messy...?)

Dave

2956[/snapback]

Okay, Dave, if the only reason is messiness, could you consider releasing the code at this time. I absolutely, completely, honestly and truely promise that none of us will laugh. :laugh:

Perhaps some of us could add an extra feature or so and do a little sweeping in the process.

Your utility is cool, :worship: but it would save us :headbang: if we didn't have to recode it all

Thanks in advance!

[i2dx]

Okay, Dave, if the only reason is messiness, could you consider releasing the code at this time. I absolutely, completely, honestly and truely promise that none of us will laugh.  :laugh:

Perhaps some of us could add an extra feature or so and do a little sweeping in the process.

Your utility is cool,  :worship:  but it would save us  :headbang:  if we didn't have to recode it all

Thanks in advance! 

3192[/snapback]

100% FULL ACK !

posting password proteced VIs here is useless i think, because it's the code we are all worrying about ...

best regards

[David Boyd]

100% FULL ACK !

posting password proteced VIs here is useless i think, because it's the code we are all worrying about ...

best regards

3247[/snapback]

While I respect your enthusiasm and involvement, I must politely disagree.

Even though this excellent set of forums (for which I heartily thank Michael for creating and tirelessly maintaining) is part of a group named LabVIEW Advanced Virtual Architects, it's still a public website. As we've seen countless times, participants vary widely in their LabVIEW experience.

The tool I wrote was one simple example of using scripting features that are undocumented and unsupported by NI, to automate a specific task that a fairly advanced LV developer would encounter. (I'm certain that many inexperienced LV users here have never used a state machine construct in their code, but that's another point.) I published it here for several reasons:

• It's a useful tool which I can give to the community.
  
• It's a practical demonstration to gently show NI's developers/decision makers how a released scripting feature could make LV users more productive.
  
• And I'll admit, it's a bit of a 'hot dog' move (translation: it says, "Look at what I can do!").
  

Judging by the number of download hits, and the other posts here, it's been useful even though I left it locked. And I did so at the time because, to release it openly, would have been to put a lot of undocumented/unsupported features on a public website.

Now I have no qualms whatsoever about lobbying NI for releasing and documenting these features, but I respect my relationship with NI and will not compromise their internal 'roadmap' for making scripting publicly available.

I understand that you may not agree with my reasoning. However, nothing prevents you from using the other details of LV scripting which have been posted here to work out your own uses for it.

With best regards,

Dave

[i2dx]

Even though this excellent set of forums (for which I heartily thank Michael for creating and tirelessly maintaining) is part of a group named LabVIEW Advanced Virtual Architects, it's still a public website. As we've seen countless times, participants vary widely in their LabVIEW experience

even though this opposes my goal (seeing your code ) i understand this argument and have to agree.

what i liked to see was, how you deal with the problem of finding the objects. in many of my scripting applications this is a verry uggly accumulation of nested for/while loops and case structures. you surely know well why and how ;-)

i have a half finished wiring tool myself. maybe if its ready we can do a "code exchange" and learn from each other ? :thumbup:

best regards,

cb

[jpdrolet]

another question:

i have some self written tools (like automatic tunnel wiring wizard, etc ..) but all these tools lack of the possibility to use them directly from the tools menu for the frontmost vi. 

2927[/snapback]

Back on topic, I think that what you need to determine from which VI Tool menu a tool was launched is the Application property App.MenuLaunchVI. It returns the name of the launching VI. Use that name to get a reference.

[i2dx]

Back on topic, I think that what you need to determine from which VI Tool menu a tool was launched is the Application property App.MenuLaunchVI. It returns the name of the launching VI. Use that name to get a reference.

3255[/snapback]

that was the missing link !

thank you very much !

:worship:

best regards,

cb

[David Boyd]

Back on topic, I think that what you need to determine from which VI Tool menu a tool was launched is the Application property App.MenuLaunchVI. It returns the name of the launching VI. Use that name to get a reference.

3255[/snapback]

Jean-Pierre,

I'm familiar with that application property, but in fact I didn't use it in the tunnel wiring wizard. It seems more appropriate when you want to launch an action on a particular VI. What I decided I wanted was a floating tool, which needs to get references to the currently selected object(s) on any open FP or BD window (even though in my case, I'm only looking for BD objects). For that, I used App.ActiveVI, then got the SelList[] property from the active VI's BD.

So the developers gave us two pretty handy application properties which are the cornerstone of both menu-launched and floating tools.

I hope this clarifies things for some of the other folks who've been interested in how to create such tools.

Best regards,

Dave

[i2dx]

i think they are both very usefull.

if you want to launch a tool on a frontmost VI the App.MenuLaunchVI is the best method to get the reference.

if you have selected somethin in the block-diagram App.ActiveVI is the fastest method to get the selected items list ...

best regards

cb

[Mike Ashe]

...So the developers gave us two pretty handy application properties which are the cornerstone of both menu-launched and floating tools.

3263[/snapback]

The thing I would like to have now is a single, floating palette of open source tools, that opens up and sits in the corner when I start LabVIEW, and which takes all the current OpenG tools under the .\LabVIEW\projects subdir as plugins and gives me quick one button access. It would be even nicer if NI gives us a way to add this to the LabVIEW toolbar area. They have already given us ways to include our tools in various menus (File>>Restart LabVIEW... or Tools>>Workspace>>Workspace 2003...) now if we can get them into the button toolbar. V8?

[Rom]

The thing I would like to have now is a single, floating palette of open source tools....

:thumbup: :thumbup: :thumbup:

Taht's the point!

We need an OpenG TOOLBAR !!!

Rom

[jhoskins]

Acutally the ActiveVI property does not return the reference to the tool.

It returns the reference to the vi which has had an object selected in it.

See attached VI. I run the VI and it stays on top, and whenever I need it to work I select the objects to be operated upon, and press the button in the tool and it modifies the elements that have just been selected, just like in the tunnle wizzard.

For those of us who like to have our BD terminal lables (non-icon style) line up to the right for controls this is the utility for you. Just leave this running in the background and whenever you have a few control terminals whose lables you want to right justify and align w/ the right edge click the button. IT IS VERY MESSY IN THERE SO USER BEWARE.

~,~

Could you please give me this vi in version 7.0 so that I may have a look at it. i want to do the same thing but cannot figure out how to get the correct reference.

Thanks

Joe

[jhoskins]

Back on topic, I think that what you need to determine from which VI Tool menu a tool was launched is the Application property App.MenuLaunchVI. It returns the name of the launching VI. Use that name to get a reference.

wher can I find this at in 7.0 :headbang:

[jhoskins]

wher can I find this at in 7.0 :headbang:

Thanks anyway I found it. I had to add this (SuperSecretPrivateSpecialStuff=True) to my ini file. :thumbup:

[WMassey]

Acutally the ActiveVI property does not return the reference to the tool.

It returns the reference to the vi which has had an object selected in it.

See attached VI. I run the VI and it stays on top, and whenever I need it to work I select the objects to be operated upon, and press the button in the tool and it modifies the elements that have just been selected, just like in the tunnle wizzard.

For those of us who like to have our BD terminal lables (non-icon style) line up to the right for controls this is the utility for you. Just leave this running in the background and whenever you have a few control terminals whose lables you want to right justify and align w/ the right edge click the button. IT IS VERY MESSY IN THERE SO USER BEWARE.

~,~

Interesting VI.

I might see if I can modify it so it offers a bit more in the way of alignment options.

Have you noticed that the VI which is having its labels aligned does not show up as having been edited after its labels are shifted?

There are no "undo" or "revert" options either. I guess I wasn't quite expecting that from a "scripting" interface.