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

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

Here is my 2 cents:

Firstly thanks, James these Vis are really cool - and I really dig the icons you did

I have reviewed and attached the set of VIs and created Tests for all of them

Open the project and run Main - this is kinda how it will plug into the current OpenG Test Framework

I've included the help and BD as images so peeps can comment without downloading if preferred

In general:

• Normally OpenG functions are not set to be re-enterent unless there is a specific need therefore, I have turned this setting off as it makes it easy for end users to debug plus there are associated memory costs with launching clones
  
• I don't think any of these VIs should output an error - it should be handled internally
  
• Documentation updated
  

Additionally I have converted the VIs to OpenG style standards including:

• Removed terminals as icons
  
• Default 2009 panel color
  
• License (added a place holder - just ignore for now)
  

Please comment or post on the attached VIs not on 2011 ones.

Get Default Object

• I think we should leave in the disabled solution for knowledge and for a possible future review - I like that
  

Default Value

• I don't see the need to pass the Object back out. I would assume this may help memory allocation but not 100% sure (can anyone comment). Regardless other comparison functions (both OpenG and LabVIEW) don't do this
  

Is Same Or Descendant Class

• Change name to include Is prefix as per other comparison functions
  
• Again - I don't see the reason to pass out the Objects
  
• As we know about one Object but we are testing for the a possible descendant (as per name of output and VI) I think the relative names should be changed around (use Descendant instead of Ancestor) - this matches the output
  
• I changed the icon and placed the ? near the object that is being tested/checked to match the above point
  

Return Class Name

• I don't see the benefit of having two VIs (originally Class Display Name and Qualified Class Name) and maintaining two similar pieces of code - so I merged the two
  
• I also changed the name to describe what the VI is doing (e.g. return or maybe resolve etc...)
  
• I removed the subVI call to the Get Default Object - it just wraps a prim so it's not a reuse issue (and it's not inlined so I assume this would remove overhead)
  
• I have added a summary of AQ's post into the VI documentation as well as a line of text from him regarding use as he provided the original code -
  

LVOOP Data 2009.zip

Hello Everyone,

I am a small-time application builder on Labview, I have tried to find answers to the following two questions a lot on the NI site but could not get any definite yes or no answer

So here are the questions

1) I know that DSC module requires run-time license on the end-users computer, my question is, that if I use the datasocket binding on the controls/indicators property box and assign a couple of OPC tags (like 20-30 max) and not use the shared variable engine, do I still have to get a dsc runtime license, or is there anything like OPC tag-based license for the end-users PC?

2) Does database connectivity toolset and report generation toolkit also require runtime license on end-user PC's?

This KB article is a good overview of what you require for DSC based on the functionality your application will use.

As for DBCT and RGT - you should only need the standard LabVIEW run-time (no license).

“Only Used Internal to LabVIEW (oh, and, shhh… LV objects)”

No its not like that at all - its about the reliability of that result (more so in the future) as the int16[] is deprecated.

-> Use at your own risk

What version are your changes in?

Uploading them here would be a great start.

Hi Guys

I have implemented some feedback

Version 1.1.0:

- (there are no Icon Layers so the tool) Attempts to copy the Parent Icon theme to the Child (currently the Library banner created is 12x32 which is the default LabVIEW banner size). I'll work on this, for all those skinner banner users

- Opens the Class Properties dialog (thanks Mike!)

<!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="800" height="600" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/171e6cc3-3ccc-4e70-a526-21d66f339b36/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/171e6cc3-3ccc-4e70-a526-21d66f339b36/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/171e6cc3-3ccc-4e70-a526-21d66f339b36/FirstFrame.jpg&containerwidth=1005&containerheight=768&content=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/171e6cc3-3ccc-4e70-a526-21d66f339b36/LVOOP%20Assistant%20-%20Create%20Child%20Class%201.1.0.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/171e6cc3-3ccc-4e70-a526-21d66f339b36/" /> Unable to display content. Adobe Flash is required.</object>

Cheers

-JG

lava_rsc_create_child_class-1.1.0.15.vip

but unfortunately Class Refnums don't work on RunTime so one can’t put anything built on it in an exe.

