Jump to content

Add a preferences category


Recommended Posts

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

Link to comment

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.

Link to comment

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.

Link to comment
  • 2 months later...

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.

  • Like 2
Link to comment
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 :thumbup1:

Link to comment
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>?

Link to comment

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!

Link to comment
...just take your preference file you created and rename/replace it with "prefPage_Colors.vi". ;)

Oh Mike - that is just too funny :D 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.

Link to comment
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).

Link to comment

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.

Link to comment

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

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

Link to comment

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.
Link to comment

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?

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

My version of the preferences dialog uses the OpenG panel to disk VIs, and they work great. I'll try to post an example tomorrow, if someone reminds me with a PM...

Link to comment

Is this a good Idea - or are there reasons not to do this?

Making it a symbolic path would encourage you users to link against it. If you thought we were cavalier about changing VIs in vi.lib that aren't in the palettes, that's nothing compared to what we feel free to do to the Resources directory. ;-)
Link to comment

Making it a symbolic path would encourage you users to link against it. If you thought we were cavalier about changing VIs in vi.lib that aren't in the palettes, that's nothing compared to what we feel free to do to the Resources directory. ;-)

lol

Link to comment

I posted a new version of the code on NI Community including a VI package.

Changes in the code:

  • Reverted version number from 1.0 to 0.2
  • Added VI package distribution
  • Moved all dialog subVIs from LV resource folder into package
  • Added support to show/hide Help button and specify dialog help file
  • Moved API and framework into LV project library
  • VIs install to ..\user.lib\ODF
  • Added subpalette to User Libraries in Function Palette

http://decibel.ni.co.../docs/DOC-13146

  • Like 1
Link to comment
  • 3 years later...
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.

Excellent Work! But I can't replace some text prompt or labels on the dialog for localization. At present, we can only custom the "OK" button label.

 

Here it is:

 post-27036-0-51366700-1378087491_thumb.j

 

Below lies the NI option dialog in Chinese.

post-27036-0-86027600-1378087505_thumb.j

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.