mje

Interesting, that's a new one for me. Yesterday I also discovered that the string-number conversion primitives work on arrays as well. Sort of blew my mind as well. Never stop learning...

Yeah, the Windows user experience on a desktop or workstation environment is a hot mess of inconsistencies at this point and hardly something to model after in my opinion. Especially since Microsoft has a track record of doing a complete about-face with regards to their guidelines (nevermind APIs), I don't exactly expect the current way of doing things to be around that long. Windows 8 is irrelevant to me: it interferes with pretty much every workflow I have, LabVIEW or otherwise. Maybe Microsoft will get something cohesive for the next iteration, or perhaps they'll fade from relevance, I don't really care which happens but I expect change. That said, if I have a main window with a menu containing a file item or equivalent, I'll throw a file exit command in there. My applications usually behave such that supplementary windows simply close if the system close button or keystroke is used, but the main window will interpret the close command as an exit signal, which will tear down any supplemental windows that may be open. Supplemental windows with menus never have a File > Close command.

"Stomper" huh? Interesting terminology given the context.

So here's another fun little behavior related to control focus. Consider a VI with a loop containing an event structure statically linked to the value change events of controls: alpha and beta. Alpha is some type of editable control like a string, and beta is a boolean configured to have a key binding. The value change event of beta terminates the loop. Beta is not configured to receive the key focus when the key binding is used. Scenario 1: Open the VI and run it from its front panel. While editing alpha, use the key binding for beta. The key binding triggers the value change event for beta, which causes the loop to return. We never see the last alpha value change event because the alpha control never lost focus, thus the value was never changed. Nothing alarming here as the beta control is configured to produce this exact behavior. Scenario 2: Call the VI consecutively from another VI. On the first call, while editing alpha, use the key binding for beta. The first call to our VI starts, and as before when editing alpha, beta's value change event executes, causing the first call to return. Now things get interesting. The second call to the VI starts, lo and behold the first thing we get is a value change event from alpha containing the data that was being entered on the previous call to the VI. Probably best demonstrated in a three and a half minute video. As far as I can tell this happens because on start up the VI clears the focus from alpha, therefore triggering a value change event from data that was entered on the previous call. Is this really desired behavior though? I think the expected behavior for most people would be all the setup mechanics of the window, including the initial control focus would be done before events are being generated. The example VI shown in the video is attached (LV2013): dialog.vi

Thanks for the idea Shaun, but I'm not entirely sure what you had in mind with that link. Thanks for checking Yair. I threw together a quick demo to show the problem, attached as LV 2013. It's a little dirty because I wanted to throw everything into a single VI but should serve as an example. MCLB+SB.vi The problem seems to rise entirely because my MCLB is an indicator-- apparently as an indicator LabVIEW is incapable of setting the key focus? This seems like an odd restriction considering if I click on it at run time it clearly does achieve key focus. Is this desired behavior? It would seem like a bug to me. I'd rather not make the MCLB a control, it would bring along a host of undesired behaviors, such as the cell focus box that can't be cleared and complicates key navigation since the control is by design not aware of any elements outside of what it displays.

I've been rocking 1Password for the last few years and I've finally lost patience with their pathetic Android implementation (other platforms are fantastic though). This weekend as I go through my passwords I've decided to look at KeePass and LastPass. I agree, password managers are the way to go, but if you use Android, my recommendation is to avoid 1Password despite how much I like it.

Very serious indeed. I am amused that in an era where major vulnerabilities and breaches are so publicized, I have not heard a peep from a single institution I deal with. In the past they've always been quick to alert clients, but not this time. Forget the important ones (banks, stocks, payroll, government entities) not even the technology companies I deal with have said a word. Amazing, I have absolute confidence that should some even more serious vulnerability arise to which there is no immediate fix, that we will be left in the dark lest any organization affect their image or stock price. Honesty and disclosure are only needed if the serve the bottom line or political gain. Yes, I'm cynical, but I try my hardest to find evidence pointing me away from the cynicism. I'm just not finding any this time around.

So something weird is happening I can't quite explain. I have a VI with a multicolumn listbox (MCLB) that I have implemented virtually-- that is it can contain a prohibitive amount of data so I just maintain the list internally and only display the rows that are visible based on page settings of an adjacent scrollbar (SB): The SB you see next to the MCLB called out in the image is not the one built in to the control, rather since I'm virtualizing the MCLB, the SB is a distinct control I maintain, set properties for, and respond to value change events by re-rendering the subset of data in the MCLB. This actually works very well, I've done so in many UIs over the years. The problem I'm having with this implementation is I don't know what happens to my key focus when the SB is used. Unlike my previous implementations, I have event handlers to navigate the MCLB when things like the arrow or page keys are pressed, but if the user interacts with the SB those handlers are lost because the key focus seems to just vanish into a void. After interacting with the SB I can see the key events by handling them at the VI level, but the FocusObj comes back with a NULL valued refnum (specifically a zero/NULL value, not the NotARefnum value) so I can't query it for any properties to determine if the VS has the focus. If I move the event handler to the key events arising from the SB itself, they never fire as the SB seems incapable of taking the key focus. I've tried setting the focus back to the MCLB from the value change event of the SB, but that doesn't seem to work either. I'd rather not lose my ability to navigate the MCLB after the VS is interacted with. I don't really have any code to show-- I mean if the event data is returning NULL refnums there's really nothing I can do with the event. Has anyone dealt with key focus on a scrollbar before?

