Enable/Disable Private Methods

[hooovahh]

I don't use private methods often, and as a result I don't know what other methods are available.  When I do turn on private methods I find that there are a ton and they some times will slow down my development, because there are so many that I will not use 99% of the time.  For this reason I find myself enabling and disabling private methods and I wanted an easier way to turn them on and off.  I made this VI (and it's supporting code) to run from the Tools menu of LabVIEW (place in the <LabVIEW>Projects folder) which will change the LabVIEW.ini key, and then restart LabVIEW.

 

 

Disclaimer 1: Private methods are not supported by NI and should not be used in build applications, and are generally only used for tools of development.  

Disclaimer 2: This set of code contains an EXE (pv.exe) and will be saved and executed from the system temporary folder %temp%.  Information about this EXE can be found here.

Disclaimer 3: As stated in the main VI, this will taskkill the version of LabVIEW running, and all unsaved work will be lost.

 

Any feedback is appreciated, thanks.

 

EDIT: This code uses OpenG File Library.

Enable Disable Private Methods.zip

Edited February 26, 2013 by hooovahh

[hooovahh]

is pv.exe bundled with Windows? I cannot find it in my install (hence the reason why you embed it in the code I suppose).

 

Are you sure you are legally allowed to distribute pv.exe in any form?

 

Edit: sorry just followed the pv link you included above, so it's not a windows tool, but am still not sure about the distribution of this.

 

Yeah you are probably right.  I certainly wasn't trying to hide the fact that part of the code was not mine, and that it was part of a freeware application.  I actually found the download on a site somewhere as just an EXE download without any attribution or history of where it came from.  Still the whole two wrongs thing.

 

I tried for a long time to accomplish what this little EXE program does natively, or using VB calls but couldn't find any thing, just some possible ways to do it in C that I couldn't get to work.

 

For those not adventurous enough to run random EXEs off the internet, this EXE has many functions but the one I use is given a EXE name, it will provide the PID(s) for those running applications, and the full path on disk to their locations.  If you open Task Manager you can see the PID column for all applications, and you can right click and choose Open File Location.  This is the functions that I couldn't seem to do with DLL calls to Windows, or VB and .Net calls.

[crelf]

Enable Disable Private Methods.png

.

All unsaved will be what?!?! Don't leave me hangin'!

[Phillip Brooks]

You can set the INI variable and restart LabVIEW using two Invoke Nodes. You will have to confirm "Quit will abort all running VIs" and it should start back up with the correct setting.

 

(LV 2012)

 

[hooovahh]

All unsaved will be what?!?! Don't leave me hangin'!

I noticed that string got cut off after I posted it but meh this isn't the CR.

 

You can set the INI variable and restart LabVIEW using two Invoke Nodes. You will have to confirm "Quit will abort all running VIs" and it should start back up with the correct setting.

 

(LV 2012)

 

Change SuperSecret Setting.png

Again goes to show the Private methods I'm unfamiliar with.

 

Even so I tested your code and it does have that dialog about quitting VIs which is nice.  It does give the user a chance to save any VIs they have instead of killing it.  I would like to point out that my method does takes half the time to perform the goal then yours...of course half in my test meant I saved an extra 5 seconds.  In the future I will be using your version because it is less likely to cause lost development work.

no idea how you get the full path though, other than using the Win32 API

That's the part I couldn't figure out.  How to go from PID --> Full Path.

[JackDunaway]

You can set the INI variable...

 

Slick. +1.

 

 

 

you can get the PID by running "tasklist" from the command line, then just processing the stdout...

 

Slick. +1.

 

 

 

Any feedback is appreciated, thanks.

 

+1 for starting a great topic to drum up some awesome tricks.

[hooovahh]

hooovah, you can get the PID by running "tasklist" from the command line, then just processing the stdout...

 

no idea how you get the full path though, other than using the Win32 API

 

ok try this from a command line: wmic process where name="labview.exe"

 

it returns a whole bunch of guff, but the full path to the executable is in there

Awesome.  I modified the command a little to just get the ExecutablePath and ProcessID

 

 

wmic process where name="labview.exe" get ExecutablePath,ProcessId

Processing this will be no problem thanks again.

 

 

I do however have a new issue.  So I modified my VI be like Phillip showed, and it works when I run the VI, but if I run from the Tools Menu I get "LabVIEW:  Configuration token not found." I believe this is because from the Tools Menu I have a new Application which for some reason doesn't like that function (possibly a limitation of the private method).  I can get the "App.MenuLaunchApp" which will return the application reference that called it and then use that for modifying the key and restarting.  This works as long as I run it from the Tools Menu in an existing VI.  If I try from the Getting Started, this reference is also blank.  I tried opening a new application instance, with the port settings but this also returns the same error.  If I try debugging it then it works.  I must be going crazy over such a simple function.

Enable-Disable Private Methods Phillip Suggestion.vi

[Phillip Brooks]

I opened your example before I left work, but didn't have time to tinker with it.

 

I'm at home now so I can't test it out, but if you look at the Config methods you will see both "get" and "set" methods that should make is simple to retrieve the SuperSecret variable without extra file I/O.

 

Note that there are two types of "sets" and "gets", "App" settings and "regular". Maybe selecting the App version methods would allow you to run this from the Tools menu.

[Darin]

From my vague recollection, I think you can use the Config.Get Target App's Settings (or Set) to do what you want.  However, I think it requires the line exist in the ini file before it can change it.  I do not think it will add it.

[Sparkette]

I always just keep them enabled. I don't have to worry about accidentally using one without realizing it's private, as the nodes will turn brown.

[Rolf Kalbermatter]

I always just keep them enabled. I don't have to worry about accidentally using one without realizing it's private, as the nodes will turn brown.

 

While that is true, the property and method menus do get rather messy and unstructured when this is enabled so for normal development work I definitely prefer this option to be disabled. YMMV if all you do with LabVIEW is digging for rusty nails and other attic relicts.

[Phillip Brooks]

Every time I read "brown nodes" I think of this unicode character... 

 

Not that they are bad, they just shouldn't be there.

Edited September 8, 2014 by Phillip Brooks

[hooovahh]

I always just keep them enabled. I don't have to worry about accidentally using one without realizing it's private, as the nodes will turn brown.

They also enable some extra event types in an event structure, that you may use but not know it was private.  

[Bob Schor]

I noted with great interest Phillip Brook's "Brown Invoke Node" to manipulate LabVIEW's .ini file.  I've written some code to do this for me (I use it to clean up the "Getting Started With" list of Projects and VIs), but wouldn't mind learning how to do it this way.  But I can't find the "brown node" -- any hints?

 

Bob Schor

Never mind, I figured it out, in private ...

 

BS

[hooovahh]

Yup Brown is private, Blue is scripting, Pink is deprecated.