Blue bar bug at the window's left side

[SilentResident]

Hello, I am a returning user of XnView Classic. I was using XnView Classic about 2 or 3 years ago but I had to uninstall it due to a blue bar bug on its window. However, yesterday I returned back to XnView Classic, which I re-installed hoping that the blue bar bug was fixed. However it was not. The blue bar bug is still in the program right now so I decided to come here and report it with the hope that it will finally get fixed.

I don't want to uninstall XnView again, but this blue bar bug is very distracting and annoying.

The bug happens only when XnView's window is maximized.

Photo 1:Here is the blue bar at the right side of XnView's maximized window:

Screenshot_001.png

Photo 2:Here is what happens if my mouse is over that blue bar at the right side: it changes to a <- -> mouse icon, indicating that the blue bar was supposed to be draggable or resizeable, however nothing happens when I actually press the blue bar with my mouse to to drag it around:

Screenshot_002.png

Photo 3: Interestingly, the Blue Bar bug occurs only when XnView's window is maximized. When the program's window isn't maximized, there is no blue bar:

Screenshot_003.png

Note 1: My operation system is Windows 10 64bit, updated with all latest patches by Microsoft, and my screen display resolution is 1360x768. The blue bar bug on XnView however happened to me both on Windows 7 (2-3 years ago) and on Windows 10 (today). So certainly the bug isn't OS-related but resolution related.
Note 2: It appears that other users too had experienced and reported the exact same bug as me. Their bug reports can be found here: http://newsgroup.xnview.com/viewtopic.php?t=31789


Because the same bug occurs to me on both XnView installations on two different OS machines, and because I dont want to drop XnView for another image viewing program out there, I am willing to stick with XnView for now and help the technical support team in identifying the bug and I will be glad to answer to any possible questions about the bug. XnView is one of the best image viewing softwares for me, but If this blue bar which has no purpose here, isn't removed, I will have no option but uninstall XnView and try another software for viewing my pictures.

[XnTriq]

Similar reports (for future reference):

This seems to be difficult to fix

It's a known issue.

• Browser in Fullscreen does not use entire screen
• Resizing window bug
• [-1.91] Problem with maximized browser window on Vista
• 1.91.6: Not full screen window in Vista
• Strange bar displaying
• XnView and Vista - 2 little things

• Strange 'effect' in fullscreen

• Calvin Hsia's WebLog (MSDN): Windows Vista Aero BorderStyle Paint problem as non Administrator
• PSPad forum: Maximalize bug (Vista, v4.5.3 -build 2262)
• Webyog Forums: Display Bug In Sqlyog

• Autodesk Community: AutoCAD 2015: Border Glitch

[xnview]

i've sent you a PM

[SilentResident]

Pierre, first of all, let me tell you that your program, XnView, is AMAZING. I love it. Except the blue bar bug.

However, something very very odd happened these days --- the blue bar was gone completely! I don't know how and why, just it is gone now. It vanished. It fixed by itself. I don't know what caused the bug to be fixed.

I just tried your beta version which you send me with this PM, and I can confirm that the blue bar bug is gone or fixed in that beta version too.


I am sorry that I am not of much help, but I am very very happy now that the bug is fixed. XnView is now perfect for me. Still I have no idea why and how the bug was fixed. I have changed nothing in the XnView's Settings Menu, so I can guarantee you that the blue bar bug wasn't fixed by tweaking the Settings Menu.

Here some screenshots as well:

Screenshot_000.png

Screenshot_001.png

[Dstruct]

Same problem here (2.44 - Windows 8.1).

[Dstruct]

Must be some weird issue with window management. When having child windows inside XnView in non-maximized state you'll see that XnView is using old (Vista or Win7?) window-controls (minimize/maximize/close buttons) and window borders (that's where the "blue" comes from):

[XnTriq]

Must be some weird issue with window management. When having child windows inside XnView in non-maximized state you'll see that XnView is using old (Vista or Win7?) window-controls (minimize/maximize/close buttons) and window borders (that's where the "blue" comes from):

Thanks for sharing your observations, Dstruct!
Let's hope this will help Pierre to find a fix.

I know this is an old post but I have spent some time and pain working the 3D border stuff out (because I needed it too) from fragments across the internet including:

