MFC & Class Wizard

I' wondering if someone could shed some light on MFC and/or the classwizard.

I don't understand why in class wizard that some functions are implemented 
as message handlers, some are virtual functions and some (such as OnOK) are 
not supported at all and I have to add them as regular member functions. Is 
it just a poor implementation of MFC that the class wizard writers were 
forced to adhere to? Or is MFC a good implementation and class wizard just 
didn't go all the way there?

Another example is that there is no way to add a variable for a radio 
control and some things like that.

Thanks.



0
Bill
9/26/2005 2:22:43 PM
vc.mfc 33608 articles. 0 followers. Follow

18 Replies
809 Views

Similar Articles

[PageSpeed] 8

Class wizard is a reasonable way to create a derived class, or add a few 
member vaiables, and possible some of the more common WM_COMMANDS, but that 
is about all it's good for.

Not something to be relied on, it's always been very flaky, and not very 
difficult to break.

The other thing to bear in mind is that MFC for the most part is just a 
glorified wrapper, and can on occasion be rather clunky, take a look at some 
of the source code and you will see what I mean.

M

"Bill" <don't want any spam> wrote in message 
news:etCHFXqwFHA.2540@TK2MSFTNGP09.phx.gbl...
> I' wondering if someone could shed some light on MFC and/or the 
> classwizard.
>
> I don't understand why in class wizard that some functions are implemented 
> as message handlers, some are virtual functions and some (such as OnOK) 
> are not supported at all and I have to add them as regular member 
> functions. Is it just a poor implementation of MFC that the class wizard 
> writers were forced to adhere to? Or is MFC a good implementation and 
> class wizard just didn't go all the way there?
>
> Another example is that there is no way to add a variable for a radio 
> control and some things like that.
>
> Thanks.
>
>
> 


0
9/26/2005 9:13:13 PM
I won't comment on the design of MFC or CW - the way things are partitioned 
often astonishes me as well.  However I don't agree that you have to add OnOK 
yourself as a regular member function or that CW does not allow you to "add a 
variable for a radio control" assuming I understand what you mean by the 
latter.  I'm assuming you want to associate an integer variable with a group 
of radio buttons such that you can set a button or determine which is set.  I 
think it's very hard to find the MS documentation that tells you how to do 
such a thing but you should be able to, as I did a couple of years ago, find 
the answers via Google Groups.  If you can't, complain here and I will 
explain.

"Bill" wrote:

> I' wondering if someone could shed some light on MFC and/or the classwizard.
> 
> I don't understand why in class wizard that some functions are implemented 
> as message handlers, some are virtual functions and some (such as OnOK) are 
> not supported at all and I have to add them as regular member functions. Is 
> it just a poor implementation of MFC that the class wizard writers were 
> forced to adhere to? Or is MFC a good implementation and class wizard just 
> didn't go all the way there?
> 
> Another example is that there is no way to add a variable for a radio 
> control and some things like that.

0
9/26/2005 10:42:06 PM
in VS.NET, OnOK is a virtual method, but due to terminal brain damage on the part of the
designer (no suprise to anyone who ever tried to use it!) you can't add virtual methods
until you've added at least one handler!  (It is clear this guy never wrote code, and one
seriously questions what might have passed as quality control on this product).

Some functions are message handlers because they respond to messages.  They are local to
your class and need not be known to a precompiled superclass.

Some functions are virtual because your version is called by the superclass, which is
precompiled.  Therefore, it has to call your method, but since a message is not involved,
it can't use the messaging system to invoke the operation (yes, OnOK is ultimately a
response to WM_COMMAND:BN_CLICKED:IDOK, but it is a bit more convoluted than that.  And
VS.NET distinguishes between the OK button click and the implicit OnOK handler, in ways
that do not seem to make sense; but few of the changes in VS.NET were improvements)

