Jump to content

jgcode

LabVIEW Tools Network
  • Posts

    2,397
  • Joined

  • Last visited

  • Days Won

    66

Posts posted by jgcode

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

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

  3. 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+?

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

    • Like 1
  5. 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)

     

    post-10325-0-94522000-1391907039_thumb.p

     

    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) 

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

  7. Hi Lewis

    Is it possible to run the preferences popup in a sub panel instead? My guess is that you can't because it is called within "the engine" ?

    Yes, that is how the framework essentially works

    You could call the Preference Pages in your own subpanel (they are just VIs) - but you would have to handle the synchronization built into the Engine/Page VIs tho

    Why can’t you view the block diagram for appVars.vi?

    AppVars is a Global Variable, a Global Variable does not have a block diagram

    I don't understand what all of the global variables are for? Where do you write to them and what is the need for them? For example, in the readFromDisk.vi, we specify the sections we would like to read

    The Global Variables are used for Application Variables in the example only - you can change this to whatever you like. However, I prefer Globals over constants for this use case so I can edit them all in one location when developing e.g. AppVars.vi)

×
×
  • Create New...

Important Information

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