Jump to content

Jim Kring

Members
  • Content Count

    3,851
  • Joined

  • Last visited

  • Days Won

    18

Jim Kring last won the day on March 5 2018

Jim Kring had the most liked content!

Community Reputation

96

About Jim Kring

  • Rank
    packages everywhere!
  • Birthday 03/17/1976

Profile Information

  • Gender
    Male
  • Location
    Lafayette, CA
  • Interests
    LabVIEW

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since
    2017

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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.
×
×
  • Create New...

Important Information

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