How do I remove OK and Cancel from an MFC Wizard dialog app ?
Alan Silver
When I create a dialog-based app using the MFC Wizard, it puts an OK and
a Cancel button on the dialog. For a simple app (such as a calculator or
dialler) these are unnecessary.
I don't seem to be able to remove them. What I mean is, I can remove the
buttons, but their IDs remain when I open Class Wizard and I can't
delete them. The main problem with this is that if I press Return when
the app is running, it assumes I've pressed OK and closes the app !!
This happens even if another control (say an edit box) has keyboard
focus.
Any ideas on how to remove these ? Thanx for any help,
Alan
--
Alan Silver
Please remove the "furryferret" if replying by e-mail
Gregory Junker
call the superclass's OnOK handler (i.e. comment out the call to
CDialog:OnOK or whatever it is that the wizard automatically puts there for
you).
hth
greg
Alan Silver wrote in message
<1Pv6UCA+...@prestwich-smile-gemach.freeserve.co.uk>...
Gregory Junker
a calculator, it might be appropriate to make the Enter or = key the
default). This should direct the Enter keypress event to another handler.
greg
Gregory Junker wrote in message
<#pH3toDr#GA...@cppssbbsa02.microsoft.com>...
Alan Silver
<gju...@one.net> writes
>One quick and dirty way is to simply override the handler for OnOK to NOT
>call the superclass's OnOK handler (i.e. comment out the call to
>CDialog:OnOK or whatever it is that the wizard automatically puts there for
>you).
I tried this. I added handlers for both buttons, which included the
default calls to the parent app's OnOK and OnCancel methods. I then
commented out these two lines. The trouble was, I couldn't close the
app, not even with the X in the top-right corner !!
Thanx anyway
Alan Silver
<gju...@one.net> writes
>Your other option is to make some other button on the dialog the default (in
>a calculator, it might be appropriate to make the Enter or = key the
>default). This should direct the Enter keypress event to another handler.
I could not do this. I created a member variable (m_equals) of type
CButton for my equals button and then put the following :-
if (m_equals.SetFocus() == NULL)
{
AfxMessageBox("set focus failed");
}
in the OnInitDialog() method to try and set the focus. This popped up
the error message. What am I doing wrong ?
If I remove the error test, it does seem to set the focus, but as soon
as I click on any of the other controls, focus goes back to the non-
existent OK button. So even without the odd error message above this
method doesn't seem to work.
This seems such an obvious thing to do, there must be a sensible way to
do it. After all, Microsoft wrote all of their dialog apps in VC++ (as
far as I know). Maybe they don't use the MFC Wizard to set them up.
This whole this sounds like a hack to me, don't see why I can't just
delete the IDs if I don't want them, but I've given up trying to work
out why M/S did most of the things it did in VC++.
Thanx for the help
Gregory Junker
either select the control (it must be a button to be able to use the default
property) in the Dialog Editor and check the "Default Button" box, or set
the property in code (SetButtonStyle(BS_DEFPUSHBUTTON), member of CButton
class).
Incidentally, in order for this to work, you must have at least one button
on your dialog (obviously) :)
HTH
greg
Alan Silver wrote in message ...
Gregory Junker
OK button in a dialog app...you then would need to manually handle
WM_DESTROY and/or WM_CLOSE (don't have the IDE in front of me).
greg
Alan Silver wrote in message ...
>In article <#pH3toDr#GA...@cppssbbsa02.microsoft.com>, Gregory Junker
><gju...@one.net> writes
>>One quick and dirty way is to simply override the handler for OnOK to NOT
>>call the superclass's OnOK handler (i.e. comment out the call to
>>CDialog:OnOK or whatever it is that the wizard automatically puts there
for
>>you).
>
>I tried this. I added handlers for both buttons, which included the
>default calls to the parent app's OnOK and OnCancel methods. I then
>commented out these two lines. The trouble was, I couldn't close the
>app, not even with the X in the top-right corner !!
>
>Thanx anyway
>
Gregory Junker
>delete the IDs if I don't want them, but I've given up trying to work
You can...you would just likely get some "undefined identifier" errors...
This is one of the risks you take on by using automatically-generated
code....it's a "one-size-fits-all" type proposition, and you generally end
up cutting out a lot of stuff you don't need.
BTW, MS tends to do a lot of stuff from the ground up in their coding
practices...just look at some of their examples sometime. You'll find that,
for instance, the MTTTY comm-device example in the MSDN doesn't use a bit of
MFC GUI code (that I can recall)...it's all low-level message loops and
CreateWindow-type stuff. MS may use their own wizards for new projects, but
I doubt it.
greg
Krishna O'Nunes Jr.
> I tried this. I added handlers for both buttons, which included the
> default calls to the parent app's OnOK and OnCancel methods. I then
> commented out these two lines. The trouble was, I couldn't close the
> app, not even with the X in the top-right corner !!
I dont' know what you wanted in the first place (the original has
scrolled off in my reader) but keep in mind that the thing that closes a
dlg box is a call to the EndDialog function. In order to close your dlg
box you need to call this function yourself from anywhere you want. Btw,
the only difference between the default OnOK and OnCancel is that OnOK
copies data out of controls into the data members, and probably supplies
a different return code too, but that doesn't affect any functionality.)
------------------------------------------
len
if you must use email, reply to:
73 662 dot 26 51 at compuserve dot com
Alan Silver
<gju...@one.net> writes
>This is one of the risks you take on by using automatically-generated
>code....it's a "one-size-fits-all" type proposition, and you generally end
>up cutting out a lot of stuff you don't need.
If I start a "dialog-based" (and I quote) application, it obviously does
not need either an OK or Cancel button. Have a look at the utilities
supplied with Windows (phone dialer, calculator, CD player, sound
recorder, any of the games, etc etc). Can you see one with these buttons
? No, 'cos you don't need them. These buttons are for when you have a
dialog as part of another application. The MFC Wizard option for dialog-
based applications should not put these buttons on.
>
>BTW, MS tends to do a lot of stuff from the ground up in their coding
>practices...just look at some of their examples sometime. You'll find that,
>for instance, the MTTTY comm-device example in the MSDN doesn't use a bit of
>MFC GUI code (that I can recall)...it's all low-level message loops and
>CreateWindow-type stuff. MS may use their own wizards for new projects, but
>I doubt it.
Don't tell anyone, but I know a secret. My brother works for Microsoft
(yeah I don't usually admit it) and he told me that the internal opinion
of MFC is that they are rubbish. Apparently no-one inside Microsoft uses
them.
It's like MS Publisher is pushed as web page designing software, but MS
don't use it (don't blame them, it's hopeless for web pages). If they
sold us the same stuff as they used, or used the same stuff as they sold
us then things would be a lot better.
Alan Silver
<gju...@one.net> writes
>either select the control (it must be a button to be able to use the default
>property) in the Dialog Editor and check the "Default Button" box, or set
>the property in code (SetButtonStyle(BS_DEFPUSHBUTTON), member of CButton
>class).
Thanx, that worked fine.
I have long since given up trying to understand why MS have implemented
features in certain ways, or wondering if they ever actually designed
VC++ at all. I spend most of my time just trying to work out how to get
around the obvious deficiencies in the system.
Ho hum.