Jim Kring

I'll try not to repeat myself too much here, since I've already posted a response here. I do welcome participation in making OpenG better and the current repositories are open to issues/pull-requests/etc. I'm not in favor of a new GitHub repository at this moment, since there are several things I've had on the roadmap, including fixing the website issues.

I'm still confused by all this, Michael. You created a fork of OpenG on GCentral without their permission and so they asked you to remove it? And, now, you've created a new "dedicated OpenG organization" on GitHub? It seems like this is just moving/stiring lots of things around and nobody who has a vested interest in the ramifications of those actions, is being consulted about it, first. If the aim is to promote better code and collaboration in OpenG, then what would help is to contribute/propose some ideas, especially around processes and structure for contribution. A haphazard approach won't work well for building community -- simply creating new GitHub pages/repos and starting forum discussions about forking OpenG will only create confusion. That all said, I'm happy to have your participation and enthusiasm in making OpenG better. There are several efforts on the roadmap for OpenG, and we can certainly use some helpful participation.

Hi All. The OpenG wiki had several technical problems, so we dropped it -- I agree that we need a new landing page for OpenG with information and docs (and we can redirect old links). I've been working with others over the past several years maintaining the OpenG packages on GitHub (e.g. OpenG-Variant-Configuration-File-Library), providing bug-fixes and upgrading the OpenG libraries to NXG (despite the fact nobody was really using NXG for real work -- that'll be changing the the next couple years). I'm aware that people are becoming very interested in collaborating more on OpenG, especially with the enthusiasm around the upcoming LabVIEW Community Edition release (I am super excited about LV Community Edition, too). I'm really happy to see this renewed interest in LabVIEW and OpenG, since I've been doing a lot of the maintenance work, myself, and would love more participation in both development/testing and documentation/examples. LAVA isn't generally the best way to reach me, but I'm available at jim.kring@jki.net or @jimkring.

Michael, can you clarify this? Most of the key OpenG libraries have been migrated to GitHub over the last couple of years (e.g. OpenG-Variant-Configuration-File-Library), and there has already been a lot of work done to migrate OpenG to NXG. Is the intent to fork the OpenG libraries? Thanks, -Jim

Thanks, Benjamin! Any chance you could post your example VI? I can't seem to place the snippet PNG.

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.

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 ;-)

Thanks @Darren @Aristos Queue @rolfk

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?

More info here: https://forums.jki.net/topic/2676-vipm-2017-for-mac-is-here/

More info here: https://forums.jki.net/topic/2679-vipm-2017-for-linux-is-here/

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.

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 :-(

I don't have a quick answer for this one. I'm curious about it...

OK, so I'm not crazy. :-)

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:

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.

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.

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/

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!