Jump to content

Darren

NI
  • Content Count

    579
  • Joined

  • Last visited

  • Days Won

    48

Posts posted by Darren

  1. The MenuLaunchApp property only works the way you desire when the menu launch VI is launched from the menu of a VI. If you want to gain access to the project from which the menu launch VI was run, you'll need to use the Active Project property:

     

    post-4441-0-53480500-1391442003.png

     

    From here, you can parse the project and get the Application Instance (which will be different per target in the project) you want.

     

  2. I don't know anything about the internals of LabVIEW window management, so I can't speak to whether or not what you're seeing is intended behavior when the windows are reparented via winapi calls.

     

    Here's a VI that may help, though. This password-protected VI (saved in LabVIEW 2013) calls a private VI Server property to suppress LabVIEW editor dialogs. Call this VI before you do your scripting, with a TRUE input. Then when your scripting is done, call it again with a FALSE input to reenable LabVIEW editor dialogs. <standard disclaimer here about using private LabVIEW functionality in production code>

     

    Suppress Dialogs.vi

     

     

    • Like 2
  3. In LabVIEW 2013, you can check out the following shipping example to see some snippets of scripting code that modify the configured events in an Event Structure:

     

    LabVIEW 2013examplesApplication ControlVI ScriptingStructuresVI Scripting with Structures - Event Structure.vi

     

    Here's a screenshot of the applicable part of the example's diagram:

     

    post-4441-0-79431900-1387479036_thumb.pn



    Unfortunately, this functionality is not available in LabVIEW prior to version 2013.

  4. The LabVIEW Run-Time Engine excludes functionality that is purely for editing use...for example, there are no palettes in a built EXE. I'm guessing this is done to keep the Run-Time Engine size down. For better or worse, LabVIEW Scripting is considered editor functionality, and as a result, is not currently included in the Run-Time Engine.

     

    FYI, the VI Analyzer Toolkit includes a test called Built Application Compatibility that will check your application for any functionality that is not included in the Run-Time Engine.

    • Like 1
  5. Open your main VI, press Ctrl-F, select "Objects", and specify a MathScript Node as the item to search for. Assuming your application doesn't call any dynamic VIs, and you have the "Search Scope" set to <All VIs in Application Instance>, this should find all the MathScript Nodes in your application.

     

    post-4441-0-30972500-1384964543.png

     

     

  6. I just updated my OpenG libraries in LabVIEW 2013 and everything looks good. For posterity, the new palette object names I observed were:

     

    OpenG Array Palette

    Empty Array? (OpenG)

     

    OpenG File Palette

    Build Path (OpenG)

    Strip Path (OpenG)

     

    OpenG Time Palette

    Tick Count (ms) (OpenG)

    Wait (ms) (OpenG)

    Wait Until Next ms Multiple (OpenG)

     

    With Jim's changes, all 6 of these OpenG VIs are now droppable with Quick Drop, and they display the proper owning palette when you right-click them.

     

    Thanks for implementing the fix, Jim!

    • Like 1
  7. I discovered another reason, independent of Quick Drop, that these duplicate palette name issues should be fixed. When you right-click on a subVI, you don't get taken to the correct owning palette for identically named items. Right-clicking on an OpenG File VI should show the OpenG File palette, like this:

     

    post-4441-0-35427500-1378248328.png

     

    When doing this on the "Build Path" OpenG VI, it shows the File I/O palette instead:

     

    post-4441-0-78305100-1378248364.png

  8. Would you consider this a Quick Drop bug (that brackets in a VI Window Title would cause a failure of QD)? Might want to generate a Hash of the name and use it as the UID/reference for each item that appears in the list, rather than reference by name.

     

    I suppose you could consider it a "bug", although this is the first time in Quick Drop's six-year history that I've heard of somebody wanting to include a bracketed suffix in a palette object name and have it *not* refer to the owning library.

     

    Speaking of libraries, I just confirmed with Stephen that, if you namespace an existing VI with a library, but leave the VI's location and name on disk unchanged, then existing code that links to that VI should automatically relink to the newly-namespaced VI without issue. We've used this trick at NI on several occasions when adding library namespacing to existing APIs...I see no reason why it wouldn't work for the OpenG libraries as well.

     

    So again, the very low-budget solution to this issue would be to figure out the OpenG palette objects that share names with core LabVIEW functions (it looks like there are about 6 of them from the discussion above) and add an "(OpenG)" suffix to their window titles. The more elegant solution would probably be to add libraries to namespace the OpenG VIs.

     

    And looking forward, I've never particularly liked palette VIs that have different palette names than their VI filenames (the exception being Merge VIs). Hindsight is 20/20, but I probably would have just named these VIs something like "Build Path (OpenG).vi", with no custom window title/palette object name, from the start.

  9. Would it create any problems (for Quick Drop) to use brackets in the VIs window title so that it looks a little more like what Quick Drop adds to LVLIB members?

     

    Unfortunately, brackets in palette object names are treated special by Quick Drop, so suffixing with "[OpenG]" would not work. Any other delimeters (parentheses, braces, etc.) should work fine, though. I think I'd prefer if we kept brackets as a library name designation, so if you did suffix the OpenG object names, I'd prefer it be with parentheses.

  10. How would it appear in Quick Drop? Would the user be able to visibly distinguish between the OpenG Build Path and the built-in Build Path?  For example, would (or could?) Quick Drop show "OpenG.lvlib:Build Path" or maybe "Build Path (OpenG.lvlib)" / "Build Path (OpenG)".

     

    Palette VIs that are namespaced with libraries (or classes) appear with the library name in brackets, like so:

     

    post-4441-0-85620300-1377968914.png

    • Like 1
  11. Quick Drop will list multiple identically-named objects if they are namespaced differently. So one possible solution would be for OpenG to include all of their palette VIs in a library...this would cause both "Build Path" and "OpenG.lvlib:Build Path" to appear in Quick Drop as separate objects.

     

    Assuming OpenG does not want to start including palette objects in libraries, I thought the renaming option was a simpler and more viable solution.

  12. I've been making a pass through all the LabVIEW palette content on my system, looking for duplicate names between palette objects. Since Quick Drop will only list a single object of a given name, I think it makes sense that all unique palette objects should have unique names. I have come across three OpenG VIs that have identical names to built-in LabVIEW functions (and thus, cannot currently be dropped with Quick Drop):

     

    Empty Array? - user.lib_OpenG.libarrayarray.llbEmpty Array__ogtk.vi

    Build Path - user.lib_OpenG.libfilefile.llbBuild Path__ogtk.vi

    Strip Path - user.lib_OpenG.libfilefile.llbStrip Path__ogtk.vi

     

    Currently, these VIs use window titles to define their palette entry names. Would it be possible to update the window titles of these VIs to have different names than the core LabVIEW functions, thereby allowing these three OpenG items to be droppable from Quick Drop?

  13. Maybe that's it, maybe they used the High Resolution Relative Seconds to get a more accurate time?  Most likely this is not the fix because I think the high resolution time is Windows only which is why it isn't on the palette yet (just speculation).

     

    High Resolution Relative Seconds.vi works on all desktop platforms, and it also works in RT.

  14. Tree:FocusItem doesn't seem to work for me in 2012 SP1 (12.0.1f3) - I get an Invalid Property error: The property is not valid for this class.

     

    Argh, you're right. When I checked this morning I was awash in several open LabVIEWs and checked the wrong one. The "Focus Item" property of the TreeControl class is only available in LabVIEW 2013 and later. I have updated my post above to reflect this. Sorry about that.

×
×
  • Create New...

Important Information

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