(I wouldn't recommend doing it of course) but that's not 100% true - I have gotten some stuff to work.

Putting these VIs in LabVIEW Data would be fine, though that library is quite large already. It might be better to have a new “LVOOP” library, especially if there is a chance of adding more tools in future, such as the Class manipulation tools jgcode linked to.

I (personally) think the Class Library Refnum API should be separate - to the VIs you have provided that work on Object Data.

However, yes the OpenG LabVIEW Data Library is quite full...

Are you distributing source code or executables?

From what I understand of the OP, they are distributing an application as a bunch of VIs.

If that is the case I recommended building an exe using the LabVIEW Builder (assuming you have a llicense for it), and read back that versioning for your About screen. That way no one can edit your code. Also the code could check a central DB for the latest version and notify the user etc...

If are distributing code then VIPM would be the best - and the community version is free!

Small question: If I feed a LVOOP object (which is a “Refnum” type) into “Get Refnum Type Enum From Data”, it comes out as “Only Used Internal to LabVIEW”. Should this not be “LV object”?

All I can say, at this point in time is, that a lot of the info for those VIs was kindly donated, and that was a specific request that came with it.

Is there any documentation for writing Project Window Providers or is it a question of reverse engineering... ?

Hi Gavin

You have to be part of the Project Providers group.

I would contact them if you are interested.

Ok, this is now an official OpenG Review.

And therefore, I have moved this thread to OpenG Developers.

I have resaved the VIs in 2009 as the OP couldn't.

Please add comments regarding any of the VIs to this thread.

Upload any mods, tweaks, etc...

OpenG LVOOP Suggestions Folder 2009.zip

 Additionally please comment on where these VIs would go in the OpenG Library:LabVIEW has a [b]Cluster, Class & Variant[/b] palette therefore, the [b]LabVIEW Data Library [/b]package [i]could[/i] be used to house these VIs - as it is where OpenG Variant VIs are (as well as an old GOOP VI).

Or we could create a new LVOOP Package - although I've always had in the back of my mind, that an OpenG Class package would look similar to this

...because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.

Using a web-server in the past has fixed my XSS issues (among other things).

I am interested to try out the switch you have posted i.e. does it allow cookies to work in chrome?

1) Automatically open the Properties window of the new child (as that’s always the next step)

Not sure if I can do this, I have a feeling I have tried to before as well with no luck.

Mike might know if this is possible in 2011?

Thanks you for this.

Glad you like it

I'm pretty sure you can hook into the New... menu and can control where in the project item is added. Is there a reason you didn't add the item to the New... menu? That's where I would expect to find it.

(I know that everything in the New... menu is added to the project item that is selected and this would be different. But that's still where I would expect to find this.)

Mike, thanks for the feedback.

It makes sense that New... is more intuitive.

However, my reason is that I intend is to keep adding tools under LVOOP Assistant menu item - so when a user installs a tool they know where to look etc...

I can always change it tho.

Jonathan Green

It's Jonathon actually

Great post by Ton - there are heaps of ways to contribute to OpenG.

Please PM me if you want to discuss further.

Cheers!

-JG

Getting old, I posted in that thread but didn't remember it.

Where is the smiley with grey beard?

I wouldn't worry - I frequently embarrass myself.

You just get used to it after a while...

Works now. Great work! I must have a hundred times though “Why can’t I just right-click a child class?"

Suggestions off the top off my head (no idea how hard any of it is to do):

1) Automatically open the Properties window of the new child (as that’s always the next step).

2) On the popup that asks for the child’s name, have checkbox options for:

— copy parent class icon to child

— copy parent private data control icon to child

Usually the child needs icons that are modifications of the parents icons, so this would save a lot of cut-and-paste.

— James

Thanks for testing.

Great feedback, I will see what I can do.

I can definitely look at modifying icons, but would prefer using layers - unfortunately the Icon Editor API is not supported in 2011 as it was broken by the addition of PPL's and there is no plans to release it any time soon (I have been asking since beta but it is unsupported). I really like layers as it makes it easier to edit icons in the future.

2011 also includes some new scripting features and fixes so I am looking forward to releasing a few more LVOOP tools.

My plan is to break down some of the 2009 LVOOP Assistant features and get them working with Project Integration, which is more usable and will be faster to execute and easier to extend than just having one bulky tool.

I successfully installed it with VI Package Manager (no error), but I can’t find it, either right-clicking or under Tools>>LAVA.

Looking for the files, I seem to be missing a \resource\Framework\Providers\CreateChildClass directory. Other files seem to have installed.

Thanks heaps for the feedback.

Its the first time I have used build hooks in anger with VIPM and there was a path that should have been relative but wasn't. It should have installed correctly on a 32-bit LabVIEW install on a x64 OS (which was the only machine I had to test it).

Do you mind trying again - I upload a new version in the OP.

Cheers!

Curious; just noticed a private method App.CreateGUID. (LV8.6)

Is this present on Mac as well?

(I haven't tried it but) - Shaun posted it here commenting that it can't be included in a build.

See here for original thread.

This tool has been packaged up on the LAVA-CR

I will look at adding it to the LVTN in the near future.

Name: LVOOP Property Popper

Submitter: jgcode

Submitted: 17 Jan 2012

File Updated: 17 Jan 2012

Category: LabVIEW Tools Network

LabVIEW Version: 2011

License Type: BSD (Most common)

Copyright © 2012 Norman J. Kirchner, Jr.; 2007-2012 JGCODE

~,~ - The Captain was here...

This package is Open Source

LVOOP Property Popper is a tool that aids in debugging Class Property Nodes.

Instructions:

* Open the LVOOP Property Popper UI

* Select a Class Property Node

* Press 'Get Properties'

* Double-click a property in the listbox to open that properties Block Diagram

Restart LabVIEW to refresh Menus after installation

Tools Menu:

Plugins can be found under Tools>>LAVA>>LVOOP Property Popper

'Run' - opens the LVOOP Property Popper UI

'Open Example' - demonstrates features of this tool

Installation Locations (relative to LabVIEW directory):

'\vi.lib\addons\_LAVA\lvoop_property_popper' - main code

'\project\LAVA\lvoop_property_popper' - tools menu plugin code

'\examples\LAVA\lvoop_property_popper' - example code

Click here to download this file