jgcode

No as that will be application specific - so you want to pass that in as an argument. 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). Not sure what you are referring to here - can you go into detail? Thx. Glad you like it too! 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.

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>

Sorry I missed that post above. As per my post I hadn't got to performance testing then, but I am doing some now as I have both VIs - the time difference is quite surprising - and I wonder if this would be optimized in the future? And what the answer to your question is regarding the effect of inlining. One thing I did notice is the coercion when there is no connecting output, which disappears when its thralled. Well that depends who's code you read But yes, they should include the output given the results of the benchmarking

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

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).

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

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

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...

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!

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.

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

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?

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?

Glad you like it 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.

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

I wouldn't worry - I frequently embarrass myself. You just get used to it after a while...

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.

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!

Howdy Attached is a tool that automates the creation of a Child Class in the LabVIEW Project Environment. This is my first foray into LabVIEW Project Integration, and was a good example as it is a simple one. There are no example VIs in package yet, but here is a video: <!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="470" height="625" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/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/2d60299d-20fc-47df-ae5d-da3987577dc2/FirstFrame.jpg&containerwidth=470&containerheight=625&content=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/LVOOP%20Assistant%20-%20Create%20Child%20Class.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/2d60299d-20fc-47df-ae5d-da3987577dc2/" /> Unable to display content. Adobe Flash is required.</object> For things like this - Project Integration has a more natural workflow than '>>Tools' The package is LAVA namespaced as I plan to release this on LVTN and also to release more LVOOP helper tools. Feedback welcomed! lava_rsc_create_child_class-1.0.0.14.vip

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