LabWindows 2017 program starts full screen with menu bar not visible?

[AllenInIowa]

Now that I have seen this happen on more than one other computer, I wanted to ask: what could cause a LabWindows program to start up and go full screen (which we do in our code) but have the menu bar not visible? There is no way to get to File, Edit, etc. or even the maximize/minimize/close icons on the top right of the menu bar. That whole line is just not there.

It works 100% reliably on dozens of systems, but every now and then someone runs it on a PC and they can't see the menu bar.

[ebalci]

What happens when you open menu using keyboard shortcuts, like the ALT key or F10?

If menu pops open in that case, I would say it is a screen resolution issue.

Did you try to disable automatic resolution adjustment checkbox on the UI panel settings?

Hope this helps,

[AllenInIowa]

---

@ebalci wrote:

What happens when you open menu using keyboard shortcuts, like the ALT key or F10?

If menu pops open in that case, I would say it is a screen resolution issue.

Did you try to disable automatic resolution adjustment checkbox on the UI panel settings?

---

Web search showed us F10, the user said it did nothing. I finally had them try Win-UP and that squished the window to the top half of the screen then allowed them to access the menu bar.

Our program uses the scaling, so when they go full screen everything stretches out. This provides amusing looks when doing that on a vertical monitor 😉

I recall we saw this on another customer system, but do not remember what the solution is. Oddly, I put in code to read from an .ini file and then either maximize or not the screen. Either that is broken, or it does not work on the user's Win 11 system (works on my Win 11 system just fine) as it came up full screen regardless of that setting.

The numeric value (which is 0, or 2 ...not sure what other values do) is just passed in to this during initialization:

SetPanelAttribute (g_PanelMain, ATTR_WINDOW_ZOOM, g_WindowZoom);

[AllenInIowa]

---

@ebalci wrote:

...

If menu pops open in that case, I would say it is a screen resolution issue.

...

---

We have a winner!

Our program appears to be designed for an HD (1920x1080). That fits fine.

If Windows 10/11 is set to a Display Settings "Scale & Layout" of 125%, then the app scales up and centers on the screen. The top, left, bottom and right are all off the screen. On my dual-monitor system, I could see the left edge of the program on my left monitor, confirming the issue.

Doing Alt-M opens the top left menu, then M gets me in to Move mode where I can use the arrow keys to get the menu bar visible, and then Maximize. Then the "scale contents" in the app takes over and it fits.

Good to know. Thank you.

Now ... I need to figure out how to detect if the top left of the screen is pushed off the screen, and move the window down/right. I am still trying to wrap my head around all the dual-monitor stuff with screen coordinates.

[AllenInIowa]

A quick fix for me is to uncheck the "auto center" options for the main panel:

Now it opens in the hard-coded position (0,51) so the menu bar is visible, though the right and bottom is off the screen. That is much better.

[AllenInIowa]

For anyone else who runs into this, I "fixed" it the following way:

1. Turn on the Auto Center Horizontal/Vertical options in the panel. This makes the window pop up centered on the Primary Display.

2. Get the ATTR_TOP and ATTR_LEFT of this panel, and if it is off the screen, reposition it so the top/left is the corner of the Primary Display. I found I could get the thickness (I would have called it height) of the title bar to know where to position it.

Pseudo code looks like this:

int Top = 0;

GetPanelAttribute (g_PanelMain, ATTR_TOP, &Top);
if (Top < 0)
{
    // Top is off the top of the primary display.
    int TitleBarThickness = 0;
    // Set it down so the title bar is visible.
    GetPanelAttribute (g_PanelMain, ATTR_TITLEBAR_ACTUAL_THICKNESS, &TitleBarThickness);
    SetPanelAttribute (g_PanelMain, ATTR_TOP, TitleBarThickness);
}

int Left = 0;
GetPanelAttribute (g_PanelMain, ATTR_LEFT, &Left);
if (Left < 0)
{
    // Left is off the left of hte primary display.
    SetPanelAttribute (g_PanelMain, ATTR_LEFT, 0);
}

Now if I open on a large monitor, it auto-centers. If the monitor is too small, or the Scale factor is set so it cannot fit the normal window, it will at least be where the user can access the menubar and the title bar to move it around.

Hope it helps save someone else some frustration with this.

[BlazingProdigy]

Sounds like a tricky one! The stretching on a vertical monitor must be quite the sight. 😄 Maybe there's a subtle difference in how the .ini file is being read on their Win 11 setup compared to yours? Could also be something quirky with their scaling settings or display drivers. Debugging these cross-system inconsistencies is always an adventure! 

[AllenInIowa]

---

@BlazingProdigy wrote:

Sounds like a tricky one! The stretching on a vertical monitor must be quite the sight. 😄 Maybe there's a subtle difference in how the .ini file is being read on their Win 11 setup compared to yours? Could also be something quirky with their scaling settings or display drivers. Debugging these cross-system inconsistencies is always an adventure! 

---

This was just the Windows resolution set to 125%. Our main panel was large enough to fit on a modern display at 100%, but at 125% it was "just a bit" too large, so LabWindows places the top left off the screen. I added code to look for that and push the screen back to 0,0. Something like this:

int Top = 0;
GetPanelAttribute (panelHandle, ATTR_TOP, &Top);
if (Top < 0)
{
    // Top is off the top of the primary display.
    int TitleBarThickness = 0;
    // Set it down so the title bar is visible.
    GetPanelAttribute (panelHandle, ATTR_TITLEBAR_ACTUAL_THICKNESS, &TitleBarThickness);
    SetPanelAttribute (panelHandle, ATTR_TOP, TitleBarThickness);
}

int Left = 0;
GetPanelAttribute (panelHandle, ATTR_LEFT, &Left);
if (Left < 0)
{
    // Left is off the left of hte primary display.
    SetPanelAttribute (panelHandle, ATTR_LEFT, 0);
}

That lets me delay "really fixing" the issue

[rolfk]

Maybe you could read the actual screen resolution and size too, either using the CVI functions in the Monitors function group or directly calling Windows API functions: https://learn.microsoft.com/en-us/windows/win32/gdi/multiple-display-monitors-functions

Then you can detect how large your current screen is and adjust the panel accordingly without having overlapping areas.

[AllenInIowa]

---

@rolfk wrote:

Maybe you could read the actual screen resolution and size too, either using the CVI functions in the Monitors function group or directly calling Windows API functions: https://learn.microsoft.com/en-us/windows/win32/gdi/multiple-display-monitors-functions

Then you can detect how large your current screen is and adjust the panel accordingly without having overlapping areas.

---

One issue I had with that was knowing what was "visible". For example, I have a large monitor to the left, and it is vertical (great for long lists of code), and then the smaller laptop monitor to the right. The size returned is a HUGE thing as it covers a bunch of "invisible" space above the laptop monitor. I can have a window positioned off the screen that would be within the bounds of the "window" but completely not visible.

Do you know if there is a way to tell if a window is off the visible portion of this size?