Elements from Jacob Slusser's page at codeproject.com (Accessed 1st Aug'12)

So here goes:

Code: Select all

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;

namespace MDITest
{
    public static class MDIClientSupport
    {
        [DllImport("user32.dll")]
        private static extern int GetWindowLong(IntPtr hWnd, int nIndex);

        [DllImport("user32.dll")]
        private static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);

        [DllImport("user32.dll", ExactSpelling = true)]
        private static extern int SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int cx, int cy, uint uFlags);

        private const int GWL_EXSTYLE = -20;
        private const int WS_EX_CLIENTEDGE = 0x200;
        private const uint SWP_NOSIZE = 0x0001;
        private const uint SWP_NOMOVE = 0x0002;
        private const uint SWP_NOZORDER = 0x0004;
        private const uint SWP_NOREDRAW = 0x0008;
        private const uint SWP_NOACTIVATE = 0x0010;
        private const uint SWP_FRAMECHANGED = 0x0020;
        private const uint SWP_SHOWWINDOW = 0x0040;
        private const uint SWP_HIDEWINDOW = 0x0080;
        private const uint SWP_NOCOPYBITS = 0x0100;
        private const uint SWP_NOOWNERZORDER = 0x0200;
        private const uint SWP_NOSENDCHANGING = 0x0400;

        public static bool SetBevel(this Form form, bool show)
        {
            foreach (Control c in form.Controls)
            {
                MdiClient client = c as MdiClient;
                if (client != null)
                {
                    int windowLong = GetWindowLong(c.Handle, GWL_EXSTYLE);

                    if (show)
                    {
                        windowLong |= WS_EX_CLIENTEDGE;
                    }
                    else
                    {
                        windowLong &= ~WS_EX_CLIENTEDGE;
                    }

                    SetWindowLong(c.Handle, GWL_EXSTYLE, windowLong);

                    // Update the non-client area.
                    SetWindowPos(client.Handle, IntPtr.Zero, 0, 0, 0, 0,
                        SWP_NOACTIVATE | SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER |
                        SWP_NOOWNERZORDER | SWP_FRAMECHANGED);

                    return true;
                }
            }
            return false;
        }

    }
}

In the form load event call:

Code: Select all

form.SetBevel(false);

Don't forget to change the namespace and remember this is an extension method but it could be changed to be jsut a method call in another class or in you MDI parent form.

For Win10 there's no real "skinning"-tool needed - below is a little Demo,
what one can accomplish without any APIs or SubClassing in 5 Minutes:
MDITest.zip

Here a ScreenShot:


The Resizing-Border has (on Win8) the same Color as the MDI-BackGround -
(it's what's left over, after deactivating all Caption-Buttons and the Caption itself).

In case that's useful - what remains is to define a DragArea and the Dragging-Code (which would be one single API-call).

[xnview]

Same problem here (2.44 - Windows 8.1).

you don't have the problem in 2.43, right? There is some problems with my fix...

[Dstruct]

Same problem here (2.44 - Windows 8.1).

you don't have the problem in 2.43, right? There is some problems with my fix...

I'm not sure 100% but I think 2.43 didn't have this problem.

[Dstruct]

Also when XnView is maximized there is a resize mouse cursor getting displayed when hovering the mouse over the right blue border - but you can't resize anything in this case.

[xnview]

i think that i found a fix for all problem around 'blue line'

[Dstruct]

Nice!

[XnTriq]

i think that i found a fix for all problem around 'blue line'

Great news, Pierre!

[Dstruct]

Must be some weird issue with window management. When having child windows inside XnView in non-maximized state you'll see that XnView is using old (Vista or Win7?) window-controls (minimize/maximize/close buttons) and window borders (that's where the "blue" comes from):

The "blue bar" issue is fixed in 2.45 when child windows are maximized.

But this issue is still present in 2.45:

When having child windows inside XnView in non-maximized state you'll see that XnView is using old (Vista or Win7?) window-controls (minimize/maximize/close buttons) and window borders. Why that?

Zwischenablage-1.png

[xnview]

When having child windows inside XnView in non-maximized state you'll see that XnView is using old (Vista or Win7?) window-controls (minimize/maximize/close buttons) and window borders. Why that?

it's a bug of windows