-2

I've got an MFC app on Windows 10 that has the maximize button disabled as it wasn't designed to be resized. If the program is run not as administrator/elevated then the user can minimize the window to the taskbar and then restore/maximize it like normal. However, if the app is run as administrator/elevated privileges then the window can be minimized to the taskbar but never restored/maximized.

Things I've tried:

  • Left-clicking the icon on the taskbar - nothing happens.
  • Hovering over the icon on the taskbar then hovering over the tiny preview above the icon - this shows the window but goes away as soon as you stop hovering and clicking on the small preview does nothing.
  • Enabling the maximize button and setting the NoActivate property to true - doesn't help.
  • Alt-tabbing to the application does not do anything.
  • I've inspected the app when it has this issue using spy++ 64 and I can see the messages but I'm not sure what's wrong. See below

This is the log of the successful (non-admin) minimize then maximize where the maximize attempt happened around ID 290: https://pastebin.com/kRT4ABrC

This is the log of the unsuccessful (admin) minimize then maximize where the maximize attempt happened around ID 176: https://pastebin.com/nAiXUa8p

Anyone have any ideas what is wrong? It does look like the unsuccessful log is missing a bunch of WM_ACTIVATEAPP messages, but I'm not sure what else looks off.

"code" necessary for pastebin link posts
m4gik
  • 430
  • 5
  • 27
  • 2
    A normal Win32 program shouldn't do that. Did you write the code yourself? If not, see if you can find `IsUserAnAdmin` or `Elevated` anywhere in your C++ code. Maybe the program is doing something odd when it detects that it is running in admin mode. – Barmak Shemirani Oct 05 '18 at 03:56
  • Without [mcve], trying to solve this issue from a description of symptoms only is pointless. – zett42 Oct 05 '18 at 08:37
  • What you are looking for is the default behavior. It works that way, without doing anything. Since it doesn't work for you, you have written code, that changes the default behavior. We need to see a [mcve] to help you find out, what it is. – IInspectable Oct 05 '18 at 08:58
  • @zett42 That is impossible in this situation. – m4gik Oct 05 '18 at 17:08
  • @IInspectable That is impossible in this situation. – m4gik Oct 05 '18 at 17:08
  • @BarmakShemirani Thank you for helping with some suggestions! I will try looking for those and similar concepts. I was handed this project and the problem goes back to the beginning of the repository which was a big commit that pulled code from somewhere unknown unfortunately. – m4gik Oct 05 '18 at 17:10
  • I cannot envision a situation, where producing a [mcve] were impossible. You already have a complete and verifiable example. Now strip it down to its absolute minimum. The link contains helpful information. – IInspectable Oct 05 '18 at 23:19
  • @IInspectable Since the area of the problem was unknown the amount of possible, problematic code would be way more than anyone on this site would want to go through. – m4gik Oct 06 '18 at 00:06
  • That sounds like you don't understand the word *"minimal"*. The link provides guidance on how to construct a [mcve]. – IInspectable Oct 06 '18 at 00:32
  • @IInspectable I understand the word "minimal." I don't think you understand my point in that there is a large amount of code that could be the cause of the issue. It seems as if you just want to be dismissive instead of helpful. – m4gik Oct 08 '18 at 18:26
  • The link provides strategies on significantly reducing the code necessary to illustrate the issue. It requires hard work on your part, and diligence. You do not appear to be prepared to invest either. As it stand, you have a question with 2 close-votes, and a proposed answer with 2 down-votes. That speaks a clear language. – IInspectable Oct 08 '18 at 22:05
  • @IInspectable The link was not helpful as it is just common sense. – m4gik Oct 09 '18 at 17:20
  • All the better for you, as you seemingly are no stranger to common sense. Next step: Apply it. – IInspectable Oct 09 '18 at 18:06

1 Answers1

-2

Found the issue! I searched our code for "WM" and found a few custom message handlers including one for ON_WM_MOVE (See for more info.). I still don't understand why it causes an issue, but removing it gives us the desired effect. Below is the code that was causing the issue for anyone curious. The positionPages method is custom code that may be the culprit:

void CMyDlg::OnMove(int x, int y)
{
    CDialogEx::OnMove(x, y);
    positionPages(false); // This keeps the page being displayed in the right location
}
m4gik
  • 430
  • 5
  • 27
  • 1
    How can this answer be useful for anyone? What is `WM_ON_MOVE`? What is `positionPages()`? How does this relate to the observed symptoms? – zett42 Oct 05 '18 at 19:29
  • @zett42 It gives others an idea of where to look to solve similar issues. I made a typo on the windows message. – m4gik Oct 05 '18 at 21:49
  • Still, what has the `WM_MOVE` handler to do with the observed behavior that the program doesn't restore from minimized when it is run elevated? This is not a useful answer, because it doesn't explain anything. – zett42 Oct 05 '18 at 22:01
  • @zett42 It is part of the process that is involved in restoring a minimized window to it's last position. The custom handler obviously does something to interrupt that. I don't need to explain everything that's going on to post an answer that potentially provides some use to someone in a similar situation. Feel free to blog about the inner workings of the process of restoring windows and I'll be sure to take a read. Thanks for the help! – m4gik Oct 06 '18 at 00:11