The radio button issue is the result of muddy thinking and a bullheaded persistence in
continuing to use the muddy thinking in spite of the fact that it makes no sense.  The
trick for radio buttons is to set the WS_GROUP flag for all radio buttons, create the
buttons, then remove the WS_GROUP flag.  Since this clumsy workaround avoids Microsoft's
stupid solution, it is not clear why they didn't fix this in VS.NET.  But no, excuse me,
that would have been an *improvement*, and when any improvements happened in VS.NET's
design, it appears to have been entirely accidental.  Perhaps VS.NET 2005 will break all
these so the current philosophy of "make the designer's ego trip the goal" will be
realized to its full potential.

I am tempted to post my rant, which I've been working on for several weeks as I've been
using VS.NET (we have another project that demands MFC7 features.  It is a shame that all
the MFC7 improvements are hidden behind such a crappy facade)
					joe

On Mon, 26 Sep 2005 22:22:43 +0800, "Bill" <don't want any spam> wrote:

>I' wondering if someone could shed some light on MFC and/or the classwizard.
>
>I don't understand why in class wizard that some functions are implemented 
>as message handlers, some are virtual functions and some (such as OnOK) are 
>not supported at all and I have to add them as regular member functions. Is 
>it just a poor implementation of MFC that the class wizard writers were 
>forced to adhere to? Or is MFC a good implementation and class wizard just 
>didn't go all the way there?
>
>Another example is that there is no way to add a variable for a radio 
>control and some things like that.
>
>Thanks.
>
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15973)
9/27/2005 1:14:17 AM
Joe,
The way I learned to handle radio button groups is explained here
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcresed/html/_asug_grouping_radio_button_controls_on_a_dialog_box.asp
Is this the "stupid solution" as opposed to your description of a "clumsy 
workaround?"  How does one "set the WS_GROUP flag for all radio buttons" 
before creating the buttons?
Hal

"Joseph M. Newcomer" wrote:
> The radio button issue is the result of muddy thinking and a bullheaded persistence in
> continuing to use the muddy thinking in spite of the fact that it makes no sense.  The
> trick for radio buttons is to set the WS_GROUP flag for all radio buttons, create the
> buttons, then remove the WS_GROUP flag.  Since this clumsy workaround avoids Microsoft's
> stupid solution, it is not clear why they didn't fix this in VS.NET.
0
9/27/2005 1:30:01 PM
That creates a variable for the first radio button.  My solution allows creating variables
for *every* radio button (but you have to remember to remove the WS_GROUP property once
the variables are created, because otherwise the radio buttons won't work right! That's
why I call it "clumsy").  

To set the WS_GROUP property for more than one button, the easiest way is to select all
the buttons, then go to the properties and set the Group property.  It will set it for all
the selected controls.

Microsoft's stupid solution is that you cannot use symbolic control IDs, you cannot have a
designated group with an upper/lower symbolic name (in addition to their individual
names), and you cannot create control variables for each radio button.  Given that all of
these things seem obviously useful, and they've made this consistent mistake for a decade
instead of giving us a Radio Button class, that pretty much sums up the fact that they are
not paying attention to the needs of the customers.  And that's stupid.
					joe

On Tue, 27 Sep 2005 06:30:01 -0700, hal korstead <halkorstead@discussions.microsoft.com>
wrote:

>Joe,
>The way I learned to handle radio button groups is explained here:
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcresed/html/_asug_grouping_radio_button_controls_on_a_dialog_box.asp
>Is this the "stupid solution" as opposed to your description of a "clumsy 
>workaround?"  How does one "set the WS_GROUP flag for all radio buttons" 
>before creating the buttons?
>Hal
>
>"Joseph M. Newcomer" wrote:
>> The radio button issue is the result of muddy thinking and a bullheaded persistence in
>> continuing to use the muddy thinking in spite of the fact that it makes no sense.  The
>> trick for radio buttons is to set the WS_GROUP flag for all radio buttons, create the
>> buttons, then remove the WS_GROUP flag.  Since this clumsy workaround avoids Microsoft's
>> stupid solution, it is not clear why they didn't fix this in VS.NET.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15973)
9/27/2005 2:42:55 PM
Although the MSDN solution creates a variable for the first radio button, it 
behaves as if it is a group button.  When any radio button is selected, after 
UpdateData() the variable has the value 0,1,2,... of the selected button.  If 
the variable is set to a non-negative value then the corresponding radio 
button is programatically selected.  Isn't this the functionality needed for 
a radio group in most cases?  I don't see the value of having a variable for 
every button.  I agree that this design and behavior is not nearly so nice as 
what is found in the ButtonGroup Java class but at the same time I grudgingly 
admit that I don't think it is bad as you're making it out to be. 
<ignore>Gosh, did I really defend Microsoft?</ignore>

"Joseph M. Newcomer" wrote:
> That creates a variable for the first radio button.  My solution allows
> creating variables for *every* radio button.
0
9/27/2005 5:19:07 PM
Yes, and why would I want to use UpdateData()?  Or even the operation that gets that
integer directly?  What conceivable value is 0, 1, 2, when I already had symbolic names.
Why not return the control ID? Now *that* would have made sense!

If you don't see the value of a variable for every button, fine, don't use them.  But why
prevent those of us who want them from getting them?

On Tue, 27 Sep 2005 10:19:07 -0700, hal korstead <halkorstead@discussions.microsoft.com>
wrote:

>Although the MSDN solution creates a variable for the first radio button, it 
>behaves as if it is a group button.  When any radio button is selected, after 
>UpdateData() the variable has the value 0,1,2,... of the selected button.  If 
>the variable is set to a non-negative value then the corresponding radio 
>button is programatically selected.  Isn't this the functionality needed for 
>a radio group in most cases?  I don't see the value of having a variable for 
>every button.  I agree that this design and behavior is not nearly so nice as 
>what is found in the ButtonGroup Java class but at the same time I grudgingly 
>admit that I don't think it is bad as you're making it out to be. 
><ignore>Gosh, did I really defend Microsoft?</ignore>
>
>"Joseph M. Newcomer" wrote:
>> That creates a variable for the first radio button.  My solution allows
>> creating variables for *every* radio button.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15973)
9/27/2005 7:39:19 PM
Joe,
I'm not being argumentative - I have very little experience with MFC and I'm 
just trying to understand what you're saying that I seem to be missing.  It 
seems  to me that if you want the control ID you can get it with 
GetCheckedRadioButton().  Again I think the radio button API like many other 
things in MFC has the feeling of being a kluge but I don't feel there is 
anything that I am prevented from getting.
Hal

"Joseph M. Newcomer" wrote:

> Yes, and why would I want to use UpdateData()?  Or even the operation that gets that
> integer directly?  What conceivable value is 0, 1, 2, when I already had symbolic names.
> Why not return the control ID? Now *that* would have made sense!
> 
> If you don't see the value of a variable for every button, fine, don't use them.  But why
> prevent those of us who want them from getting them?
> 
> On Tue, 27 Sep 2005 10:19:07 -0700, hal korstead <halkorstead@discussions.microsoft.com>
> wrote:
> 
> >Although the MSDN solution creates a variable for the first radio button, it 
> >behaves as if it is a group button.  When any radio button is selected, after 
> >UpdateData() the variable has the value 0,1,2,... of the selected button.  If 
> >the variable is set to a non-negative value then the corresponding radio 
> >button is programatically selected.  Isn't this the functionality needed for 
> >a radio group in most cases?  I don't see the value of having a variable for 
> >every button.  I agree that this design and behavior is not nearly so nice as 
> >what is found in the ButtonGroup Java class but at the same time I grudgingly 
> >admit that I don't think it is bad as you're making it out to be. 
> ><ignore>Gosh, did I really defend Microsoft?</ignore>
> >
> >"Joseph M. Newcomer" wrote:
> >> That creates a variable for the first radio button.  My solution allows
> >> creating variables for *every* radio button.
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm
> 
0
9/27/2005 10:42:03 PM
I'm slowly learning that MS are not software gods - more like hacks, just 
like in most companies. In all fairness, the current programmers are 
probably handcuffed by a backwards compatibility requirement that goes all 
the way back to Windows 3.1 or earlier. But this is software; there is 
little reason they couldn't add better ways to do things and leave the 
backward compatibility.

