Jump to content

Darren

NI
  • Content Count

    560
  • Joined

  • Last visited

  • Days Won

    45

Everything posted by Darren

  1. If you take the project from one environment to another, then you might expect to see many (or all) of the VIs that make ActiveX calls to want to be recompiled. The ActiveX component version mismatch issue is independent of the Excel_Print issue workaround. That's why any ActiveX-based toolkit (like the Database Toolkit) will demonstrate these issues.
  2. Ok, now it's coming back to me (I haven't worked on the Report Gen Toolkit in several years). You mentioned that the version difference only appears with that one VI? I'm starting to remember that there's a weird ActiveX bug with the Print method for Excel that Microsoft never fixed, and we were able to workaround it by installing a non-mass-compiled version of the VI that calls that method (Excel_Print.vi). A recompile on an installed system (which will always happen when the VI is saved in an old version) works around the bug in the Print method.
  3. I can speak to the Report Gen Toolkit and Database Toolkit issues specifically. Both of these toolkits are mass compiled in the appropriate LabVIEW version before release (which makes me wonder about Jordan's second screenshot above referencing LV 8.6b7...this may be a bug). Bugs notwithstanding, both of these toolkits happen to make extensive use of ActiveX calls. If there are any differences in the ActiveX components on different machines, then the VIs will prompt you to save changes, even if you didn't actually make any edits to the VIs. This is illustrated by the message in Jordan's first screenshot ("external component modified"). One common cause would be a machine with a different version of Office installed than the one installed on our build machines here at NI, but there are many other causes of ActiveX version number differences as well.
  4. That's right. When you're scripting, you need to use the Undo transaction methods in order to preserve (and add to) the Undo history.
  5. If you drop a dummy object on the diagram, then delete it, without wrapping those operations in a Begin Undo/End Undo transaction, it looks like it clears the Undo history.
  6. Call the "Get Tag" method of the ProjectItem class and use the alias.value tag:
  7. In this thread I posted a VI that wraps a private function to suppress LabVIEW dialogs. Standard disclaimer here about using private functionality in production code, etc. etc.
  8. 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: From here, you can parse the project and get the Application Instance (which will be different per target in the project) you want.
  9. Maybe use a subpanel to switch out the visible controls depending on user preference?
  10. 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
  11. 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: Unfortunately, this functionality is not available in LabVIEW prior to version 2013.
  12. Nope, still not prompted: Here's the VI I'm trying (saved in LabVIEW 2013), if anybody wants to modify it in such a way that I get a prompt when the VI closes. test script and close.vi
  13. 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.
  14. What specifically are you doing to the VI to cause it to prompt on close? When I create a new VI and drop an object in it, I don't get prompted to save when I close the VI, even if I set up an Undo transaction.
  15. Are you trying to close the VI interactively, or programmatically?
  16. Scripting properties and methods are not supported in the run-time engine, so a built EXE does not have the ability to perform VI inspection.
  17. Sure, here you go. Saved in LabVIEW 2012. OS Window and Native Window properties.vi
  18. I have said almost those exact words on more than one occasion.
  19. 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.
  20. My solution is to never, ever rename classes. I'm serious.
  21. 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!
  22. I have added a link to this post to the CAR, and indicated that we should prioritize this over some of the other CARs I've filed about moving private stuff to public/scripting.
  23. 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: When doing this on the "Build Path" OpenG VI, it shows the File I/O palette instead:
  24. 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.
  25. 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.
×
×
  • Create New...

Important Information

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