Opened 2 years ago

Last modified 2 years ago

#18114 confirmed defect

wxMAXIMIZE style is getting ignored by wxWidgets!

Reported by: tomay3000 Owned by:
Priority: low Milestone:
Component: wxMSW Version: 3.1.1
Keywords: wxMAXIMIZE, WS_MAXIMIZE, maximize Cc: tomay3000@…, aliket1435@…
Blocked By: Blocking:
Patch: no

Description

the wxMAXIMIZE style is getting ignored in the wxMSW port of wxWidgets.

The problem is because of the Win32 API itself ignoring WS_MAXIMIZE style.

I think wxWidgets should take care of this issue by applying the patch I am proposing.

Thank you for your understanding.

Attachments (2)

mypatch.patch download (359 bytes) - added by tomay3000 2 years ago.
minimal.patch download (509 bytes) - added by tomay3000 2 years ago.

Download all attachments as: .zip

Change History (13)

Changed 2 years ago by tomay3000

Changed 2 years ago by tomay3000

comment:1 Changed 2 years ago by tomay3000

  • Cc tomay3000@… added

This is very easy to reproduce using the attached patch to the minimal sample.

comment:2 follow-up: Changed 2 years ago by vadz

  • Priority changed from normal to low

Which MSW version do you use? For me the attached patch to the minimal sample (thanks for providing it BTW!) works just fine under Windows 7.

comment:3 in reply to: ↑ 2 Changed 2 years ago by tomay3000

  • Cc tomay3000@… removed

Replying to vadz:

Which MSW version do you use? For me the attached patch to the minimal sample (thanks for providing it BTW!) works just fine under Windows 7.

I also use Windows 7 with SP1 32-Bit.

comment:4 Changed 2 years ago by vadz

Well, my version is 64-bit, but it would be really, really weird if the behaviour differed between the 2 versions of the same system only because of this. I really don't know how to explain that it doesn't work for you, but I'm rather reluctant to apply an apparently unnecessary patch without understanding the problem.

Can anyone else reproduce it by chance?

comment:5 follow-up: Changed 2 years ago by pb101

  • Cc pbfordev@… added
  • Status changed from new to confirmed

I checked on 64-bit Windows 10 with the current master.

The window is NOT maximized when the executable is run with File Eplorer or Total Commander.

However, when the executable is run from MSVC (2017) or from the command line (cmd.exe or powershell.exe), the window IS maximized.

The obvious conclusion here would be the difference in how the application is launched, i.e., ShellExecute() vs CreateProcess(), which I confirmed with the exec sample (File/Launch File vs Exec/Sync Execution).

My uneducated guess would be that the value of n(Cmd)Show passed from ShellExecute() to WinMain() somewhat conflicts with the window setting...

comment:6 in reply to: ↑ 5 Changed 2 years ago by tomay3000

  • Cc tomay3000@… added

Replying to pb101:

I checked on 64-bit Windows 10 with the current master.

The window is NOT maximized when the executable is run with File Eplorer or Total Commander.

However, when the executable is run from MSVC (2017) or from the command line (cmd.exe or powershell.exe), the window IS maximized.

The obvious conclusion here would be the difference in how the application is launched, i.e., ShellExecute() vs CreateProcess(), which I confirmed with the exec sample (File/Launch File vs Exec/Sync Execution).

My uneducated guess would be that the value of n(Cmd)Show passed from ShellExecute() to WinMain() somewhat conflicts with the window setting...

Exactly, and sorry for not mentioning these details (which I already knew from many test I did).

I think it is a windows bug, even though if you try to reproduce it in pure Win32 API, you will get the same behavior.

the window will be guaranteed shown maximized in either case if you call:

::ShowWindow(GetHwnd(), SW_MAXIMIZE);

which is ensured by setting

m_maximizeOnShow = true;

in the top level window creation.

later or soon the developer is gonna call (wxFrame/wxDialog)::Show(); to show the window, and it will be shown maximized.

Thank you.

Last edited 2 years ago by tomay3000 (previous) (diff)

comment:7 Changed 2 years ago by vadz

Hmm, yes, you're absolutely correct, logging the value of nCmdShow shows that it's SW_SHOWDEFAULT when running the process from MSVS (as I did) or from command line, but SW_SHOWNORMAL when launching it from Explorer. This is really, really surprising because it basically means that Explorer intentionally prevents any application from starting minimized or maximized by default.

I don't know if we should override it. On one hand, we strive to behave as native programs do, but OTOH this really doesn't make much sense. OT3H you can (and, apparently, many people already do) just call Maximize() before showing the window to initially show it maximized without any flicker anyhow.

comment:8 follow-up: Changed 2 years ago by tomay3000

  • Cc tomay3000@… removed

agreed, so wxMINIMIZE is also affected when the app is launched from Windows Explorer.

wxWidgets is supposed to be CROSS-platform toolkit, so writing a cross platform application, in this case, as you say, we are supposed to call Maximize() even for wxMAC or wxGTK (and the only affected port for this problem here is wxMSW). and this is Microsoft's responsibility to fix it (no one here knows if it is intentionally or a bug!).

if a patch should be applied here, so another one should be for wxMINIMIZE too, (I haven't tested, I am just saying).

Thank you for your understanding.

comment:9 in reply to: ↑ 8 Changed 2 years ago by pb101

  • Cc pbfordev@… removed

Replying to tomay3000:

this is Microsoft's responsibility to fix it (no one here knows if it is intentionally or a bug!).

My guess would be it is intentional. As Microsoft used to say, the desktop belongs to the users, not the application. I can imagine that applications taking all available screen space can get annoying pretty quick, particularly for those with e.g. 32+" ultrawidescreen monitors. I can't think of an application I frequently use which launches in full screen. Even my movie player has a checkbox whether to launch in the full screen or not, the rest seems to either use OS defaults or store their last window position...

Moreover, how Explorer launches the executable is generally of little relevance these days. The applications are usually launched via their shortcut placed on the Desktop, in the Start menu, pinned to the Taskbar... The application's installer can set the show window property of the application shortcut, which seems to be respected by the Shell.

I have no idea what happens if the application is launched via document association (= ShellExecute()), which is the other common way of launching a program.

comment:10 Changed 2 years ago by tomay3000

  • Cc tomay3000@… added

Well, then it is up to you vadim to do what is best for the toolkit.

As a workaround for now I am using Maximize() to complete my project.

Thank you anyway for the support.

comment:11 Changed 2 years ago by AliKet

  • Cc aliket1435@… added
  • Patch unset

Hi

I can confirm this as it happened to me too (win7 32bit), and i just solved it by doing this:

void MainFrame::OnShow( wxShowEvent& event )
{
    if (!IsMaximized())
        Maximize();

    event.Skip();
}

Note: See TracTickets for help on using tickets.