51 replies to this topic

[jgcode]

Name: JGCODE Preferences Dialog Library
Submitter: jgcode
Submitted: 30 Jan 2012
File Updated: 11 Feb 2012
Category: LabVIEW Tools Network Certified
LabVIEW Version: 2009
License Type: BSD (Most common)

This package is Open Source
The Library contains supporting VIs that integrate with the LabVIEW Preferences Dialog to simplify file IO using OpenG VIs.

Thanks to Yair/tst for help with refactoring

Installation locations:
<templates>\JGCODE\Preferences Page Dialog.vit - template for creating new pages
<examples>\JGCODE\preferences_dialog - example application and instructions

The following VIs are called dynamically so that linking is maintained:

<resource>\dialog\PreferencesDialog\PreferenceDialog.vi
<resource>\dialog\PreferencesDialog\optionsFrame_GetErrorReportQueue.vi
<resource>\dialog\PreferencesDialog\optionsFrame_GetPageReadyNotifier.vi
<resource>\dialog\PreferencesDialog\PreferencePages\SharedPrefPage_SubVIs\SetCursorBusy.vi
<resource>\dialog\PreferencesDialog\PreferencePages\SharedPrefPage_SubVIs\SetCursorNormal.vi
<resource>\dialog\PreferencesDialog\PreferencePages\SharedPrefPage_SubVIs\SetOkDisable.vi
<resource>\dialog\PreferencesDialog\PreferencePages\SharedPrefPage_SubVIs\SetOkEnable.vi
<resource>\dialog\PreferencesDialog\PreferencePages\SharedPrefPage_SubVIs\SetPanelCloseStateDisable.vi
<resource>\dialog\PreferencesDialog\PreferencePages\SharedPrefPage_SubVIs\SetPanelCloseStateEnable.vi

This Package depends on these other packages:
oglib_appcontrol >= 4.1.0.7
oglib_array >= 4.1.0.13
oglib_file >= 4.0.0.20
oglib_variantconfig >= 4.0.0.5

Click here to download this file

[Yair]

In the first video you mention that the framework code is duplicated in every VI because of problems with dynamically registering events in subVIs. Can you go into any more detail on that? Maybe it's something which can be resolved.

[jgcode]

In the first video you mention that the framework code is duplicated in every VI because of problems with dynamically registering events in subVIs. Can you go into any more detail on that? Maybe it's something which can be resolved.

Yer that would be nice.

