23 replies to this topic

[Ton Plomp]

I am thinking about placing a Code Capture Tool section in the LabVIEW preferences dialog.

Looking at the %LabVIEW%\resource\dialog\PreferencesDialog\PreferencePages folder I see a pageTemplate.vit template.
I have created a new VI (prefPage_CCT.vi) and was hoping that a section would show up in the options dialog.
Unfortunatly this doesn't work.
Has anyone done this?

Ton

[Daklu]

Has anyone done this?

No, but if you figure it out be sure to post a How To. That would be very cool!

[Antoine Châlons]

I am thinking about placing a Code Capture Tool section in the LabVIEW preferences dialog.

This is a great idea!
If someone could knock the right door at NI maybe we'd get some info :-o

[crelf]

I tried to once a few years ago, but was told that it's locked. That said, I wasn't trying to add anything to the LabVIEW preferences, I wanted to use the API in my own application (why re-invent the wheel?), but I ended up making my own with a LVOOP plug-in architecture. Maybe you'll have better luck since you're working with the LabVIEW preferences? Talk to Jeff Meisel at NI - he's the guy who's leading the charge for third-party add-on development.

[smenjoulet]

I am thinking about placing a Code Capture Tool section in the LabVIEW preferences dialog.

Looking at the %LabVIEW%\resource\dialog\PreferencesDialog\PreferencePages folder I see a pageTemplate.vit template.
I have created a new VI (prefPage_CCT.vi) and was hoping that a section would show up in the options dialog.
Unfortunatly this doesn't work.
Has anyone done this?

See below, but first a couple caveats.
1) Proceed at your own risk! (okay, it's not really all that risky)
2) May the LabVIEW gods forgive me for stirring up and digging through the bones. Please don't smite me!

Talk to Jeff Meisel at NI - he's the guy who's leading the charge for third-party add-on development.

I agree that talking to Jeff would be the better, official way to go, but... for those who like to play around, I offer the following:

After digging around the VIs in the PreferencesDialog folder, you can see the inputs to the Preferences Dialog VI:

You'll notice the inputs to the VI, which presumably are passed from the LabVIEW IDE when the dialog is launched.
Three of them seem to be of particular interest: props, page VIs paths, & initial page VI.
The two path inputs are pretty self explanatory, but props is an unknown. If you create a constant from it, it is identified as a TagSet/PropertyBag refnum, so presumably it is some type of property collection.
As these inputs come from the IDE, it doesn't seem possible to add our own page into the list, until you stumble across this VI:

It has those same three inputs. Hmmm... We can't edit this VI, but we could rename it and substitute our own in its place. Yea, I know, that's a little sneaky

So making several assumptions we can try the following steps:
1) Rename optionsFrame_GetPageTitles.vi to something else
2) Create a new VI and call it optionsFrame_GetPageTitles.vi
3) Call the original version from your new custom version
4) Create all the Controls/Indicators from the original, use the same connector pane, and wire them up
5) Create your new property page from the template.
6) Through whatever mechanism you choose, insert the path to your new page into the page VIs Paths input

Save & close the VIs. Open the prefs dialog. Ha! Failure. You get an error saying the page VIs Paths array and the props array are not of equal size.
Well, what to do now? Not knowing what goes into props and a loss for anything else, I added the following step:

7) Index off an element of props (I used 0) and add it to the end.

Save and Close. Open prefs dialog. Success it would appear! My page now shows up in the list.

This is all the farther I investigated. I didn't try to make any custom page, I just used the template as is. I didn't try and see if I could get any settings saved and have them loaded back in. In fact, I get an error when closing the dialog. So I don't know if you can get the framework to take care of saving/loading settings for you without digging further into it. You might need to manage the load/save yourself. But at least you can have your custom settings page accessible from the built-in preferences dialog.

Good luck and let us know if you find out anything more.

-Scott

[François Normandin]

Great digging Scott!

Not knowing what goes into props and a loss for anything else, I added the following step:

Using Scripting Workbench, I noticed the TagSet class possesses very few methods: Set & Get Tag; and no properties.
Aything could be stored in those variant tags, but most likely nothing necessary for our own customized Preference Pages anyway.
Based on your description, I got to put my own page there in minutes. Thanks for clearing the way.

[Ton Plomp]

Good work, but the problem is that this only works on the computer that is used for the development.
It's not working on a ' fresh' computer like it would be very cool to be used.

Ton

[Christian_L]

I picked up this discussion on a thread over at NI Community and wanted to provide some input.

Reusing the LabVIEW options (preferences) dialog framework to create your own custom dialog for your application, along the lines of crelf's use case, is fairly simple and I will post a couple of VIs and an example in a day or two that provide a wrapper around PreferencesDialog.vi and a slightly updated template to build your own options pages.

Note: I prefer the term options to preferences so in general I will use that name.

