Thread: Disabeling buttons on the windows display

Thanks for the update. That person was actually john.c who posted the original code that you criticised as "not working":

Code:

void disableMinimizeAndMaximizeButtons(HWND hwnd)
{
    SetWindowLong(hwnd, GWL_STYLE,
        GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}

The above code is equivalent to what you found worked, if you call it like this:

Code:

disableMinimizeAndMaximizeButtons(GetConsoleWindow());

And yes, unfortunately, john.c is also the one who insulted you, but surely you can see it from his point of view now that you realised that his code works if you call it properly?

Originally Posted by Ivory348

I am unable to respond the Laserlight. So I am creating a new post to be able to do so.

I think Salem closed it hoping to preempt another squabble. Anyway, I'll merge the threads since it looks like we might be able to have a proper discussion.

Originally Posted by Ivory348

This code is flawed, I changed it to look like so:
-----------------------------------------------------

(Below is the * code . . . the corrected code)

Code:

extern void disableMinimizeAndMaximizeButtons(void)
{
    HWND hwnd;
    LONG_PTR ws;
    hwnd = GetConsoleWindow();
       SetWindowLong(hwnd, GWL_STYLE,
        GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}

No, the code that you changed it to is equivalent. Here's why:

• The extern keyword is unnecessary because function names have external linkage by default.
• Whether you call GetConsoleWindow() as an actual argument of the function, or call it to provide an initial value to a local variable within the function, it is the same: either way hwmd is set to the return value of GetConsoleWindow().
• When you're providing a non-static local variable with the return value of a function call immediately after declaring it, it is equivalent to initialising it with the return value of that function call.
• In your "corrected code", ws is unused, therefore its declaration can be deleted.

This means that your "corrected code" is equivalent to:

Code:

void disableMinimizeAndMaximizeButtons(void)
{
    HWND hwnd = GetConsoleWindow();
    SetWindowLong(hwnd, GWL_STYLE,
        GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}

This is in turn equivalent to:

Code:

void disableMinimizeAndMaximizeButtons(HWND hwnd)
{
    SetWindowLong(hwnd, GWL_STYLE,
        GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}

// ...

disableMinimizeAndMaximizeButtons(GetConsoleWindow());

except that having hwnd as a parameter is more flexible since you could call the function with a different argument.

Originally Posted by Ivory348

After making a test environment for the second time in order to try out everything that was proposed to me again, I found that the * code did in fact work.

After searching for a cause I discovered that in the original test environment there was a routine that blocked the * code from working. Who would think of the possibility of two routines biting each other?

The naughty routine is a security check, requiring a pin code to be entered. Why it is getting in the way of the * code, I have not found out yet.

Yeah, it looks like that was the key to the puzzle as to why john.c's code failed to work. You should find that if you substitute john.c's code back into your code to replace your * code, along with the correct function call, it will now work.

Originally Posted by Hodor

If you're disabling the min/max buttons to work around a bug in your program then I think this is the wrong way to go about it. Changing the UI to work around a bug makes no sense and confuses users.

What is the bug that manifests itself if the min/max buttons are there?

I am guessing that it is a console program that looks bad if the number of columns is changed.

But, it could be an poorly written GUI program that has issues with size changes.

Tim S.