Jump to content

Open GDS copy byref object at runtime

Recommended Posts


Does anybody know the best way to make a copy of a byref object (open gds v4) at runtime and pass all the attributes values (including inherited attributes) to the new object?

Thank you!


Link to post

I would create a Clone method in the class.



If you inherit any classes you need to also use the: "Call Parent Method", so the parent classes attribute will be clones as well.

  • Thanks 1
Link to post

Copy cannot be auto-generated because your object might contain references and the copy routine has to decide whether to share or clone the references. Mikael’s answer is best. Obviously if the parent class doesn’t have a Clone method, then you cannot add one to the child. 

  • Thanks 1
Link to post

Thanks MikaelH and Aristos for your answers,

I was rather hoping there would be an easier way around this hence my rather open question, but I can see there are too many caveats for it to be a simple answer. My specific problem involved objects containing other objects as Aristos mentioned (I have a composition). However for this specific case I always want to clone the references. The composition is also built exclusively of items with a shared ancestor. So to do it I have taken the method that MikaelH mentioned, included "call parent method", and replaced the "child" references (i.e. the references in the object's attributes) with copies (recursively to ensure all "descendant" references are copies too).  Thankfully this does the job 🙂

Here is the top level "DeepCopy.vi":


And the modified MikaelH's method "CopyAttributes.vi" (This method is cloned to all the classes inheriting from TestProfileItem):


Many thanks to both of you for your help on this.

Edited by Brains
Link to post

Someday, I really would like to take two months off of my main dev job to sit down with the developers of some app that uses all this ref stuff and really tear it apart. I've gone through smaller apps and been able to eliminate most of the references, achieving much better performance -- often with a significant decrease in memory and usually fixing a couple of race conditions along the way! But that's only for small apps, which leaves my theory that the big apps would be better off without the ref aspects as just that: a theory. I don't just need my time... I'd also need the time of the large app's developer(s) to provide the handholding to do the analysis. The work I did with Allen Smith on the AF was this weird moment of downtime for me at NI between two major projects, something that doesn't come around often. 

Until that next magical gap in my schedule, I'm just going to look at diagrams like the ones above and wince, whispering quietly, "We gotta find a better way..."

  • Like 1
Link to post

😄 Thanks Aristos. I find myself in a continual struggle between the light and dark side. I am part of a very small team and one of the main barriers to sticking with byval for us is that the tools for goop based development all seem to prefer byref. While they help to speed up the development process there are always times when a trivial subject for byval such as the above copying process, in byref becomes a complete nightmare. However, for now, the benefits are outweighing the costs.


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By cyro2015
      I tried to create a template based on OOP for QMH. During development I have been confronted with infinite crashes of LabVIEW so I decided to slow down with this project and open it to the community. I finished my working example and stopped for now.
      So if anyone is interested to play around with the code, see attached ZIP file (LV 2020).
    • By Marko Hakkarainen
      I had some time to learn about new interfaces and finally I could implement my collection class as I had envisioned. I didn’t want to use iterable and iterator names, because I thought that would have been too bold a claim.
      The original version of the collection class was (and is) used as a collection of sequence steps. Each element can be either a sequence command (send message, wait timer, wait complete etc.) or another collection of commands (sub-sequence). That’s the reasons for the labels and search method. Otherwise it is just a fancy (Rube Goldberg) array.
      Next method is recursive and it steps through all elements in the collection. Execute is only method, which requires override.
      For now, it’s at least an exercise in new interfaces. I don’t know if it’s useful enough to be in the code repository, but I can polish it up if needed.
      Marko H
      Certified LabVIEW Architect
      Iterable Collection LV2020.zip
    • By Zyl
      Hi everybody,
      I'm running into something I don't really understand. Maybe you can help me here !
      I've got a LVLIB that is used as an 'Interface': it exposes public VIs which wrap around public functions of a private class (see code attached) . The class is private because I want to force the users to use the 'interface' functions.
      In one of my interface VI, I create a DVR on the private class (Interface_init). The DVR is stored into a typedef (FClass_DVR.ctl) and this typedef is the 'reference' that link all the interface public functions.
      In TestCode.vi (which is not part of the lvlib and illustrates the standard code that a user can create to use my driver), I can call my public interface functions and link them without any problem.

      But as soon as I create an indicator on that reference (to create a state-machine-context-cluster for example), my TestCode VI breaks !

      The error returned is : This VI cannot use the LabVIEW class control because of library access scope. The LabVIEW class is a private library item and can only be accessed from inside the same library or libraries contained in that library.
      I understand that the class is private. But the DVR is contained into a public control. Using an In Place structure on that DVR into TestCode would not work, since the class is private. So why is the DVR control problematic at that point ? Creating it do not breaks any access protection...
      Am I missing something ?
      DVR Private POC.zip
    • By GregFreeman
      I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.
      Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.
      For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.
      I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
    • By StefanLemmens
      When I create new property node methods for a GOOP400 class using the OpenGDS they look like this :
      The Write method gets the reference to the data and then modifies it in place.The read method gets a complete copy of the data and unbundles the wanted element. When the object contains a lot of other (large) elements I would like to avoid copying the entire data to unbundle just 1 element. This means also getting a DVR to the object and unbundle the element inside an in place element structure, as shown here :

      In LabVIEW 2017 and above I could even use "Allow parallel read-only access." to make sure it's read-only.
      Currently I modify such read methods manually each time I create a new one. I know I could update the template but I was wondering if there is any good reason not to do this. Or what is the reason why the original OpenGDS is reading by copying the entire cluster?
  • Create New...

Important Information

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