Supporting the Pane: Pane Size and the Panel Close? events with dynamic registration (as would be the case if it was made into a re-entrant, reusable engine) means the FP needs to be in memory however, there is no (well, not that I know of as it's all locked) feedback as to the state of the FP as it is inserted and removed from the subpanel.
If there was then you could un/register for those events correctly.

The Panel Close probably doesn't matter - it was in <resource> template so I included it - because of the OpenG VIs, there is no real great need to test each Page as it is the same code.
The Pane: Pane Size is handy to show or hide the scrollbars - so this is required.
When it is statically registered I the above concerns can be ignored.

It would be much nicer code if it was refactored into an engine - which is what I was hoping for.

The two workarounds off the top of my head are:

• A simple event loop on the Page listening for the Pane Resize and passing it to the engine - but that would require 2 way comms (msg + to shutdown loop)
  
• Possibly polling could work - but is not that great sounding

Hopefully there is a fix someone can suggest

[Yair]

If the framework only runs the page VIs when they are put into the SP (and I'm assuming that's the case), then maybe you can try a trick - I'm assuming the Page Ready Notifier you send at the end of the Setup state tells the framework that you're done and you're ready to put the VI into the SP. What if before you do that, you open the FP (maybe hidden), then register the event, then close the FP again and only then send the notification?

[jgcode]

If the framework only runs the page VIs when they are put into the SP (and I'm assuming that's the case), then maybe you can try a trick - I'm assuming the Page Ready Notifier you send at the end of the Setup state tells the framework that you're done and you're ready to put the VI into the SP. What if before you do that, you open the FP (maybe hidden), then register the event, then close the FP again and only then send the notification?

The only reason I didn't try that is I assumed that taking the FP out of memory would invalidate those events?
I will give it a go.

Here is the Dual Loop approach - it works.
All the meat is in the engine, the stuff on the Page is pretty basic (in comparison).




<edit>

Sweet!!

It works - great suggestion
The code now looks how I originally intended - reusable!



</edit>

[Yair]

The This VI reference is probably also redundant - you can get it inside the subVI.

[ShaunR]

The This VI reference is probably also redundant - you can get it inside the subVI.

Ditto with the get config file.
This is sweet. Huge improvement on the original. Nice work.
One question. Does it need the openG tools intalled on the users machine? (i.e what about distribution of the developers toolkit that these settings apply too)

Edited by ShaunR, 29 January 2012 - 03:12 PM.

[neil]

Awesome!

Thanks Jon. I took a look at the framework when it was first "released" in 2010(?), but there was too much to do to get it working nicely.

Aside: does any body else use the MGI read/write VIs instead of the OpenG ones? I switched to the MGI ones a few years ago (for some reason that eludes me right now).

[jgcode]

Ditto with the get config file

No as that will be application specific - so you want to pass that in as an argument.

.
One question. Does it need the openG tools intalled on the users machine?

Yes, as per the VIPM info screen in the OP there are some dependent packages.
I originally considered including the OpenG VIs in with the dist, I could still do this, but normally don't for APIs (as opposed to tools).

.
(i.e what about distribution of the developers toolkit that these settings apply too)

Not sure what you are referring to here - can you go into detail? Thx.

Awesome!

Thanks Jon. I took a look at the framework when it was first "released" in 2010(?), but there was too much to do to get it working nicely.

Glad you like it too!

Aside: does any body else use the MGI read/write VIs instead of the OpenG ones? I switched to the MGI ones a few years ago (for some reason that eludes me right now).

I went back and forth with these and OpenG and I pretty much used OpenG exclusively for last couple of years.
MGI is faster but they write as a string blob (looks like ini, but behaves different), OpenG is "slower" but they write as keys - I use quotes because for small data speed is not an issue at all.
If you have a clustersarous then yes, it will be slower.
The other thing is you are not streaming data to disk with these things, so the speed difference has never been an issue for me.

The biggest advantage for me is that you can add, leave, delete etc... data per key - MGI removes the entire blob.
One use case where this is advantageous is in supporting different versions of files, and having keys persist.
The other (which is important to me) is if you have a class and it persists its data to disk, you can create a Child class and write the additional data (parent + child) to the same section (assuming that data has different key names), with MGI you cannot, it will overrite the entire section.

[jgcode]

Ok looks awesome here is the new package with the above fixes.
Very simple to create and maintain a Page - just drop your control and indicators on the BD

The Page Template



The Page Engine (reuse subVI)



The new Package



 jgcode_lib_preferences_dialog-1.0.0.16.vip   241.99K   84 downloads

I have also exposed the Filter Names (optional) input so you can filter out controls/indicator that you may be using for screen effects etc...
This video (no sound) shows it in action (obviously you wouldn't not save a piece of data, but you get the point)

<!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="1275" height="733" type="application/x-shockwave-flash" data="http://content.scree...gswfplayer.swf" > <param name="movie" value="http://content.scree...gswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2973dfad-70cd-453a-8ad2-5e795d0ced7f/FirstFrame.jpg&containerwidth=1275&containerheight=733&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2973dfad-70cd-453a-8ad2-5e795d0ced7f/Preferences%20Dialog%203.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.scree...-5e795d0ced7f/" /> Unable to display content. Adobe Flash is required.</object>

[neil]

I went back and forth with these and OpenG and I pretty much used OpenG exclusively for last couple of years.
MGI is faster but they write as a string blob (looks like ini, but behaves different), OpenG is "slower" but they write as keys - I use quotes because for small data speed is not an issue at all.
If you have a clustersarous then yes, it will be slower.
The other thing is you are not streaming data to disk with these things, so the speed difference has never been an issue for me.

The biggest advantage for me is that you can add, leave, delete etc... data per key - MGI removes the entire blob.
One use case where this is advantageous is in supporting different versions of files, and having keys persist.
The other (which is important to me) is if you have a class and it persists its data to disk, you can create a Child class and write the additional data (parent + child) to the same section (assuming that data has different key names), with MGI you cannot, it will overrite the entire section.

Good points. I have had a few problems with the MGI libraries recently, some very subtle bugs and incompatibilities with .ini files created using the NI VIs. (Things like no space between the key-name and the "=" causing havok).

Time to try OpenG again I think...

[neil]

Jon, having a bit of trouble with the package.

I have tried a simple app, and when I run it my new preference page gets run as its own VI and not within a subpanel of the Preferences framework, as shown in pic.

It seems to run hidden as well (although sometimes seems to open). Actually once I have had the Preferences framework VI open, but then got error (1144?) saying cannot insert VI into subpanel as it is already open. I think this occurs after running my main VI when the preference page FP was open but not running.

Any ideas what I am doing wrong? The preference page is just opened from a template and then saved.

Attached Thumbnails

• 

[jgcode]

I have tried a simple app, and when I run it my new preference page gets run as its own VI and not within a subpanel of the Preferences framework, as shown in pic.

It seems to run hidden as well (although sometimes seems to open). Actually once I have had the Preferences framework VI open, but then got error (1144?) saying cannot insert VI into subpanel as it is already open. I think this occurs after running my main VI when the preference page FP was open but not running.

Any ideas what I am doing wrong? The preference page is just opened from a template and then saved.

Hi Neil

As the Framework inserts Pages into a subpanel you cannot have the Page FP in memory as this will cause as error
This is standard with using subpanels - so try closing the Page then running the Dialog VI and see if you still get issues.
Are you using the latest version of the package - 1.0.0.16?
I have that version working fine here and it also includes some niceties for running the page by itself for debugging.
Although that should be needed as all you have to do is drag and drop control onto the front panel now - yay! .
As for anything else, I am not sure - do you want to post your code, I am happy to have a go running it?

Cheers!

[ShaunR]

Yes, as per the VIPM info screen in the OP there are some dependent packages.

Thats a pity since I don't use VIPM or the tools:(

Not sure what you are referring to here - can you go into detail? Thx.

Nevermind. I think I got the wrong end of the stick. I thought it was adding a page to the LabVIEW preferences (from the LabVIEW toolbar).
Still sweet though.

[jgcode]

...I thought it was adding a page to the LabVIEW preferences (from the LabVIEW toolbar).

Sorry to disappoint you!
Yer, it's so you can easily build your own plugin, Preferences Dialog, leveraging the NI Framework.

[ShaunR]

Sorry to disappoint you!
Yer, it's so you can easily build your own plugin, Preferences Dialog, leveraging the NI Framework.

I didn't mean to belittle your efforts. It's great. Just not what I originally thought.

[jgcode]

Ok, the current version has been added to the LAVA repo
I rolled up the example into the package and added some documentation to help new users.







Enjoy!
-JG

[Yair]

One additional comment: I'm personally not a fan of providing the name of something in more than one place. If ignoring controls on the front panel is common (and I'm guessing it actually isn't very common), then I would prefer if the template included a for loop which iterates over every control reference given to it and extracts its Label.Text property to use as the filtering array.

Of course, since the default is to have no control, this code could be in a disable structure, or you could feed it one of the built-in controls, which I assume is meaningless, since it filters them anyway.

[ShaunR]

What I did with PassaMak was that the engine would exclude any controls where the caption wasn't visible (it too used the label as a tag). The user then just showed the label instead of the caption for that "ignored" control/indicator. But as Yair said, it isn't common and it doesn't really make any difference if you do add all controls since who expects a control on a preferences dialogue not to remember what you put in it?

[drjdpowell]

One could use a symbol in the label to indicate excluded controls, like “_Numeric”.

Edited by drjdpowell, 30 January 2012 - 03:58 PM.