LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

~5 pixel offset in top left corner of multiscreen layout (LV2019, WIN10)

I am developing an application that:

1. will span across 3 different screens

2. must fill all parts of the screen (ie. no menus, no frames)

avictor_0-1617199318001.png

I've developed a similar application using Window 10 and LabVIEW 2010 with no issue.  After upgrading to LabVIEW 2019 (and using the same VI Window Run-Time Position settings), I end up with a frame "shift" of about 5 pixels starting from the top left corner on both the horizontal and vertical plane, which carries through all screens; essentially, the application is offset from origin (5,5) instead of (0,0).  Any attempts to offset this with settings (ie (-5,-5)) was unsuccessful.  Yet when I configure the application to start Maximized, the 5 pixel frame is gone and the window fills to the edge of the screen.

avictor_1-1617199463973.png

avictor_3-1617199573053.png

 

Any possible solutions to this problem would be greatly appreciated.  It may very well be something to do with Windows as well.

 

Thanks

0 Kudos
Message 1 of 8
(1,985 Views)

What happens if you uncheck "allow users to resize front panel"?  In theory, this eliminates borders on the front panel.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(1,935 Views)

It's a weird border.  Not a standard grey/tan border, it's actually transparent.  Here's my "Customize Window Appearance" settings:

avictor_0-1617212684781.png

 

0 Kudos
Message 3 of 8
(1,930 Views)

Dang, there's nothing I can see there that would cause the issue.  And I know you didn't just make any arbitrary changes to your FP (or the properties); I was kind of hoping that there was a change from LV 2010 to LV 2019 that would cause you to have to change some FP properties, but I guess this wasn't the case.  😞

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 8
(1,914 Views)

No I didn't.  And really, this might very well be something with Windows created a buffer around the edge of windows unless they are fully maximized.

 

Thanks for your thoughts.

0 Kudos
Message 5 of 8
(1,907 Views)

I wonder....  is it possible that someone accidentally changed the "Sticky Corner" when trying to show / hide the scroll bars?  A wrong right click menu selection on the RCM between the scroll bars would be an easy way for the origin to insidiously start sticking to the "Wrong" corner by ~5 pixels, if hide scrollbars while running is selected.

 

Do the forum a favor and post images of how to change the Sticky corner when you reply.  80% of the readers never saw the "Origin sticks to..." menu options


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 8
(1,890 Views)

So I found a soft "solution" to this issue. 

 

I adjusted the "BorderWidth" and "PaddedBorderWidth" to 0 (HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics).

0 Kudos
Message 7 of 8
(1,747 Views)

Wow, that's messy - and it shouldn't have to be that way.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 8
(1,700 Views)