Switching Window to Borderless breaks in a not visible file

Question

Hey,

I implemented a function to switch from a Windowed format to a Borderless one and vice versa.
This function is executed when i press the designated button's.
If i start the application in Borderless mode and press the button for Windowed it works without any problems,
but if i then switch back to Borderless, or start the application Windowed and switch to Borderless,
it does goes Borderless, but right after that it breaks in a file which i can't view in my IDE.

Here is the code of the function which i execute on the designated button presses:

 

void ChangeWindowState(unsigned int EnableBorderless)
{
    WINDOWPLACEMENT g_wpPrev = { sizeof(g_wpPrev) };

    GetWindowPlacement(Viewer, &g_wpPrev);
    DWORD dwStyle = GetWindowLong(Viewer, GWL_STYLE);

    if ((dwStyle & WS_POPUP) && (EnableBorderless == 0))
    {
        MONITORINFO mi = { sizeof(mi) };
        if (GetMonitorInfo(MonitorFromWindow(Viewer, MONITOR_DEFAULTTOPRIMARY), &mi))
        {
            SetWindowLong(Viewer, GWL_STYLE, WS_OVERLAPPEDWINDOW | WS_VISIBLE);
            SetWindowPos(Viewer, HWND_TOP, 0, 0, 1920, 1020,SWP_FRAMECHANGED);
            UpdateWindow(Viewer);
            ShowWindow(Viewer, SW_SHOWNORMAL);
            Borderless = 0;         // Current window state "Windowed"
        }
    }
    else if((dwStyle & WS_OVERLAPPEDWINDOW) && (EnableBorderless == 1))
    {
        SetWindowLong(Viewer, GWL_STYLE, WS_POPUP | WS_VISIBLE);
        SetWindowPlacement(Viewer, &g_wpPrev);
        SetWindowPos(Viewer, HWND_TOP, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), SWP_FRAMECHANGED);
        UpdateWindow(Viewer);
        ShowWindow(Viewer, SW_SHOWMAXIMIZED);
        Borderless = 1;             // Current window state "Borderless"
    }
}

 

Answer 1

Hello IBL_Mueller,

I have tried to reproduce your application case. However, in my case no crash nor break occurred. I tried GCC (from the Build Environment) and MSVC 2012, both as libs and as source code.

According to our license DB, IBL should have access to all target relevant source code files belonging to EW so no libraries are necessary. When the error is reported in an 'unknown' file, it is probably related to a C compiler/Windows file?

Can you provide more details concerning the file and error description?

Have you made other modifications in the Build Environment? If yes, start from scratch using the original files and step by step add the modifications and then test the application.

I hope it helps you to narrow down the cause of the issue.

Best regards

Paul Banach

Comments

Hi Paul Banach,

Firstly i want to thank you for your quick answer. 

Have you made other modifications in the Build Environment? If yes, start from scratch using the original files and step by step add the modifications and then test the application.

 Yes, i have modifications in my Build Environment and while i was looking through the whole process of going Borderless and Windowed i noticed that when i go Borderless the Screen Resize Function, that my coworker gave me, signals the button press again, but only if i switch to borderless not when i switch to windowed.
So i removed the signal and now it works.
I also checked if that made any other errors, but i haven't found any yet, so it seems to me that the signal was useless.

If you want you can check the function, because it would be nice to know if you might have an answer to why that happened.
And i asked my coworker he said this function was given to him on his thread in the forums, with the goal to make a window with a dynamic size.

/* Following function has the job to adjust the size of the viewport and the
   of the root object to the values provided in the variables aWidth/aHeight. */
void EwResizeScreen(int aWidth, int aHeight, void* aFrameBuffer)
{
    XPoint size = { aWidth, aHeight };
    XRect  rect = { 0, 0, aWidth, aHeight };

    /* Each time the window is resized -> discard the old viewport ... */
    if (Viewport) EwDoneViewport(Viewport);
    Viewport = 0;

    /* ... and create a new viewport as bridge between the Windows DIB and the
       Graphics Engine bitmap represented by aFrameBuffer */
    if ((Viewport = EwInitViewport(size, rect, 0, 255, aFrameBuffer,
        0, 0, EwViewportProc)) == 0)
        EwPanic();

    /* Update all relevant variables */
    DisplayInfo.FrameBuffer = aFrameBuffer;
    DisplayInfo.DisplayWidth = aWidth;
    DisplayInfo.DisplayHeight = aHeight;
    DisplayInfo.ViewportX = 0;
    DisplayInfo.ViewportY = 0;
    DisplayInfo.ViewportWidth = aWidth;
    DisplayInfo.ViewportHeight = aHeight;
    DisplayInfo.Context = 0;

    /* update the size of the root object */
    CoreRectView__OnSetBounds(RootObject, rect);
    CoreGroup__InvalidateArea(RootObject, rect);

    /* Force immediate screen update */
    EwProcessSignals();  // THIS SIGNALS THE BUTTON PRESS AGAIN
    EwUpdate(Viewport, RootObject);
}

 

---

Hello,

yes, I remember the Resize Window thread. Why EwProcessSignals() causes the error is difficult to deduce without debugging the entire application. Possibly it causes a recursion in EwResizeScreen()?

The idea to invoke  EwProcessSignals() was to perform all update relevant signals before EwUpdate() is invoked. As far as I remember it eliminated update delays while resizing the window which looked better.

I think, you could omit EwProcessSignals(). Then the pending signals will be delivered during the next screen update. Or you implement a kind of lock to prevent ChangeWindowState() from being executed during EwResizeScreen() is performed. An if-condition with a 'lock' variable at the beginning of ChangeWindowState() could evtl. improve the behavior. The 'lock' variable is set during EwResizeScreen() is performed.

I hope it helps ...

Best regards

Paul