David,

IIRC, you're writing shrink wrap software. The problem with .Net is that
you can't control very easily what runtime is installed on your target
PCs. Of course they're all available for download free of charge, but
some users are reticent about installing them, or can't because of admin
rights issues. Also someone installing a new version of .net runtime can
break your program. I'm fortunate in that my company supplies both the
software and the hardware and OS on which it runs, but even we have
issues when one component relies on the latest version whereas another
component must be compatible with 1.1 etc. I know that theoretically
everything is forward/backwards/sidewards compatible, but if this were
truely the case why is there a config file with the exe which specifies
which version should be used.

But for utilities that you use in house, where you can control the
runtime environment, .Net offers a lot of already written goodies. Regex
is another example, and good db support.

David Webber wrote:
[..]

If it were included it would be easier to direct people to use it. I'm with
you on purchasing libraries. I tend to do it often, but unlike .NET (which
has a reasonable solution out of the box) MFC is lacking in this area.
Maybe not that important, but we get the question a lot here...

Tom

"David Ching" <dc> wrote in message
news:7320
[..]

"Colin Peters" <cpeters> wrote in message
news:d1_5
> David,
>
> IIRC, you're writing shrink wrap software.

Yes.

>The problem with .Net is that you can't control very easily what runtime is
>installed on your target PCs...

Yes, absolutely, but I hit problems sooner than that. I have ben selling
maintaining and improving my music software since release 1 in 1994. The
program is written in C++, and does not restrict itself to the reduced
feature set of managed C++: it uses bit fields in classes and multiple
inheritance all over the place. Trying to rewrite it wit the "windowsy
bits" in managed C++ connecting to the rest in "proper" C++ would be a
nightmare with little return for the amount of effort required.

>...
> But for utilities that you use in house, where you can control the runtime
> environment, .Net offers a lot of already written goodies. Regex is
> another example, and good db support.

Fair enough. That is probabaly what will tempt me to try it (and maybe
with C# rather than C++), if I have time for the learning curve next time I
need a new in-house utility.

Dave

> years you can't specify font properties at design time in the IDE

Actually, you can. But for the full dialog, not at control level.
And that limitation comes from the binary structure of the dialog
template in memory, not from the VS editor itself.

In order to change that you need changes in the OS itself,
and only after that you can add support in the editor
(like with all then new controls added in XP and then in Vista)

"Colin Peters" <cpeters> wrote in message
news:d1_5
> The problem with .Net is that you can't control very easily what runtime
> is installed on your target PCs. Of course they're all available for
> download free of charge, but some users are reticent about installing
> them, or can't because of admin rights issues. Also someone installing a
> new version of .net runtime can break your program.

I am using products by Xenocode (PostBuild and Application Studio ISV) to
create .exe's with virtualized environments that do not require .NET to be
installed on the systems running them. They are quite great!

-- David

"Mihai N." <nmihai_year_2000> wrote in message
news:hain
>> years you can't specify font properties at design time in the IDE
>
> Actually, you can. But for the full dialog, not at control level.
> And that limitation comes from the binary structure of the dialog
> template in memory, not from the VS editor itself.
>
> In order to change that you need changes in the OS itself,
> and only after that you can add support in the editor
> (like with all then new controls added in XP and then in Vista)
>

On the contrary, there is no reason why the MFC framework can't support
saving the selected font on a per-control basis. The extra font info can be
saved in the .rc file similar to the DESIGNINFO. Once the dialog is
created, the MFC framework can enumerate the child controls and call
SetFont() on each of them that has an overridden font.

-- David

> On the contrary, there is no reason why the MFC framework can't support
> saving the selected font on a per-control basis. The extra font info can
> be
> saved in the .rc file similar to the DESIGNINFO. Once the dialog is
> created, the MFC framework can enumerate the child controls and call
> SetFont() on each of them that has an overridden font.

There is a reason, not technical but philosophical: the controls in MFC
are the system controls. And I like it this way.

In VS 2008 SP1 is the first time (from what I know) that MFC included
"controls" that are not system controls, but custom controls.
And I am not sure if I am happy with it...
(has something to do with my general dislike for custom controls)

"Mihai N." <nmihai_year_2000> wrote in message
news:hain
> There is a reason, not technical but philosophical: the controls in MFC
> are the system controls. And I like it this way.
>
> In VS 2008 SP1 is the first time (from what I know) that MFC included
> "controls" that are not system controls, but custom controls.
> And I am not sure if I am happy with it...
> (has something to do with my general dislike for custom controls)
>

Well, even system controls have the ability to set their fonts individually
different from the font in the parent window, so I'm not sure that e.g. just
because a CButton is of class hwnd BUTTON that it makes sense to confine it
to the dialog font!

It's also not true that MFC has not included enhanced controls until SP1,
for example CCheckListbox is a derived LISTBOX control that has shipped for
many years.

Honestly, the days where MFC could skate by as being a thin wrapper around
the standard Windows controls has long ago ended. MS doesn't rev their
controls fast enough to build compelling interfaces on just the standard
Windows controls. Even Vista which has some nice controls, we are prevented
from taking advantage of since Vista is not widely adopted and any work we
do in our apps to use those Vista only controls is for naught in the more
widely deployed XP and even before. If MFC offered the control, we could
deploy it even now, instead we do not. Or rather, we use readily available
3rd party MFC controls! :-)

Thanks,
David

I agree with David. There is no reason why the thin wrapper for the
controls couldn't have functions that set up the fonts based on a resource
setting. It doesn't have to do anything custom really. There are tons of
extensions to MFC controls that do this sort of thing, but, until recently,
nothing built in. It would be nice to extend the paradigm into the IDE to
give the user easier access to the functionality that is built in to the new
controls.

Tom

"Mihai N." <nmihai_year_2000> wrote in message
news:hain
[..]

In article news:<E5EC0F91-BD16-41C8-9004-5BB7B5271626>,
David Ching wrote:
> On the contrary, there is no reason why the MFC framework can't
> support saving the selected font on a per-control basis.

Agreed.

> The extra font info can be saved in the .rc file similar to the
> DESIGNINFO.

I wouldn't do that ... Like Mihai I like the fact that the controls you
get in an MFC dialog are system controls. I also like the fact that the
vanilla resource compiler is used to build resources, and so keep some
compatibility with other tools (for other languages and from other
vendors).

However, there's no reason why the IDE shouldn't allow the programmer
to specify additional properties that can be set by wizard-generated
C++ code when the dialog is instantiated. That would only happen if the
programmer chose to override the default properties from the .rc file,
of course -- otherwise the controls will be default native control
behaviour.

> Once the dialog is created, the MFC framework can enumerate the
> child controls and call SetFont() on each of them that has an
> overridden font.

Exactly ... but I wouldn't store the information in the .rc file.

OTOH ... a dialog is a dialog ... most of the time it would be wrong to
change the fonts of controls withing the dialog on a whim. An app's
user interface should be consistent and should conform to UI design
guidelines. If a font is to be changed it should be changed on a
system-wide basis (perhaps for accessibility reasons) not just because
the programmer thought it would be "cool" to use italic labels.

It's generally an error to want to alter control fonts individually.

Cheers,
Daniel.

"Daniel James" <wastebasket> wrote in message
news:24a1
> I wouldn't do that ... Like Mihai I like the fact that the controls you
> get in an MFC dialog are system controls. I also like the fact that the
> vanilla resource compiler is used to build resources, and so keep some
> compatibility with other tools (for other languages and from other
> vendors).
>
> However, there's no reason why the IDE shouldn't allow the programmer
> to specify additional properties that can be set by wizard-generated
> C++ code when the dialog is instantiated. That would only happen if the
> programmer chose to override the default properties from the .rc file,
> of course -- otherwise the controls will be default native control
> behaviour.
>

Sure, that would work as well. I don't much care where the font info is
stored as long as it is seemless to edit and work with.


> OTOH ... a dialog is a dialog ... most of the time it would be wrong to
> change the fonts of controls withing the dialog on a whim. An app's
> user interface should be consistent and should conform to UI design
> guidelines. If a font is to be changed it should be changed on a
> system-wide basis (perhaps for accessibility reasons) not just because
> the programmer thought it would be "cool" to use italic labels.
>
> It's generally an error to want to alter control fonts individually.
>

I typically use a bold version of the default dialog font for labels and
such. That works well. In fact it's so common to do that these days, if
you don't do it, your app looks so 1990's. You know, like a default MFC
app! :-O


Thanks,
David

> Well, even system controls have the ability to set their fonts individually
> different from the font in the parent window, so I'm not sure that e.g.
> just
> because a CButton is of class hwnd BUTTON that it makes sense to confine it
> to the dialog font!

But the dialog structure is a system structure, put on screen by a
system API. A control doing its own thing inside a dialog (setting it's own
font) is in the same class as a button setting it's own background color
(moving towards owner draw/custom control).

If something like that seems usefull, then it should be in the system dialog
template, not a hack ontop of it.


> Honestly, the days where MFC could skate by as being a thin wrapper around
> the standard Windows controls has long ago ended. MS doesn't rev their
> controls fast enough to build compelling interfaces on just the standard
> Windows controls.

That's one of the points, if you want.
If MFC is unable to wrap what is offeret by the system, how can I trust it
that can do the whole thing from scratch, properly?

I did not manage yet to test for internationalization all the custom
stuff added in MFC from a 3rd party company that nobody knows.

> The extra font info can be
> saved in the .rc file similar to the DESIGNINFO.

DESIGNINFO is (as the name says) design info.
It is lost at runtime.

Something closer to what you want is DLGINIT.
And what a wonderful job this is!

The info is dumped as hex junk in the system code page.
It does not matter if the .rc file is utf-16.

Take a look here in the section about DLGINIT:
http://www.mihai-nita.net/article.php?artID=20070503a

> I typically use a bold version of the default dialog font for labels and
> such. That works well. In fact it's so common to do that these days, if
> you don't do it, your app looks so 1990's.

I have never seen such dialogs, with bold labels.
Or if I have seen them, I thought they are from the 1990's. Remember the
bitmap font used in dialogs? Was fat and looked bold.

Don't remember it?
http://toastytech.com/guis/win31regedit.gif
That is the modern look with bold fonts?

Maybe bold does work well, for English.
Not for Chinese, Japanese, Arabic, and others.

Thing is: there is a setting in control panel where I can set the fonts
I want for labels, buttons, titles, menus, etc.
The includes font family, style, size, foreground and background colors.
If I want bold, I set it there. Any aplication should respect my
preference. If not, it is crap.

Would you appreciate an application that uses an italic font size 5
throughout? Just because I think it's cool?

I agree with David. I don't care where the info is stored or instanciated
so long as it's easy enough to set in the properties in the resource editor.

Tom

"Daniel James" <wastebasket> wrote in message
news:24a1
[..]