Could someone please refresh my memory what the bar color on a property node indicates when it is statically linked to an interface element? For example, below I have two pane property nodes which have a black bar whereas the three linked to controls are blue: Never mind...I need to go home. It's data type. The panes are black because there is no data type. Sigh. At least it's friday.

Nice. Same CAR. That makes me feel better-- that the problem has been characterized enough such that it has been identified as the same issue in multiple requests.

Perhaps better off a conditional disable structure that way no run time check is performed? If the behavior you settle on is undesired, the user can define a symbol in their own project to revert the library behavior to the original implementation.

Out of curiosity is this security behavior documented in whatever API you used?

Ah, I see. I thought this was a design time thing, not something that's being worked into an existing implementation.

Why even use static bound data if you're essentially looking to do late binding? Seems like an ideal place to use the look-up ability of a variant here. Plus it doesn't necessarily break down the idea of scope. Keep what data you need to be late bound through that interface and anything that's off limits can stay statically bound as normal private data fields. There's of course performance issues going through the name lookup and type checking, but I don't see a way around that if you're not wanting to do bind things statically at compile time. LV2013 Code: DynamicData.zip

I've seen similar behavior. I managed to isolate a pretty simple example and sent it in with the CAR I quoted in the linked thread. Paul, I have no advice other than showing it to an AE if you can isolate the code and aren't prevented from giving it to NI. This issue has been an issue for years and the more examples NI can get, the more hope there may be of fixing the behavior.

Cheers! So apparently setting the plot area "size" forces the graph to recalculate all of its elements, but setting the "bounds" does not. So there's that. Part of me is very happy you two pointed that out. Part of me is also very sad (though not surprised) at the inconsistency.

Nope, I got nothing. Sorry. Sincerely I am, if for no other reason than selfishness: my life would be way easier if not for this behavior. One of our project's spanning a few thousand VIs has this problem with hundreds of the VIs. I've given up. Development is completely non-portable. Everything's stable as long as you're on a single machine, but otherwise we're SOL. Wish I had an answer for you, but I don't. See this discussion at the dark side. I have several arcane "best" (read: awful) practices, but even then it may very well be a crapshoot. New projects of reasonable size only come along here every few years, so I haven't had a chance to start anything sizeable up with what I've learned from that thread. The typedef thing discussed in the link may be real, it may be a red herring, I just don't know.

You would lose the linkage to the typedef. Also I'm not sure how LabVIEW would handle changing the control from a typedef to a control, it may very well mutate your constant values just as modifying the typedef would. Of course case structures completely throw a wrench in the plans I've mentioned above. Fun fun fun.

I'm on day two of dealing with LabVIEW's poor ability to make a good scalable UI. While trying to deal with automatic scaling issues I've decided to completely bypass and control my layout programmatically. Yep, apparently it's 1999 again... Anyway's today's UI issue du jour is if I set my graph size programmatically via the Plot Area Bounds property, the scales fail to expand beyond their initial size. They will get smaller, and can then grow back up to their original bounds as set in the development environment, but can never grow beyond their initial dimensions: Is there a "proper" way of setting the size of a graph control? Near as I can tell the plot area is the only writable sizing property that can be used.

What I've done in the past is open the typedef, right click on the icon to do a "find all instances", then document each constant's value with a comment (or really any means, comments are nice because you can do a #enum or something similar). Do what you need to to, then go back and double check your constants. Yes, it sucks, but I still don't trust LabVIEW as far as enums go.

Eh, it's not that bad of a bug, it just shifts the layout logic from being automatic to tediously manual. I just need to have the VIs in the subpanels adjust their layouts programmatically. Pain in the ass? Yes. Time consuming and shouldn't be necessary in modern languages? Absolutely. But not difficult.

Hi all, I'm wondering if any of you see odd behavior when trying to maximize/restore a window that contains a splitter with subpanels. Specifically if the spliter's panes are set to have minimum bounds, then filled with subpanels, some weird stuff can happen if the window is restored from a maximized state that would violate the a pane's sizing restriction. Best demonstrated in a video: https://www.dropbox.com/sc/raat2m37x1gekl7/qwvo0ldgG_ m

I'm snickering over the fact that you can mark your own post as the "best answer" to your own topic.

Darn. Probably just offloads to a third party library with no support for vxWorks-- I seem to remember someone from NI saying as much for some of the other image VIs. Hopefully it is at least available on mac/linux...

http://zone.ni.com/reference/en-XX/help/371361K-01/lvcomm/ws_imagetopng/