jgcode

would be a much better way for others to contribute code to the project   

I am unsure if a new workflow would increase contribution but, what do others think?

I don't see the point of removing it as from an end user point of view, the BSD licence is so simple and non-restrictive

They probably spent more time editing it out

Will be interesting to hear the outcome of the nudging 

Okay so I did get a solution for my use case.  One of my new favorite private functions is the Save VI as Buffer.  It performs the same save operation that a VI normally does, but returns the stream of bytes that the file would be, had it been written to disk.  Luckily there is also a Save Library as Buffer.  

 

So using these functions I was able to get the VI and project buffers, then save them to disk using the write binary file.  The only modification I needed was to edit the library buffer stream, modifying the XML to include the relative path to the member.  Since the member hadn't been saved yet the path wasn't stored in the project buffer.  After that I needed to close some references, and it seems to work.

Nice. Are you able to post any example code?

Cheers

Nothing from me but I would still love a wrapper for this functionality from NI

Warning: I'm not a scripting veteran.  I know my way around vanilla Vi Server pretty well, but Scripting is still (kind of) new for me.

 

I am looking into the possibility of scripting a different kind of accessor for a "framework" (I use the term loosely) I am working on.

 

What I'm really not sure about is whether I should try to leverage the VIs present in the "\Framework\LVClassLibrary\" directory.  Most are password protected and I'm unsure as to whether the work will be easier wrangling the existing code to do what I want or just doing it from scratch....

 

I don't need IDE integration, just code which can be run when needed.

Hi Shoneill, are you able to provide details of are planning? This code is 2012, open source, and includes a modification of the library references above (creates a wrapper around a delegate class). 

I'm in, for me ol' DOS games 

 I'm looking at you accessor VIs (for the most part).

I changed my thinking on this a while ago too

Reads can be as simple as one in and one out: LVOOP Object input, accessor-data-item output

Just had code that worked in development but returned a 1502 build error (cannot Save A Bad Vi Without Its Block Diagram)

Hunted it down and turned out to be a privately-scoped VI in a polymorphic API 

Changed to public and all good 

I would say the most important thing is to give it a go and find out

As for me, I find it easy but more importantly fun to use!

Also, I like creating an API that uses the event structure to communicate with a process and this compliments it well 

Ok, so its not all AppRef functions that are effected, just the one in this post 

That's a relief 

Both, pal! But in LV13.0bxx era, I asked the same question, and the unofficially-reworded response was "yep; we [NI] changed this because previous to this change the AppRef was leaking; just keep it open til you've done what you need to do with the newly-created VIRef, then `Close Reference` on the AppRef and it'll work like it used to, just less-leaky".

I've used that guidance for 2yrs now with success; your independently-discovered `*Edit` is the correct way to use this method now.

Does this mean old code will be 'broken' in 2013+?

Wholly crap cakes.  Why not LabVIEW 3?. 

lol. 8.2.1 is/was one of my fav LabVIEWs

Howdy

I am chuffed to be giving away an AudibleListener® 6-Month Gold Gift Membership.

Sure beats reading

Hi Mikael, I include all library files in my VI Server script as well, but I am insure as to what that option actually does. It seems the global settings (LabVIEW options or project options) override when a VI/ctl is added to a library (LV2012) making me think it is redundant or a bug. Do you know setting the library to separate compiled code does?

And just to reiterate a point that some people often forget. The global compiled code option only applies for "New Files" so checking it won't change all the existing files to use this method. You have to go and change each VIs setting individually and recompile.

That sounds like too much hard work - lol

You can bulk mark VIs through the project's options or you can use VI Server and script it

I tried this feature out recently and liked developing with it

One thing I concluded with tho is that if I ship a tool (essentially a source code dist) I want to install compiled code with it

Otherwise the tool needs to be compiled for use in its native version of LabVIEW

VIPM can do this on install, or the tool can also recompile itself, but IMHO it makes for a better UX (quicker install and first launch)

This was easily achieved using VI Server

Hey Jon... you coming back to Labview or just stopping by for a visit?

On secondment? Lol

Yes, this is exactly what I am experiencing.  Creating the child class from within a LabVIEW project window works fine in LabVIEW 2013.  Creatind the child class from within a Class Project Window crashes LabVIEW 2013.

Glad to hear that 

jgcode, thanks for the info.  Unfortunately LabVIEW 2013 is crashing when I try to create a child class with you latest test build.

Hi Brian, thanks for the post

But one thing I noticed recently was that LabVIEW crashes if you run the Create Child Class plugin in a class Project Window (right) as opposed to a standard Project Window (left)

The reason is that LVOOP Assistant is trying to insert a class, and obviously cannot in the context of a class Project Window

I have since fixed this in source by disabling the feature in the above case

Additionally I have done the same for Clone Method (this was error'ing out as opposed to crashing)

Is this is what you are experiencing?

Otherwise do you have any more information on the crash (screen capture?) 

Unfortunately I do not have LabVIEW 2013 at the moment (hopefully soon) so bear with me if it is isolated to that version (hopefully not) 

Hi guys, thanks for your posts

I have added a test build compatible with 2012 here if you are interested

I have attached a test build that is compatible with 2012

It contains the LVOOP Theme Creator

lava_rsc_lvoop_assistant-12.0.0.79.vip

LabVIEW 2012

Mmmm.... meat

The reason you get this error is that you cannot register for FP events for controls on a VI that is not in memory... ...Event if you try to register for control events while the FP is in memory, the event registration goes invalid when the FP is closed.

There is a workaround for this

Yair helped me here with when I had the same problem

Not saying it would fix your problem, but worth looking at

Cheers

The only annoying part is that I tend to pass in my clustersaurus into it, which ruins the front panel.

Use a class?

Here is a link to a thread on this topic that you may like to read: http://lavag.org/topic/14759-can-i-override-private-data/