mje

Yeah, as someone who has used the picture primitives a lot, all I can say is I feel your pain with regards to quality. The bitman library is fantastic but won't help with text. As for size, LabVIEW uses the size as the pixel height of the line. So three lines of size 15 text occupy a bounding box 45 pixels high (assuming no rotation). That doesn't mean the text is 15 pixels on each line though, the exact dimensions of that are determined by the font.

Also not a lawyer. Would you instead be able to assign copyright and disclaimer to members of an "OpenG Group" or similar? That way individual people and time frames need not be called out depending on what dependencies were used. "Copyright 1995-2015 © members of the OpenG Group. All rights reserved." How OpenG handles membership would be a detail that doesn't need to be in the license. Not sure if there's precedent for anything like that. Also not sure how to phrase it such that the group proper isn't claiming the copyright, rather stating individual members of the group take claim. Having a clear attribution/disclaimer statement would go a long way to getting adoption in my book. Part of the problem is indeed there's no easy way to know everyone has been covered, and the inability to provide objective evidence that every claim has been made is part of what prevents me even trying to push something like that through. Yes, I could scrape every front panel and put something similar to what JKI did into my application but there's no way to objectively prove I haven't missed anything. There are other issues though that I really don't want to discuss, but suffice it to say fall into the category of change resistance-- "that's not the way we do things." Things like SOPs/ISOs/WTFs that need to be invoked/consulted/created to release an application containing code under some license. These barriers come from the consumer of the library and I think an author would be hard pressed to do anything to tackle these obstacles. Frankly I don't want to deal with any of it, I just want to create an application that works.

Yes, I'm aware of the LabVIEW license requirements and BSD. That comment was originally presented in another context and wasn't meant to refer to either, rather licences that have non-commercial clauses. I'm not implying it is a valid model for OpenG. Anyways, I was trying to say how I've come to very much like the model of distributing with a restricted free license with alternative paid licenses available if required. As for the throwing money comment, I can't really be specific in a public forum. All I can say is sometimes provisions in a license are unacceptable and instead we may look for an alternative. Again though, I realize this isn't appropriate for OpenG.

Ditto. Full credit to the OpenG authors for a fantastic library, but the reality is the licensing burden exceeds that of just banging out my own implementation. Even if the licensing was bottled up with a single clear attribution statement, there are other corporate challenges to using open source. There's something to be said for just being able to throw money at the problem to get your own commercial license and not have to deal with open source requirements. A few hundred to a few thousand dollars may well be worth my time even if you also distribute via open source licenses. And here's a hint: when I say "worth my time", I'm not weighing against the time it would take for me to implement your library myself. I'm considering bureaucratic burden.

Wow. I think xcontrols finally make sense. Wait. Sorry, momentary lapse of sanity. I never said that.

Yep, the behavior is consistent. I had a good idea of what was going on even in the original post. It's very subtle and when I tracked a bug down last year to this, I was left wondering how many odd behaviors of my previous applications could be explained by this. There are many ways to insure against this behavior, but that wasn't the point of the thread-- I think we can all work our way out of this situation once we identify the cause. I understand the distinction between execution and run mode, and how that pertains to static event registration. We know VIs have state data, that's how control data persists between calls, uninitialized shift registers work, etc. However never in my years of experience had I ever seen any example where changes that happen while my diagram is not executing could generate events to be consumed during execution. It has made me rethink how I think about static events. The lifespan of static event registration is fundamentally inconsistent with how I've been treating event context in my dialog VIs. I may very well adopt practice of using only dynamic event registration just so I can be in absolute control over the lifetime of the registration.

I just came across this while cleaning up old code so I thought I'd resurrect the thread and maybe get some more discussion this time around. I'm not satisfied this is good behavior. For the second call of the VI to generate an event that essentially originates from actions taken on the VI from the first call (or perhaps worse, an event from the first call being handled in the second call) seems to violate some form of encapsulation, but I can't quite pin down the right terminology. Yes, reentrancy would eliminate the issue, but I think something is fundamentally wrong with the build-up and tear-down mechanics of static event registration.

The definitive guide would be the documentation. Every VI that takes an error in either has the "This VI provides standard error I/O functionality" statement or specifies what happens when an error is supplied. I always document my VIs in a similar manner, usually something like "this VI operates regardless of supplied error state" if not standard, or more specific when need be. I agree with you and NI's practice of having release and destroy VIs always operate. Over the last few years I've also started backing off from always having error I/O. Simple VIs which are incapable of generating errors don't have error cluster I/O. I'm looking at you accessor VIs (for the most part).

