Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Yair

  1. I don't have experience with either of those options, but presumably the second option is an extension of the first, which I understand is designed to make sure that only the class can create DVRs of itself. This is presumably to ensure proper initialization of the objects in the DVR, since LV doesn't have constructors for that. I'm assuming the thinking for the second option is that if you want to create a by-ref object of type A, you can only do it in class A, even if the actual object is B, which inherits from A.

  2. I haven't looked into this (and I don't have actual experience with the import tool), but the VIs sit in vi.lib\Platform\WebService (I guess it's Windows only) and seem to be mostly unlocked. A quick look doesn't show any design for extension, but maybe you can play with it. It looks like much of the work is delegated to NI .NET classes, so I'm not sure if there is anything you can do if those classes don't support it.

  3.  I've had the impression that people wait for the SP1


    Some people wait for the SP releases. It's certainly less likely to have new bugs, as they rarely have new features, but .0 releases are not exactly hotbeds of crashes automatically. I know I used 7.0 for years and was perfectly happy with it. I suppose depends on how sensitive you are to perceived potential bugs, but I don't have any actual data about the stability of .0 and .1 releases. I actually generally try to avoid upgrading if possible, because it's a hassle and can make project management a pain.

  4. I have code (which I can't share) for batch processing VIs which call the function from a DLL and do a bunch of operations on each. I don't do the specific changes you want, but the concept is the same.


    Some relevant points:

    1. As Jack mentioned, this can be problematic, at least if you also have to start adding the code which you mention in the end of your original reply. I didn't, so this code can only be run after generating the wrappers.
    2. Keep in mind that you might want some VIs which don't get this treatment.
    3. To do the wrapping, you should create a disable structure, select everything on the diagram (my suggestion - exclude all ControlTerminals) and then call the EncloseSelection method on the VI's diagram (give the created structure as the EnclosureType) and delete the original structure. You can then probably use the properties to set the conditions.

  5. One good reason to separate is that recompiles still happen in released code (change platform/bitness/version etc.) and if you don't separate, LV will show your VIs as modified unless the installer resaved them after install (which VIPM is supposed to do if it's configured to, but didn't always work). There are also cases where VIs occasionally decide they need to recompile for no apparent reason (VIs which have ActiveX calls are particularly bad at this - they decide they have a different component from the one they had before).

    • Like 1

  6. Some potential options:

    1. Open a reference to the remote app and to the VI and insert that into a subpanel. I'm pretty sure this won't work, but it's certainly worth a try.
    2. Use remote front panels. Haven't done that in a very long time either.
    3. Use a copy of the VI and bind the controls and indicators to shared variables.
    4. Use the Windows API parenting functions mentioned here, like SetParent. They're fairly easy to use and there are even VIs which use them online (although you should note you can have one copy of the window at a time and there are potential weird artifacts which can happen).
    5. Implement a VNC server. I'm not sure how much work that is to implement. Maybe that's what the ancient LabVNC does.

  7. For the most part, I'm managing fine with Windows 10 (after setting a bunch of preferences I had which it decided to reset). Certain things about it are nice, like the window management. The two things which are still annoying me:

    1. You can't pin arbitrary items to the start menu. If you want it there, you have to copy it to the correct folder and it appears in the apps list, from which you can pin it.
    2. Windows Update decides on its own when it will install updates and restart your computer. If you ask it nicely, it will allow you to set when the time when it will restart on your own, but it *will* install and restart. Apparently this can be overridden with a group policy, which I have now set, so I will see if that works.

  8. You certainly shouldn't need XNodes for PID. As flarn says, just use a subVI. I would also say that unless your goal is learn about PID by implementing the algorithm, you should just use NI's PID VIs and focus your time on other things. I'm not sure what you need to get the PID VIs (I think in recent versions they're freely available, but if you're a student, you probably have access to them even if they're not), but you can search for that. If you still want to create it yourself, you should start by making sure you understand both the algorithm and LabVIEW well enough.


    I have no particular content to recommend for learning LV, but you can start here - http://labviewwiki.org/LabVIEW_tutorial

  9. I would suggest you not use LV for this. There are dedicated programs for setting up complex installers and you would probably be better off with one of those. In LV, the only real customization is the ability to specify an EXE to call after installation. I have no experience with such programs, but there have been some threads discussing them over the years (I would suggest looking under the relevant category, or searching for "InnoSetup", which is the only name that immediately comes to mind).


    It also seems to me that you have some confusion about how projects work. They are not some magical file system which takes care of things automatically. They are simply an organizational tool which LV uses. Every item in the project points to a specific file on disk. Virtual folders are simply a tool for grouping items in a way which would be more relevant in that context.

  10. I wonder if this can work:

    1. Open the typedef.
    2. Save the enum control somewhere.
    3. Replace the enum with a numeric.
    4. Apply the changes.
    5. Do your disconnecting.
    6. Replace the numeric with the enum you saved.
    7. Apply the changes.

    A quick test indicates that replacing a an enum with a constant and a constant with an enum preserves the value, but I don't know if this applies when you do it with a typedef and I don't know if it will help with this specific issue even if it does work on typedefs. My guess would be no, because whatever's resetting the value will probably still happen at some point in this process, but that's just a guess.

  11. That's what I mean with I don't know why LabVIEW does not allow me to do this - we got recursive VI calls eventually...


    I haven't worked through all the implications, but I wouldn't be surprised if you're right and this isn't strictly necessary (because the DVR doesn't need an actual object allocated) and with enough work, NI could resolve this in the same way it resolved static recursion. My guess is that if this is the case, this is simply an inheritance from static type recursion, where LV does need to allocate a value statically, since you can't have a null object.

  12. Excel has a default time definition of number of days since January 1, 1900, although due to a mishap when defining that epoch and forgetting about that 1900 wasn't a leap year, the real epoch starts on midnight December 31, 1899.


    This was actually there back in Lotus123 and is apparently by design, as it allowed the program to calculate leap years by using a much simpler algorithm at the cost of being wrong for 1900 and 2100. Probably a minor price to pay for a program designed in the early to mid 80's.

  13. I'm pretty sure all the functionality should work, but I don't remember testing specifically. You can look at the documentation for each method or make a small test app.


    Some potential caveats:

    1. LV strips the BD of all VIs that go into an EXE unless you explicitly tell it not to. Without a BD there's nothing to capture.
    2. LV strips the FP of most VIs which go into an EXE. For both, this isn't relevant if you're looking at external VIs.
    3. At some point, LV lost the ability to read an image from the clipboard in an EXE. The method just doesn't work. I don't think this affects writing an image to the clipboard, but it might.

  14. This brings me back to me wondering why the direct inclusion of a circular reference isn't allowed, and in turn why the runtime cast to the self-referencing object does not result in an allocation failure - one of the two ought to be the case. I must think about this some more. The answer is probably quite simple...


    It is, and it's two sides of the same coin - the static link is simple to understand - LVF has an LVFR, which has an LVF, and so on. There is an issue with resolving the type, because you have to keep adding more layers infinitely. The dynamic version works because this doesn't actually need to happen - when you stuff the LVF DVR into LVFR, the actual object inside the DVR has its own LVFR which doesn't point to any other object (its data type is LVO and the DVR is empty), so the recursion stops at that point.

  15. Which type should be a parent of what? I have this relationship, and none of those two clases currently have a parent:


    attachicon.gifLVFile UML.png


    LVFileRefs should have a DVR to a LabVIEW Object (not LVFile). At run-time, you populate this with a DVR of a LVFile. You create an accessor which reads the DVR and casts it down to an LVFile DVR for using it (you might need to do the casting inside the IPE structure).

  16. Bugger, I can't put a DVR to the owning class (LVFile) inside LVFileRefs' data control, since LVFile obviously has LVFileRefs in its data control  :angry:.


    Let me think of a workaround here - first I'll have to get my head around why this restriction is in place. Is it perchance a recurrence thing?


    I haven't read the rest of the thread closely, but in case this can help you - you can do this, but the data type needs to be that of a parent class (like LV Object). You can then use the accessor which reads the DVR to cast it down to LVFile.

  17. I haven't looked at the code, but there are also other ways of doing this. If you think about an FGV, it's essentially just a way of performing different actions on the same piece of data. Your code creates a wrapper to turn the actions into VIs. If you're doing that, you can also just pull out the data and get rid of the internal FGV entirely.


    For example, the shared data could be a cluster (or an object) in a DVR. Each action simply takes the DVR and operates on the data, so the "increment num" action could look like this:




    It starts with a call to the GET DVR VI (inlined into the caller here for simplification) and then does the action.


    This allows you to get rid of the enum and the FGV VI itself and the need to match the API correctly. It might make debugging more difficult, because you no longer have a single VI you can go and probe to see what's happening.


  • Create New...

Important Information

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