Thanks for the discussions.


"M" <ihatespam.0.a101888@spamgourmet.com> wrote in message 
news:JvZZe.1955$iW5.234@fe3.news.blueyonder.co.uk...
> Class wizard is a reasonable way to create a derived class, or add a few 
> member vaiables, and possible some of the more common WM_COMMANDS, but 
> that is about all it's good for.
>
> Not something to be relied on, it's always been very flaky, and not very 
> difficult to break.
>
> The other thing to bear in mind is that MFC for the most part is just a 
> glorified wrapper, and can on occasion be rather clunky, take a look at 
> some of the source code and you will see what I mean.
>
> M
>
> "Bill" <don't want any spam> wrote in message 
> news:etCHFXqwFHA.2540@TK2MSFTNGP09.phx.gbl...
>> I' wondering if someone could shed some light on MFC and/or the 
>> classwizard.
>>
>> I don't understand why in class wizard that some functions are 
>> implemented as message handlers, some are virtual functions and some 
>> (such as OnOK) are not supported at all and I have to add them as regular 
>> member functions. Is it just a poor implementation of MFC that the class 
>> wizard writers were forced to adhere to? Or is MFC a good implementation 
>> and class wizard just didn't go all the way there?
>>
>> Another example is that there is no way to add a variable for a radio 
>> control and some things like that.
>>
>> Thanks.
>>
>>
>>
>
> 


0
Bill
9/28/2005 1:28:56 PM
Hi Bill,

I think they are continuing to find better ways to do things and they don't 
seem to be too concerned about backward compatibility to me.  Every time I 
go to a new version I have to change a ton of stuff in my programs so ...

:o)

Tom

"Bill" <don't want any spam> wrote in message 
news:O0esVCDxFHA.2228@TK2MSFTNGP11.phx.gbl...
> I'm slowly learning that MS are not software gods - more like hacks, just 
> like in most companies. In all fairness, the current programmers are 
> probably handcuffed by a backwards compatibility requirement that goes all 
> the way back to Windows 3.1 or earlier. But this is software; there is 
> little reason they couldn't add better ways to do things and leave the 
> backward compatibility.
>
> Thanks for the discussions.
>


0
tserface (3860)
9/28/2005 1:46:09 PM
GetCheckedRadioButton works if I want to switch on a range of IDs, but if I only need to
check one control, I should be able to ask "is this control checked".  So indeed, you are
prevented from creating a variable to represent the button.  Often I only have to ask
about a single button, and I'd rather ask in terms of the button than the control ID.
				joe

On Tue, 27 Sep 2005 15:42:03 -0700, hal korstead <halkorstead@discussions.microsoft.com>
wrote:

>Joe,
>I'm not being argumentative - I have very little experience with MFC and I'm 
>just trying to understand what you're saying that I seem to be missing.  It 
>seems  to me that if you want the control ID you can get it with 
>GetCheckedRadioButton().  Again I think the radio button API like many other 
>things in MFC has the feeling of being a kluge but I don't feel there is 
>anything that I am prevented from getting.
>Hal
>
>"Joseph M. Newcomer" wrote:
>
>> Yes, and why would I want to use UpdateData()?  Or even the operation that gets that
>> integer directly?  What conceivable value is 0, 1, 2, when I already had symbolic names.
>> Why not return the control ID? Now *that* would have made sense!
>> 
>> If you don't see the value of a variable for every button, fine, don't use them.  But why
>> prevent those of us who want them from getting them?
>> 
>> On Tue, 27 Sep 2005 10:19:07 -0700, hal korstead <halkorstead@discussions.microsoft.com>
>> wrote:
>> 
>> >Although the MSDN solution creates a variable for the first radio button, it 
>> >behaves as if it is a group button.  When any radio button is selected, after 
>> >UpdateData() the variable has the value 0,1,2,... of the selected button.  If 
>> >the variable is set to a non-negative value then the corresponding radio 
>> >button is programatically selected.  Isn't this the functionality needed for 
>> >a radio group in most cases?  I don't see the value of having a variable for 
>> >every button.  I agree that this design and behavior is not nearly so nice as 
>> >what is found in the ButtonGroup Java class but at the same time I grudgingly 
>> >admit that I don't think it is bad as you're making it out to be. 
>> ><ignore>Gosh, did I really defend Microsoft?</ignore>
>> >
>> >"Joseph M. Newcomer" wrote:
>> >> That creates a variable for the first radio button.  My solution allows
>> >> creating variables for *every* radio button.
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>> 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15973)
9/28/2005 4:44:04 PM
For example: Why don't we have CFont::Create, overloaded with either a massive number of
parameters or LPLOGFONT?  Instead, we have CreateFont and CreateFontIndirect methods!  Why
do we have LPRECT parameters on methods that cannot accept NULL, instead of RECT &?
Because the API call used LPRECT, so the C++ method should use LPRECT.  And the worst of
all: if you call a superclass method with different parameters, they MAY OR MAY NOT have
any effect!  Because instead of doing the job right, they chose to call Default() and pass
the original message parameters, instead of the ones supplied (I was responsible for
getting that paragraph in every description that says if you call the base class your
parameters will be ignored; prior to that paragraph being added, they did it wrong,
undocumented.  The case arose because I had to prevent OnNcActivate from actually changing
the color of the title bar, because this was producing an annoying flicker.  So I did the
obvious: I simply called the superclass OnNcActivate with FALSE.  But it still activated!
This makes no sense whatsoever from a formal OO viewpoint, but hey, the code was smaller
by some infinitesimal amount, so This Must Be The Right Solution).  

A decent radio button class would be a big help.  Moving the About box to a separate,
*fully repluggable* module, would be a big help.  Creating a default About box that
conformed to Microsoft's own GUI guidelines would be a step in the right direction.  One
of the unfortunate features of VS.NET is that it maintained all of these fundamental
errors of design, while simply destroying the IDE.
					joe

On Wed, 28 Sep 2005 21:28:56 +0800, "Bill" <don't want any spam> wrote:

>I'm slowly learning that MS are not software gods - more like hacks, just 
>like in most companies. In all fairness, the current programmers are 
>probably handcuffed by a backwards compatibility requirement that goes all 
>the way back to Windows 3.1 or earlier. But this is software; there is 
>little reason they couldn't add better ways to do things and leave the 
>backward compatibility.
>
>Thanks for the discussions.
>
>
>"M" <ihatespam.0.a101888@spamgourmet.com> wrote in message 
>news:JvZZe.1955$iW5.234@fe3.news.blueyonder.co.uk...
>> Class wizard is a reasonable way to create a derived class, or add a few 
>> member vaiables, and possible some of the more common WM_COMMANDS, but 
>> that is about all it's good for.
>>
>> Not something to be relied on, it's always been very flaky, and not very 
>> difficult to break.
>>
>> The other thing to bear in mind is that MFC for the most part is just a 
>> glorified wrapper, and can on occasion be rather clunky, take a look at 
>> some of the source code and you will see what I mean.
>>
>> M
>>
>> "Bill" <don't want any spam> wrote in message 
>> news:etCHFXqwFHA.2540@TK2MSFTNGP09.phx.gbl...
>>> I' wondering if someone could shed some light on MFC and/or the 
>>> classwizard.
>>>
>>> I don't understand why in class wizard that some functions are 
>>> implemented as message handlers, some are virtual functions and some 
>>> (such as OnOK) are not supported at all and I have to add them as regular 
>>> member functions. Is it just a poor implementation of MFC that the class 
>>> wizard writers were forced to adhere to? Or is MFC a good implementation 
>>> and class wizard just didn't go all the way there?
>>>
>>> Another example is that there is no way to add a variable for a radio 
>>> control and some things like that.
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>> 
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15973)
9/28/2005 4:51:42 PM
On Wed, 28 Sep 2005 12:51:42 -0400, Joseph M. Newcomer wrote:

> For example: Why don't we have CFont::Create, overloaded with either a massive number of
> parameters or LPLOGFONT?  Instead, we have CreateFont and CreateFontIndirect methods!  Why
> do we have LPRECT parameters on methods that cannot accept NULL, instead of RECT &?
> Because the API call used LPRECT, so the C++ method should use LPRECT.  And the worst of
> all: if you call a superclass method with different parameters, they MAY OR MAY NOT have
> any effect!  Because instead of doing the job right, they chose to call Default() and pass
> the original message parameters, instead of the ones supplied (I was responsible for
> getting that paragraph in every description that says if you call the base class your
> parameters will be ignored; prior to that paragraph being added, they did it wrong,
> undocumented.  The case arose because I had to prevent OnNcActivate from actually changing
> the color of the title bar, because this was producing an annoying flicker.  So I did the
> obvious: I simply called the superclass OnNcActivate with FALSE.  But it still activated!
> This makes no sense whatsoever from a formal OO viewpoint, but hey, the code was smaller
> by some infinitesimal amount, so This Must Be The Right Solution).  
> 
> A decent radio button class would be a big help.  Moving the About box to a separate,
> *fully repluggable* module, would be a big help.  Creating a default About box that
> conformed to Microsoft's own GUI guidelines would be a step in the right direction.  One
> of the unfortunate features of VS.NET is that it maintained all of these fundamental
> errors of design, while simply destroying the IDE.
> 					joe
> 
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


Hey, Joe - What's your take on wxWidgets as an alternative to MFC?
0
9/28/2005 5:15:46 PM
No take.  My customers want MFC; I could not sell them something that uses any other
technology.  So instead of using quite-possibly-reasonable systems, I really have to live
with MFC, which works fine almost all the time, but when it screws up, it REALLY screws
up.  I love it 97% of the time, but that last 3% is screwed up for reasons that really
don't make any sense at all.

Then they got C# wrong by not giving us document/view.  I could move a lot of people to C#
if doc/view existed.  I actually LIKE C#, if it weren't for the brain-dead editor and IDE
I have to use to get to it.
				joe
On Wed, 28 Sep 2005 12:15:46 -0500, BobF <rNfOrSePeAzMe@charter.net> wrote:

