Printable View
This code works alright. In the heat of the discussion I missed it, for which I humbly apologize. I am unable to refer this contribution to the person who made it, but do so implicitly, with many thanks attached.Code:void disableMinimizeAndMaximizeButtons(void)
{
HWND hwnd;
LONG_PTR ws;
hwnd = GetConsoleWindow();
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}
Thanks for the update. That person was actually john.c who posted the original code that you criticised as "not working":
The above code is equivalent to what you found worked, if you call it like this:Code:void disableMinimizeAndMaximizeButtons(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}
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?Code:disableMinimizeAndMaximizeButtons(GetConsoleWindow());
I am unable to respond the Laserlight. So I am creating a new post to be able to do so.
This was the code proposed:
This code is flawed, I changed it to look like so:Code:
void disableMinimizeAndMaximizeButtons(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}
-----------------------------------------------------
(Below is the * code . . . the corrected code)
The * code I tried out in the environment of an application. There it did NOT work.Code:
extern void disableMinimizeAndMaximizeButtons(void)
{
HWND hwnd;
LONG_PTR ws;
hwnd = GetConsoleWindow();
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}
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.
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.Quote:
Originally Posted by Ivory348
No, the code that you changed it to is equivalent. Here's why:Quote:
Originally Posted by Ivory348
- 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:
This is in turn equivalent to:Code:void disableMinimizeAndMaximizeButtons(void)
{
HWND hwnd = GetConsoleWindow();
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}
except that having hwnd as a parameter is more flexible since you could call the function with a different argument.Code:void disableMinimizeAndMaximizeButtons(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~(WS_MAXIMIZEBOX|WS_MINIMIZEBOX));
}
// ...
disableMinimizeAndMaximizeButtons(GetConsoleWindow());
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.Quote:
Originally Posted by Ivory348
Your final code works. I have the extern in because I have the code in a header file, having followed the instructions of how to do a header file. My word, what an exercise! Now the only thing I don't know yet how to do in C is to position the output frame in the middle of the console and to block moving it about. In C## these things are a piece of cake. The positioning can be done of course but not the fixing. Although I don't like having to do a calculating exercise to get the output frame in the center.Quote:
Originally Posted by laserlight
You don't need "extern" on a function declaration. Surely you didn't include the function's definition in a header file, right? This is the only part of the function that should be in a header file:Quote:
Originally Posted by Ivory348
Code:void disableMinimizeAndMaximizeButtons(void);
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.Quote:
Originally Posted by Hodor
But, it could be an poorly written GUI program that has issues with size changes.
Tim S.
Maximizing after minimizing produced havoc on the c-output frame of my application, on a windows console. Why that happens is not the issue, neither is the question whether disabling the maximize and minimize box is good coding practice or not. It simply is the programmer's choice. An undesired occurrence does not always imply a coding shortcoming. The max/minimizing discussion in which many have vigorously participated has come to satisfactory end. I do not wish to start it all over again. However, I do thank you for your post.Quote:
Originally Posted by stahta01