Adding you own pages into the LabVIEW options dialog alongside the existing options pages is a bit more involved as stated in this thread. If you add your own pages and want to load/save your settings (which obviously you do) you need to explicitly add code in your options page VIs to do this. The framework will not handle that for you. The framework uses the TagSet/PropertyBag refnum for this purpose, but you will not be able to piggyback on this, at least not now.

We are discussing ways to allow LV add-on developers to add their own entries in the LabVIEW options dialog in the future, so stay tuned.

[crelf]

Reusing the LabVIEW options (preferences) dialog framework to create your own custom dialog for your application, along the lines of crelf's use case, is fairly simple and I will post a couple of VIs and an example in a day or two that provide a wrapper around PreferencesDialog.vi and a slightly updated template to build your own options pages.

Excellent - I look forward to seeing what you come up with

[Christian_L]

Excellent - I look forward to seeing what you come up with

Here it is: http://decibel.ni.co.../docs/DOC-13146

[jgcode]

Currently the options dialog framework VI is password protected while we refactor the code to make it user accessible. Stay tuned for an update of this reference example that includes the open source options dialog.

This is some cool stuff, and I look forward to the above.
However, I am wondering how it is going to be distributed so we could use it in an application?

All the called code sits under Resources\Dialog which is not a symbolic path in LabVIEW.
This means that when you move your source code around all the linking will break (had the same issue with the Icon Editor API for LV2009) - I even had to relink the example.

I guess you could namespace and re-install all the existing Resources\Dialog libraries/code into <user.lib>/<vi.lib>?

[MikaelH]

So you want to do this:



...just take your preference file you created and rename/replace it with "prefPage_Colors.vi".
I never modifies the colors anyway.

[Christian_L]

This is some cool stuff, and I look forward to the above.
However, I am wondering how it is going to be distributed so we could use it in an application?

All the called code sits under Resources\Dialog which is not a symbolic path in LabVIEW.
This means that when you move your source code around all the linking will break (had the same issue with the Icon Editor API for LV2009) - I even had to relink the example.

I guess you could namespace and re-install all the existing Resources\Dialog libraries/code into <user.lib>/<vi.lib>?

I'm glad you brought up this concern so that we will consider it. I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

[jgcode]

I'm glad you brought up this concern so that we will consider it. I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

Sweet, that will be a great release.
Playing with your example now.
Kudos!

[crelf]

...just take your preference file you created and rename/replace it with "prefPage_Colors.vi".

Oh Mike - that is just too funny My first LLOL of the day!

I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

I think that's a great idea, aalthough I'd like to see it distibuted as a VIPM package so I can control my project-based configuration management.

[jgcode]

I think that's a great idea, aalthough I'd like to see it distibuted as a VIPM package so I can control my project-based configuration management.

I was in the process of repacking the above to play with, but could not get past the cross-linking issues.
I too would like a package deliverable of the final product (but if not I am happy to do it myself).

[Christian_L]

I was in the process of repacking the above to play with, but could not get past the cross-linking issues.
I too would like a package deliverable of the final product (but if not I am happy to do it myself).

For the final package there will definitely be a VI package. I was holding off until I get the additional things done. Consider the current version a prelease or beta and please send me your feedback/suggestions.

I'm also looking for feedback and recommendations on a 'standard' method to store option/setting values in a running application as well as how to store them to file. How do you implement option values in your applications today?

- Globals
- FGVs
- Super cluster in a shift register

- INI file
- XML file
- ???

My plan is to integrate this design with the options page template code to automate the load/save process in the options page as well as load/save to persistent storage (file) as much as possible.

[Yair]

Regardless of which method you choose to store the data in the app (class, globals, cluster), persisting the data is fairly easy:

• With a class you can simply flatten it to disk.
• With globals you can use the Controls[] property for the global VI and then iterate over them and save them using something like this:
  
• With a cluster you can use the OpenG or MGI VIs to save and load it.

[Aristos Queue]

I'm glad you brought up this concern so that we will consider it. I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

No reason to rename the VIs. AppBuilder uses lots of things out of VI.lib. So does the Getting Started Window. If it really is something that both LV and customers use, put it in vi.lib and let LV use that copy. It means that any bug fixes we find for Tools >> Options also get fixed for users of the dialog.

[jgcode]

No reason to rename the VIs. AppBuilder uses lots of things out of VI.lib. So does the Getting Started Window. If it really is something that both LV and customers use, put it in vi.lib and let LV use that copy. It means that any bug fixes we find for Tools >> Options also get fixed for users of the dialog.

That is ok for future versions, but if we want it now (and us developers are a greedy, arrogant, demanding bunch) then it will have to get moved and renamed for LV2009 and LV2010 (if e.g. it was changed for LV2011) - unless you are saying that installing it to <vi.lib> not renamed, alongside the current files in LV2009, will not cause cross linking issue with other LabVIEW components?

Otherwise why not just make the Resource folder (and possibly others) a symbolic path?
Is this a good Idea - or are there reasons not to do this?