Jump to content

Jim Kring

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Thanks, Benjamin! Any chance you could post your example VI? I can't seem to place the snippet PNG.
  2. Has anyone noticed that if a window (A) has no titlebar AND (B) is resizable, then it will have a white stripe at the top of it? (see screenshot below, and note that the big titlebar is not actually a titlebar, but a styled button, and the actual titlebar is hidden) Has anyone figured out how to get rid of this white strip (perhaps with Windows API calls)? I know I can get it to go away if I make the window NOT resizable, but I don't want that -- I need to be able to resize. I've done a little googling and the only thing I can really find how to set up WPF properties for the windows, and I can't seem to find any magic user32.dll calls or anything like that. Here's an example: white strip at top of window.vi Thanks for any help or ideas.
  3. OpenG isn't dead. There just hasn't been a lot of work on it lately (though we have been working to keep them working in NXG). I've been in the process of moving the libraries over to GitHub, as needed. LAVA posts aren't the best way to get in touch ;-)
  4. Does anyone know how to open the "Edit Events" dialog programmatically, passing in either a frame reference or using the currently visible Event Structure frame? Perhaps @Aristos Queue, @Darren, or @Christina Rogers knows?
  5. More info here: https://forums.jki.net/topic/2676-vipm-2017-for-mac-is-here/
  6. More info here: https://forums.jki.net/topic/2679-vipm-2017-for-linux-is-here/
  7. I'm looking for a way to change a visible state of a Case Structure, and (A) not have this show up in the Undo Transaction history and also (B) not wipe out the undo history. Right now, if I don't create an undo transaction (and simply call the scripting function) for the visible frame change, then it wipes out the entire undo transaction history :-( Since a user can click on a Case Structure in the IDE to change the visible frames of a Case Structure and it doesn't show up as an Undo-able action, I would assume that I should be able to call the corresponding scripting function to change the visible frame of the Case Structure and have it not wipe out the undo history. Note: From reading this post by Darren it seems that many/some of the scripting functions will wipe out the undo history if they are not wrapped in an undo transaction. I'm not sure why setting the VisibleFrame property would do this since it's not actually change the code.
  8. I'm looking for a way to change a visible state of a Case Structure, and (A) not have this show up in the Undo Transaction history and (B) not wipe out the undo history. Right now, if I don't create an undo transaction for the visible frame change, it wipes out the undo history :-(
  9. I don't have a quick answer for this one. I'm curious about it...
  10. I'm trying to read the icon of an xnode by reading the NI.Lib.Icon property, which is encoded zipped binary data of the image. This code generally works for reading any LVLib icon (note dependency on OpenG Zip Library). I've noticed that for many XNodes, the icon data looks very weird, almost scrunched up. Any ideas why this would be the case? And others look fine:
  11. I'm curious about the best practices and caveats others have discovered related to using LabVIEW's built-in installer builder for distributing apps efficiently. Note: I saw an old post by crelf here where there was some discussion of approach #1, below, and a follow up by Tonn Plomp about that mentioned the problem I've sited below. Problem Application installers that include dependencies (e.g. LabVIEW Run-Time Engine, IMAQdx, DAQmx, VISA, etc.) can be quite large. When users are upgrading to new versions of your application, it would be nice if they could just download the new application, and not have to download the dependencies, if they have not changed. Solution (over-simplified) Separate the installation of the application from the dependencies, and manage this all somehow. More details on approaches... = Approach #1 / Have two installers: "Full" (App + Dependencies) & "Upgrade" (App only) = How: Copy the installer rules and delete the dependencies. Call this the "Lite" or "Upgrade" installer. Problem: The full installer and lite installer will likely have different product guids (component codes / installer IDs), so Windows will treat them as two different applications. And, since they are installing your application into the same location, there will be a conflict. The installer will not actually uninstall the old files first (maybe, or other bad things will happen that we can't predict). = Approach #2 / Have two installers: "Application" & "Dependencies" = How: Create an installer that includes the application and the dependencies. Then, make a copy of this and remove the app, so that only dependencies are installed -- call this "Dependencies". In the original installer build spec remove the dependencies -- call this "Application" Problem 1: The first time the software is installed, the user has to install two separate things: Dependencies and then Application. Solution: In the "Dependencies" installer, include the installer for Application as additional support files, as well as a batch file that gets called as a post build spec to install the Application, after the Dependencies get installed. Bonus: call this installer "Full Install" since it now includes the Dependencies AND the Application -- but, note that it's structurally different than the Full version in Approach #1, above. Problem 2: What happens when the dependencies for your application change? (e.g. if it requires a new version of the run-time engine or if you start using some other LabVIEW feature that requires an additional support installer) Solution: Use some kind of versioning scheme where users understand that major releases of the Application will require upgrading the "Dependencies" installer to the same major version, too. = Approach #3 / Use a package manager with dynamic download and dependency management capabilities = OK, we know this is the best solution, but let's explore what folks are doing with the above two approaches, for now... Looking forward to hearing what people are doing and what your thoughts are on these approaches I've outlined.
  12. Thanks, LogMAN, for the helpful info! Filipe, it sounds like editing the XML worked for your needs. I hope it's all going well for your project.
  13. JKI is donating a Surface3 (which can run LabVIEW and Windows Desktop). Don't win one at the LAVA BBQ, you can still win one: https://instagram.com/p/58MjJOHEUQ/
  14. Hi Everyone. I wanted to share what I was working on. It's a new quickdrop plugin that adds delays into your code. Finding the screen coordinates of block diagram objects was important for "flying the fairy" to the right location on the screen. I've added you guys to the credits Thanks again for your help on this fun little project!
  15. Thanks for the quick ideas and examples. I'll do some testing to see how this works! This is for a fun little pet project that I'll be announcing and sharing with you guys soon
  16. Anyone solved this problem? Basically, I want to get the screen coordinates of a block diagram object. Thanks!
  17. Hi All: Please let me know if/when you need this built/released. I want to support this!
  18. Thanks for the info, everyone! My takeaways are: - NI is eating its own dogfood and using this feature internally to a very great extent (I'll see if I can verify this and learn more). - For projects that do not have multiple targets (e.g. Windows desktop only, and no Real-Time targets in the same project) this seems to work very well in 2013 and 2014 (but, there were lots of problems in 2012 and earlier) - For simple projects that have multiple targets (e.g. Desktop and Real-Time targets in the same project) this seems to cause issues ("small hiccups" and "odd things") that can usually be resolved by clearing the object cache. - For larger and more complicated projects with multiple deployment targets there can be (A) deployment errors when running in interactive mode on remote target, as well as (B) build problems. Unfortunately, forcing recompile and clearing the object cache doesn't always work to resolve the issues. For some users, this is too big of a pain and they have abandoned the use of Separate Compiled Code from Source on these projects. Did I get that right? Anyone else have good/bad experiences or input to the topic? Thanks,
  • Create New...

Important Information

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