I for one really liked some of their products, but can't ever see myself giving them money again so long as they stay exclusively on this "cloud" platform. I don't want access to my data to be held hostage for $x/mo indefinitely, never mind the performance considerations for pushing large amounts of data around the cloud. For what it's worth, NI would become irrelevant overnight for me if it went to a cloud platform. There are just so many reasons not to do it, especially in a corporate landscape.

My profile picture puts me bang on for when it was taken. Frightening and awesome.

We don't display the build number anywhere in the applications, but we do use them in release testing since the number can be extracted via Windows Explorer. When you've build your fifth release candidate and they're all labelled version X.Y.Z, you sort of need that last hidden number.

Here you go. It's not quite a drop-in from what you describe. The system dialog is modal and I believe it centers on screen, opposed to the LabVIEW color picker which can be made appear more like a context menu. The modality likely helps though since dismissal is automatically handled. Hope it helps. m Edit: this source code is released to the public domain, blah blah blah. .NET Color Picker 2013.vi

I've done this exact thing, but I used a system call to display the OS color dialog. Pretty sure it handled the case you describe. If this is an option for you I can dig up the utility VI I wrote. It's for Windows, though I can't recall if it used the Win32 or .NET API.

We've stuck with SVN, it's suited me just fine and I love it. At one point I understood the DVCS systems, but never saw the need for it in my workflow and haven't bothered to switch over. Because all the cool kids are doing it doesn't fly for me. Now excuse me while I cry, because my SVN is being pried from my hands in favor of...urgh. Don't make me say it. Rational Team Concert. It sort of works, so there's that.

I've been getting my hands dirty with embedded C programming lately for AVR chips. A fascinating reversal of perspective from LabVIEW where resources are so abundant you don't need to think of them. I think it's good to rotate skills from time to time, lest one become overly focused on a single tool.

My company maintains MSDN licences for developers. There's an OS only license which while not cheap, is a great value considering it gets you access to every OS they have made (within reason) over all the localizations. Wonderful for testing and also very valuable for being able to have a clean OS for each major project. Depending on the operating system the number of keys you can claim may be rather limited, but they allow you to re-use the keys quite a bit. I've never run into the limit, but my conversations with support imply if you ever hit it, it's a simple matter of calling them up and they can reset things on their end.

I have no answer for you, but like the idea you have. "Type Definition modified" is a very annoying bug. Any insight into what triggers the behavior would be welcome.

I'm don't particularly like the confrontational relationship I often hear about between the engineers or architects of a project and the levels of management. Though it can produce good software, I think when it does it's in spite of rather than a result of these relationships. It really only serves to advance the project through to completion and has nothing to do with producing "good" software. Fortunately, despite working at a large company, I work with a small team of experienced and talented people at all levels of the project. Our managers are extremely deft at dealing with the demands of marketing, quality, documentation, phase gates, and other aspects of the nine levels of hell bureaucracy that need to be dealt with to release anything at a large company. They serve some very important roles, but when it comes to details of implementation they defer to those who know best: the architects and developers. Without our management team I wouldn't be able to do what I do, and wouldn't be nearly as satisfied with my job as I am.

I'm on vacation for the next week so don't have a system handy to check the details, but I recall the quick drop settings are stored in a pair of config tokens. If you have any custom shortcuts defined, do a search for any of them and you should find them. This would be in your private LabVIEW.ini somewhere in your LabVIEW data folder, not the LabVIEW.ini in the main program files folder.

The llb is older. I can't remember when the lvlib came around, but it's been around for several versions now. I can't say I'm familiar with the old implementation, but I've used the newer one extensively. Works great.

This is a fantastic idea, I wish I had thought of it earlier. Specifically all I'm really interested in is preserving my LabVIEW.ini settings across systems. Mostly for the quick drop shortcuts, but some other environment options as well. This is the main reason I'd likely not synchronize all data. I really just want the same config across all my systems.

I suppose the thing that's kept me from just moving my LabVIEW Data directory to Dropbox is I have no idea how LabVIEW will tolerate concurrent access to the settings. I don't anticipate well. It's not uncommon for me to have two or more VMs fired up each with LabVIEW running.

This is a good idea. I also chiefly work on VMs and have wanted to do this for a while, but never got around to looking into how.

+1 for InnoSetup Fantastic tool. I don't bother with NI installers anymore.

That performance is worse than I'd expect. Yes, LabVIEW is terrible at image manipulation, but I don't quite expect that level of awfulness. I do something similar to your first two options but rather than generating a video I make a (large) collection of images to disk. I've never timed it but it can dump a few hundred PNG files in a reasonable amount of time (a few seconds maybe?). This includes the LabVIEW logic to render the picture layers with the native picture API (*cough*). What dimensions are we talking about?