LabVIEW
Single pixel (1px) border missing on LabVIEW windows in Windows 10
Solved!
@Mitch_Peplow wrote:
So what do I tell my customers who ask why the screen hasn't maximised as they requested and I have to go, well, you see, it is maximised. Makes me (and LabVIEW/NI) look like complete muppets.
First you take a seat, lean back and take a deep breath. Then you count from 1 to 10 and think about how utterly horrendous this situation must be for your customers, who I'm sure have no other problems to tackle than to get upset about a 1 pixel border.
Really, is this something you let your engines get revved up about? Is this worth any high blood pressure and heightened risk of vascular disease? It's a cosmetic bug, and as nice it is to have it fixed, your software is not working one single bit better or worse with this or without it.
NI and most other software providers only backport critical bug fixes to earlier versions, if they do it at all. It's a standard procedure in the industry.
@Mitch_Peplow wrote:
Just to make everybody aware, I have raised this question with NI support and they have confirmed that this will be fixed in LabVIEW 2021, however the fix will NOT be applied to any previous versions, so basically any version running on Windows 10 other than 2021 will have the missing border.
What a joke.
So what do I tell my customers who ask why the screen hasn't maximised as they requested and I have to go, well, you see, it is maximised. Makes me (and LabVIEW/NI) look like complete muppets.
Unless it's a showstopper, bugs usually aren't fixed in previous versions. This goes for pretty much any software that you buy.
What do you tell your customers? If they complain about it, just tell them it's an evil, soul-crushing LabVIEW bug but you're not willing to shell out $5k to fix it. Have any customers even complained? I'm guessing they haven't even noticed. It's one of those things that you can't "un-see", so I imagine some customer would bring up the topic if it was annoying enough.
BTW - it is a soul-crushing bug. 😄
@billko wrote:
@Mitch_Peplow wrote:
Just to make everybody aware, I have raised this question with NI support and they have confirmed that this will be fixed in LabVIEW 2021, however the fix will NOT be applied to any previous versions, so basically any version running on Windows 10 other than 2021 will have the missing border.
What a joke.
So what do I tell my customers who ask why the screen hasn't maximised as they requested and I have to go, well, you see, it is maximised. Makes me (and LabVIEW/NI) look like complete muppets.
Unless it's a showstopper, bugs usually aren't fixed in previous versions. This goes for pretty much any software that you buy.
What do you tell your customers? If they complain about it, just tell them it's an evil, soul-crushing LabVIEW bug but you're not willing to shell out $5k to fix it. Have any customers even complained? I'm guessing they haven't even noticed. It's one of those things that you can't "un-see", so I imagine some customer would bring up the topic if it was annoying enough.
BTW - it is a soul-crushing bug. 😄
If they complain, invent a workaround...
Search LabVIEW like a graph! 
@zou wrote:Use Windows APIs to remove this style at runtime.
Something like this:
@zou wrote:Only need to do this once at the beginning of your program.
Well, you'd need to do this for each VI you want this.
And if you close (not hide or minimize) the FP, you'd probably need to do this again (as you get a new hWnd).
I tried to change this in the LV window's class, but the style of a LVDChild returns 0, so the style is probably applied after VI's FP's are created. So, changing the class's style doesn't result in anything (or I did something wrong, of course).
You could change the VI.NativeWindow method with a FindWindow\FindWindowEx:
But LV titles can be tricky!
wiebe@CARYA wrote:
@zou wrote:Use Windows APIs to remove this style at runtime.
Something like this:
@zou wrote:Only need to do this once at the beginning of your program.
Well, you'd need to do this for each VI you want this.
And if you close (not hide or minimize) the FP, you'd probably need to do this again (as you get a new hWnd).
I tried to change this in the LV window's class, but the style of a LVDChild returns 0, so the style is probably applied after VI's FP's are created. So, changing the class's style doesn't result in anything (or I did something wrong, of course).
You could change the VI.NativeWindow method with a FindWindow\FindWindowEx:
But LV titles can be tricky!
And you have just discovered the tip of the iceberg why this is NOT a 10 minute fix. 😀
Windows styles are complicated, involved, interact with each other in difficult to evaluate ways and this even changes between Windows versions. The WS_EX_CLIENTEDGE flag affects how the border is drawn for windows who have one of the other border type flags. For borderless windows it should not have any effect, expect that it seems to somehow offset everything by 1 pixel.
So you may fix the issue of this one pixel white border with your 10 minute fix, but create half a dozen other problems in much less harmless areas.
Also Goerge's explanation that that just was added a few years ago is likely not completely right. This flag was already automatically added to
windows as far back as Windows 95 depending on how they got instantiated and with what other flags. So even if NI would never have added that before it would have been used in many cases in earlier Windows versions. Possibly Windows changed that behavior at some point by not adding it automatically anymore and the quick fix (but definitively more than 10 minutes 😁) was to add it explicitly.
