Jump to content

Thoric

Members
  • Content Count

    150
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Thoric

  1. Wish I'd read this thread before I took my CLED! I didn't realise documentation was worth so little! Luckily I passed also, but next time I take a test I'll pay more careful attention to the grading criteria! Well done to everyone who's passed the CLED, and good luck to all future LabVIEWers who take it!
  2. I'm looking for a way to get the color of a datatype wire, i.e. as it would appear in the connector pane for an associated front panel control. A little more detail: Take a standard VI with a handful of controls and indicators wired to the connector pane. Each datatype's core wire color is shown in the associated connector pane terminal box. Can you programmatically retrieve this color for any datatype? What I've tried: I've looked for a "datatype" property node in the hope of extracting further information, but not sure that's helpful. I've played around with the Class Identifier fo
  3. Yair, Rolf, Thanks for the replies. I agree, the IDE has always been difficult to tap into, and this was something I wasn't truly expecting to get to work, but it was always worth asking the world's best before giving up. The Fake Exec state isn't going to work for me, the VI has to remain in true edit mode for what I had in mind. Back to the drawing board...
  4. Is there a way to interfere with the edit time shortcut menu of a front panel control? I want to be able to register for the Shortcut Menu Activation? filter event for the controls of a VI that's in edit mode, and inject my own menu items. I can only get this to work if the target VI is reserved for execution (running state), and not when idle. (To be clear, there are two VIs here. A running VI with an event structure that's meant to be interfering with the shortcut menus of the other's front panel controls whilst the operator is editing it. I want to be able to inject my own menu item
  5. Thoric

    DSF0757

    It's me again - and another beer in my hand. What a surprise!
  6. Thoric

    DSF0686

    Everyone on that bus took a souvenir photograph. Funny at the time, and still funny now! :-)
  7. Thoric

    DSF0676

    You'll rarely see me without a beer in my hand!
  8. How bizarre! Yes, that works. Dropping a simple ADD function, then deleting it, vaporizes the Undo History. Any thoughts as to why? Can LV not cope with changes that aren't wrapped in an Undo transaction?
  9. Snippet included as an attachment, rather than an image.
  10. I can't get this to work programmatically. If I manually set a VI's protection to password-protected through the VI Properties window, then unprotect it again, I see the Undo history is emptied. However, if I programmatically invoke LockState.Set with Password-protected, then invoke LockState.Set with Not Locked, the VI undo history remains in tact. Inserting a Save.Instrument makes no difference either. The Undo history always persists! Any thoughts anyone? Below is a snippet of some example code that attempts to prove that password protection of a VI clears the undo history. It
  11. Thanks Darin. I'll try that. Presumably if I take my target VI, apply a password, remove the password, I'll find the undo history is blank and the VI remains unprotected. Cheers! Edit: it seems LAVA now thinks I'm no longer "Thoric" but "Riggy" !?
  12. I want to clear a VI's undo history, programmatically, from another VI. I see in 2013 that saving doesn't clear the history, so my original plan to simply save my target VI somewhere isn't working. Is there a scripting technique that will obliterate the undo history?? A quick search didn't find anything.
  13. Here: http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/
  14. Thanks Darren, this is an interesting function. Kudos for putting this together for me.
  15. OK, so this is where I'm at. Taking Darren's code segment above and slowly adding my own code to it until the Save Request issue arises, I see that it occurs as soon as I dock both the front panel and block diagram of the scripted VI into two individual containers. If I dock just one, or neither, LabVIEW doesn't ask me to save the VI when I close it. By 'docking into a container' I mean changing the parents of the scripted VI windows, using a winapi call. My intention is to 'contain' these two windows to control their access from within my own environment. I presume that once both the fro
  16. Jack. That's. Just. Awesome. I can see how powerful and reusable such a scheme would be. I'll be giving that a go (or at least a basic framework akin to what you describe) and I'll approach you directly, if that's ok, should I get a bit stuck. Thank you
  17. Thanks for replying Shoneill, XP Embedded is essentially the same as XP, so the LabVIEW code is identical. Real-Time is a wholly different kettle of fish, and there you have no static events, but you can still have user events. Anyway, the crash turned out to be a memory leak issue, which turned out to be due to my own coding error. I had a "Register for Event" node inside a while loop when it should have been before it, so consequently I was creating a new reference to the user event with each iteration of the while loop. Ooops.
  18. This component is part of a much bigger system that needs to work optionally on a machine without LabVIEW. I'm conducting a feasibility study at the moment, so if this doesn't work out too confidently I'll pull the plug.
  19. I'm not at my PC today, but I am making a few winapi calls to the vi to change its parent. I'm kinda docking it in a container, so that must affect LabVIEW? I can modify your code tomorrow to mimic mine, most likely.
  20. I can only think up one workaround, and that would be a lot of work - it would involve wrapping each scripting function in a wrapper VI, and using standard VI server calls to open each VI, populate the VI terminals and execute them, sequentially, to achieve the equivalent scripting requirements. This moves the scripting session into the IDE, yet it remains controlled from the external executable. I bet it would be frightfully slow though. Alternatively I guess you could keep the scripting elements of the executable as separate source VIs, and use VI server calls to load and execute them. L
  21. Darren: This is all programmatically. Darin: Thanks, I was beginning to wonder if I might need to do this.
  22. Gleichman: you misunderstand. I don't want to inspect the exe. I want the exe to be able to use scripting calls on other VIs that are in the IDE. Think of it as a compiled version of VI Analyzer. Darren: I can understand why creation isn't supported, but if we're using Remote Server access to the LabVIEW IDE to purely read info about block diagrams then it's a benign process. Is there a reason this is blocked? Security concerns?
  23. Hypothetically, if one created a LabVIEW executable that used a remote application reference to interact with the LabVIEW IDE, how much of the scripting function set would work? I've already discovered "New VI" doesn't work, but what about the non-creative functions, such as programmatically showing a block diagram, traversing the block diagram, inspecting nodes and other objects etc.? It seems to me that it should be ok to perform inspection, just not manufacture, right? So why are a load (if not all) of the scripting methods denied when attempted from a remote interface?
  24. I've used scripting (which I'm still learning) to create a New VI, create some objects, show the front panel and show the block diagram. Now I want to close the VI and lose it, but because it has unsaved changes I get a dialogue box asking if I want to save it. I've set the options input to New VI to 0x0, which means it shouldn't be marked as modified and it shouldn't prompt to save changes. How do I close the VI silently? I have no interest in keeping the changes, so saving it first isn't what I want to do.
×
×
  • Create New...

Important Information

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