>On Wed, 28 Sep 2005 12:51:42 -0400, Joseph M. Newcomer wrote:
>
>> For example: Why don't we have CFont::Create, overloaded with either a massive number of
>> parameters or LPLOGFONT?  Instead, we have CreateFont and CreateFontIndirect methods!  Why
>> do we have LPRECT parameters on methods that cannot accept NULL, instead of RECT &?
>> Because the API call used LPRECT, so the C++ method should use LPRECT.  And the worst of
>> all: if you call a superclass method with different parameters, they MAY OR MAY NOT have
>> any effect!  Because instead of doing the job right, they chose to call Default() and pass
>> the original message parameters, instead of the ones supplied (I was responsible for
>> getting that paragraph in every description that says if you call the base class your
>> parameters will be ignored; prior to that paragraph being added, they did it wrong,
>> undocumented.  The case arose because I had to prevent OnNcActivate from actually changing
>> the color of the title bar, because this was producing an annoying flicker.  So I did the
>> obvious: I simply called the superclass OnNcActivate with FALSE.  But it still activated!
>> This makes no sense whatsoever from a formal OO viewpoint, but hey, the code was smaller
>> by some infinitesimal amount, so This Must Be The Right Solution).  
>> 
>> A decent radio button class would be a big help.  Moving the About box to a separate,
>> *fully repluggable* module, would be a big help.  Creating a default About box that
>> conformed to Microsoft's own GUI guidelines would be a step in the right direction.  One
>> of the unfortunate features of VS.NET is that it maintained all of these fundamental
>> errors of design, while simply destroying the IDE.
>> 					joe
>> 
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
>
>Hey, Joe - What's your take on wxWidgets as an alternative to MFC?
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15973)
9/29/2005 3:57:34 AM
On Wed, 28 Sep 2005 23:57:34 -0400, Joseph M. Newcomer wrote:

> No take.  My customers want MFC; I could not sell them something that uses any other
> technology.  So instead of using quite-possibly-reasonable systems, I really have to live
> with MFC, which works fine almost all the time, but when it screws up, it REALLY screws
> up.  I love it 97% of the time, but that last 3% is screwed up for reasons that really
> don't make any sense at all.
> 
> Then they got C# wrong by not giving us document/view.  I could move a lot of people to C#
> if doc/view existed.  I actually LIKE C#, if it weren't for the brain-dead editor and IDE
> I have to use to get to it.
> 				joe

Fortunately for me, I own my code. :-)  I'm just evaluating wxWidgets
myself and was hoping for some additional perspective.  So far, its very
compelling.  Especially so considering the cross-platform capability and
its maturity.

Thanks
0
9/29/2005 1:07:09 PM
On Thu, 29 Sep 2005 08:07:09 -0500, BobF <rNfOrSePeAzMe@charter.net> wrote:

>Fortunately for me, I own my code. :-)  I'm just evaluating wxWidgets
>myself and was hoping for some additional perspective.  So far, its very
>compelling.  Especially so considering the cross-platform capability and
>its maturity.

I don't know anything about wxWidgets, but the newsreader I'm using (Forte
Agent 3) is written in terms of it. Seems to work fine, but then Agent's UI
is pretty vanilla.

-- 
Doug Harrison
VC++ MVP
0
dsh (2498)
9/29/2005 3:35:34 PM
On Thu, 29 Sep 2005 10:35:34 -0500, Doug Harrison [MVP] wrote:

> On Thu, 29 Sep 2005 08:07:09 -0500, BobF <rNfOrSePeAzMe@charter.net> wrote:
> 
>>Fortunately for me, I own my code. :-)  I'm just evaluating wxWidgets
>>myself and was hoping for some additional perspective.  So far, its very
>>compelling.  Especially so considering the cross-platform capability and
>>its maturity.
> 
> I don't know anything about wxWidgets, but the newsreader I'm using (Forte
> Agent 3) is written in terms of it. Seems to work fine, but then Agent's UI
> is pretty vanilla.

If you're interested, here are screenshots of some apps built with wx:
http://www.wxwidgets.org/screensh.htm

Here's the main site:
http://www.wxwidgets.org/

Enjoy!
0
9/29/2005 3:41:31 PM
On Thu, 29 Sep 2005 10:41:31 -0500, BobF <rNfOrSePeAzMe@charter.net> wrote:

>If you're interested, here are screenshots of some apps built with wx:
>http://www.wxwidgets.org/screensh.htm
>
>Here's the main site:
>http://www.wxwidgets.org/
>
>Enjoy!

Didn't know about Audacity, which I also use. There's a whole 'nother world
out there, I guess. :)

-- 
Doug Harrison
VC++ MVP
0
dsh (2498)
9/29/2005 3:54:06 PM
Reply:

Similar Artilces: