Preface
Welcome to Donut2. Donut grows up to the practical application. I have
resolved many problems, which involved even a bug of CString, for this year.
WTL lacks: the way to serialize application general settings, to serialize Rebar-Bands
states, to serialize Toolbar states, to ordering of ToolBar buttons, and to
load 8bit bitmap Toolbar images, and the implementation of the reliable CommandBar,
OLE-drag-drop, and Update-Command-UI. All is the foundamentals for your applications.
So I had to write many drafts for them, and I have reached and published almost
good one. Before you play your own role, check that codes.
Features
- Supports most of all Microsoft Internet Explorer supports
- Controls downloading image, running scripts and so on
- Switches active MDI child windows by Tab control
- Deters advertising popup windows
- Supports Favorite Group
- Tab control supports OLE-drag-and-drop
- Supports the loading of Favorites' order
- You can try Mozilla control
Source code guide
- ATL3.0 doesn't support
put_DLControlFlags which controls downloading images
etc, so I have Changed Atlhost.h a little. You need not to read AtlhostEx.h,
AtlifaceEx.h, AtlifaceEx.idl, and AtlifaceEx_i.c.
- Many users hope an application not use "Registry", so I wrote MtlProfile.h
for "Ini file", in which algorithms support
ATL::CRegKey, too. And you can
find functions which save and load ReBar Bands' position.
- In ExplorerMenu.h, Emulates IE's "Favorites Menu" which loads your Favorites dynamically.
- As
WTL::CCommandBarCtrl doesn't support MenuControl (Nobody finds MDI application with a command bar on rebar),
I wrote MDIMenuControl.h.
- In MtlWeb.h or MtlMisc.h you can find some utility functions. Some SHx
APIs require the infamous "Active Desktop", so I had to write some codes
instead of them.
- If a SDI application,
WTL::UpdateUI frame work is not bad. But if a MDI application, I think it useless.
So I wrote CUpdateCmdUI.h from MFC's UpdateCommandUI framework.
- If the file name is Mtlx.h, I think it reusable. If not, it's a draft header.
Problems
- While switching the active maximized MDI child window, you can take a look
at normal-sized window.
- If you activate other window before page loading is completed, then WebBrowser
control will lose a focus every page you go.
- If a link decides target frame, "Window Lock" is not effective.
- As I forcefully narrow the vertical gap of rebar in a menubar and toolbar
band, if you change the position of toolbar bands, top and bottom of toolbar
pressed buttons can't be painted.
- If IE4, then you can't load Donut. Can you fix it?
- It seems that
SetWindowText API sometimes crashes. Somebody fix it!
Warning
- Donut needs WTL3.1 and the latest SDK headers.
- Donut doesn't use C-Runtime Library(CRT) according to WTL. (But it depends
on the STL implementation. If HP's STL, it's ok. If SGI's STL, CRT required).
If you determine whether to use CRT or not, you'd better use it! I guess that
in Donut, which is not so large, the amout of code of tricks for avoidance
of CRT is now more than CRT set-up codes.
- If you build it in Release mode, the compiler would warn that Exception
is invalid, but don't care.
- Fonts of Dialog resources is "MS UI Gothic". So if you don't have this font,
it's possible the dialog layout may go mad.
- As I don't have English version of Microsoft Internet Explorer, All the
menu texts is not same as that.
- Favorite Group files are searched in the path \folder has Donut.exe\FavoriteGroup\.
Please make FavoriteGroup folder.
Comment
- Simple wrapper classes such as CWindow feel good. MFC tries to control a
life of a window and often makes trouble.
- Even if you write wrong codes, the access violation may not occur. I think
HWND is even more safe than CWnd*.
- WTL's message map is very flexible, so you can write codes much more easily
than MFC in some cases.
- CCommandBarCtrl is big one, but I think the function of displaying icons
must be separated from command bar in order to smallize a code size, because
I think many developers want only command bar.
- About WTL's rebar framework, I have some complaints.
- While developing it, I've found some bugs, you can check it out
here, where you may still find bugs.
WTL or MFC
Donut now means "Why Don't you use WTL?". Even if you do a job with WTL, you
will not think it useless, while you shares Donut source codes. WTL makes a
use of the bare functionalities of Windows APIs, which is absolutely object-oriented
(Do you believe it?). That's why WTL has the crucial advantage - the smallest
and fastest code, that I think the reason why you choose C++. Now that the new
programming paradigm is coming, you are trying to write codes in generic way:
Concept-based, Policy-based programming, that is, template magics, almost of
which VC6 can't cast. I believe WTL considerably will fit it.
Words of thanks
Special thanks to those who help me cook Donut, especially Dog-store, fub and
Nishizawa. you can find them in the source code.
