## Gobe Software, Inc. Cole Brecheen Development Journal

### 1999-12-28 (Tue, 13:02:17)

A product configuration note, while I'm thinking of it. It's important not to rely much on an installer. It's particularly bad to rely on installation of files in scattered directories, especially system directories. A user should be able just to run the app where ever he finds it: straight off the CD, or from a network location, or in a local directory installed by a different user or under a different OS. Remember that lots of users will be dual booting Win98 and Win2000 even a couple of years from now: we shouldn't require separate installations for both.

### 1999-12-28 (Tue, 17:36:48)

The Windows resource-updating API is documented here:

http://msdn.microsoft.com/library/psdk/winui/resource_3bcj.htm
http://msdn.microsoft.com/library/psdk/winui/resource_05yr.htm
http://msdn.microsoft.com/library/psdk/winui/resource_6coj.htm
http://msdn.microsoft.com/library/psdk/winui/resource_8f3n.htm

(I've listed the pages separately because you can't navigate between them without a Java-enabled browser.)

### 1999-12-28 (Tue, 18:13:04)

I spent most of today reorganizing the BeEmulation header files to (1) straighten out a mess that was preventing resolution of exported data (be_bold_font) and (2) make a reasonable system for longer-term use. My hope is to have a clear set of rules about what to #include in different situations. Here is what it is shaping up to be. In normal application code, we will to require only one additional header to build a non-BeOS version: BeEmulation.h. In the BeEmulation library itself, we will require that header plus one more: BeEmulationPrivate.h. In app code other than GP (e.g., the HelloWorld test app), we will require BeEmulation.h and an additional #define: DEFINE_GOBE_TYPES.

### 1999-12-29 (Wed, 17:54:54)

Finally got the whole BeOS HelloWorld app to compile and link, and started work on registering a win32 window class and creating a win32 window within the emulation. Haven't yet figured out exactly where to put the main WndProc, but did figure out that BApplication::Run is going to have to do more than I've got it doing now. It's currently just running the win32 message pump, but I think it's also going to have to loop through and execute all known BLoopers. That may mean I should move the win32 message pump somewhere else.

Also simplified BeEmulation header organization a little more: eliminated the need for #define DEFINE_GOBE_TYPES by splitting a bunch of #defines out into a new GobeTypes.h.

### 1999-12-30 (Thu, 11:26:16)

I think I'm going to do the first draft of the core message handling parts of the BeEmulation DLL using a C-style wndproc, but using message crackers (see WindowsX.h) to keep it well organized and easy to maintain. After that is up and limping, it might be worth also experimenting with an MFC implementation. There is an explanation at http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_alternatives_to_the_document.2f.view_architecture.htm of how to use MFC without using its document/view architecture. Using its document/view architecture is probably out of the question -- I can't imagine how we would make GP's BWindow/BView architecture work with that.

### 2000-01-03 (Mon, 11:25:54)

This morning I'm trying to solve some stupid little problem with getting a window created. I'm getting an error 2 (FileNotFound) from GetLastError after a failed CreateWindowEx. On the theory that the file it means is the app or dll image file, I thought maybe the problem might be with using the app instance handle in code that lives in the DLL, but changing to the DLL's hModule doesn't help. Maybe the problem is with where the wndproc lives.

### 2000-01-03 (Mon, 16:17:21)

The window creation problem I was having earlier turned out to be caused by a mistake in the WndProc, which in turn was probably caused by a mistake in one of Microsoft's message-cracker macros: the WndProc has to return a non-zero value (opposite of the DefaultWindowProc) on a WM_CREATE.

### 2000-01-03 (Mon, 17:22:48)

I'm starting now to set up the view-list hierarchy associated with BWindow and BView objects. It seems pretty straightforward, although defining the exact relationship between an HWND and a BWindow and its BViews will not be. It looks like HWND functionality is split across the BWindow and BView classes, so our wndproc will need to enqueue messages both for the BWindow associated with each HWND and for the BWindow's BView children.

### 2000-01-04 (Tue, 10:15:20)

Here is the scheme I'm thinking of using for tying BWindows and BViews to HWNDs. Each BWindow will have an associated HWND, and so will its BViews. The top BView's HWND will be the same as the BWindow's. All other BViews will be associated with HWNDs that are children of the HWND for the BWindow and its top BView.

We will store a BWindow/BView pointer in each HWNDs first window-long so that wndprocs can easily find the
BeOS data associated with an HWND. To determine whether the HWND is associated with a BWindow or a BView, the wndproc will have only to ask whether the HWND is a child window. If not, the pointer is to a BWindow, through which the wndproc will be able to get associated BViews. If so, the pointer is to a BView, through which the wndproc will be able to get associated BWindows.

### 2000-01-04 (Tue, 11:38:46)

Changed my mind. Here's a scheme that will be simpler and that maps more directly to BeOS functionality. Every BWindow will have an HWND responsible for managing the window's non-client area, probably including the menu bar. We won't use the client area of the BWindow's HWND at all. Instead, we will create an HWND for each BView at the time that BView gets attached to the BWindow. This HWND will be a child of the HWND for the BWindow, and will have no non-client area. This gives us a simple one-to-one correspondence between BViews and the HWNDs we use for drawing, and between HWNDs and BWindows.

### 2000-01-05 (Wed, 09:24:38)

Just before I left last night I concluded that we would probably need to use different win32 class names for each BWindow the BeOSEmulation creates, but I neglected to write down the reason, and now I can't remember why I thought so. This is just a reminder to keep that possibility open.

### 2000-01-06 (Thu, 16:20:45)

Implemented all the ConvertToScreen/ConvertFromScreen functions for BView and BWindow as part of fixing the weird window size/placement behavior of the HelloWorld sample app. As near as I can tell, HelloWorld is working perfectly now, and has a reasonably good BWindow/BView design. Actually, now that I think of it, I'm not sure whether it's doing window_alignment (i.e., right/left/center placement of BView contents) correctly, but I don't think that's important right now. Next step is to find the simplest possible BeOS sample app that uses menus.

### 2000-01-07 (Fri, 11:39:37)

In setting up this new little MessageWorld project this morning, I had to figure out again how to set up the MSVC build environment for using BeEmulation, so I should write it down here even though it will probably change again fairly soon. It's pretty simple. In the Project Settings dialog, (1) add __INTEL__ to the "Preprocessor definitions" list, (2) check the "Ignore standard include paths" box, and (3) add "e:\GobeSource\BeEmulation,c:\bin\msvc6\vc98\include" (or whereever you keep the emulation and the VC98 include folder, respectively) to the "Additional include directories" list.

### 2000-01-07 (Fri, 12:01:09)

One more thing. To use BeEmulation in an MSVC project, you need also to add BeEmulation.lib to the list of "Object/library modules" and add "e:\GobeSource\BeEmulation\debug" (or where ever the BeEmulation.DLL happens to be) to the "Additional library path" list. Both are in the Project Settings dialog, Link panel, Input category.

### 2000-01-07 (Fri, 14:55:24)

Okay, another thing. Every project that uses BeEmulation needs to compile and link its own copy of BeEmulation/WinMain.cpp. This is just an implementation of WinMain() that turns around and calls main() after packaging up arguments, saving the HINSTANCE, and maybe a few other initialization things that will be common to all BeEmulation apps.

### 2000-01-10 (Mon, 17:10:15)

I think I'm close to having an early cut at menu-creation up and running in BeEmulation.dll. Right now I'm creating and maintaining parallel win32 and internal structures to represent the menu hierarchy, but it doesn't seem very clean; I'm still not convinced that the internal structures are really necessary, but maybe as I get farther into it I'll begin to see why. Added a bunch of basic BHandler and BLooper code today just to be able to see more clearly what else is needed. My guess is that, when I turn my attention to making menus actually communicate with the app, I'll have to get more of these classes implemented and working correctly.

### 2000-01-11 (Tue, 12:38:12)

Menu creation should be working now in this little MessageWorld sample app that I've been working on for the last couple of days, but for some reason, it's not. I thought at first that maybe the menu was just getting covered up by the BView hwnd, but that doesn't seem to be the case. It could still be that the initial size/position of the menubar is wrong, however, in any number of ways. I may also be overlooking some failure to get the menubar properly attached to the window. Still working on it.

### 2000-01-11 (Tue, 12:45:39)

Aha. I'll bet it's failure to properly handle menu-related messages in the wndproc.

### 2000-01-11 (Tue, 14:49:21)

Nope. Here's what the problem is. You can't use the win32 SetMenu to add a newly-created empty HMENU to a window and then go back and fill it up. My guess is that the window's client/non-client areas won't get resized correctly to make room for the menu if you try to set the menu while it's empty. So how am I going to make BeOS apps that aren't constrained by this ordering problem work correctly? I need to find some way to defer the win32 SetMenu until after the last BeOS AddItem.

### 2000-01-11 (Tue, 17:18:02)

Menu creation is mostly working now. Exceptions: (1) I'm not satisfied with how BSeparatorItems are being handled; (2) accelerators aren't working; (3) UTF8 characters (just ellipses so far as I know) aren't getting translated and are showing up as garbage in the menu; (4) items after the first one in the menu bar don't draw until you pass the mouse over them the first time. My guess is that we can't yet create hierarchicals, but this sample app (MessageWorld.cpp) doesn't test them, so I'm not really sure of that. I'll probably clean this up a little more before pressing on with getting communication from menus back to the app working right.

### 2000-01-12 (Wed, 11:38:46)

Okay, I have a better BMenuItem design now that cleans up the BSeparatorItem implementation. What it boils down to is just maintaining a win32 MENUITEMINFO structure in each BMenuItem that tracks its state in win32 terms. I'm going to wait until I understand BeOS keystroke handling a little better before trying to make accelerators work, and the problem with UTF8 characters is going to require some research: (1) would UTF8 handling be easier if this were a Unicode app? (2) what's the current MS line on support for Unicode/UTF8 support on Win98? So it's on to implementing menu-to-app communication. My guess is that it's going to be a win32 WM_COMMAND handler that constructs and enqueues BMessages, but I still don't have a clear idea about how to make a BHandler work smoothly.

### 2000-01-12 (Wed, 18:12:51)

Communication from menus back to the app seems to be working pretty well now. All the menus in the MessageWorld applet do what they're supposed to do -- File/New creates a new window, File/Close closes a window, and Options/Say-Hello toggles the message in the client area from "Hello World" to "Goodbye World" and back. It also maintains its checked/unchecked state correctly. I still need to work on the implementation of the Quit() function, but getting the basic implementation right won't be hard. What may be tricky is translating non-menu-generated win32 close events into BeOS close events, so that (for example) we won't have to #ifdef app code to know when the last app window has closed and it's time to exit.

### 2000-01-13 (Thu, 16:23:14)

I got just enough BMessage-send and -reply functionality implemented today to allow the MessageWorld applet to do its window counting correctly. I think the way that's working will probably hold up pretty well. I then tried to get all the window/view/app shutdown code working correctly, and wound up making a mess. I need to go back and tackle each of these pieces separately -- make sure the destructors for each one are correct and functioning before trying to get all of them to work together.

### 2000-01-14 (Fri, 11:45:14)

The crash on exit problems I was having last night turned out to have been caused by one clear mistake and one bizarre side effect of an unnecessary BList initialization. I plan to look some more at the BList side-effect when I get to a good stopping place just to make sure there isn't something worse lurking there. Right now I'm trying to get BLooper::PostMessage(B_QUIT_REQUESTED) to work correctly, and it's caused me to realize that BLooper is probably going to be more useful and important than I had thought. I've got the win32 message pump in BApplication::Run; it does pretty much the same thing as a BeOS BLooper, and I had thought that if BMessages could be dispatched directly from the win32 wndproc, maybe a full BLooper implementation wouldn't be necessary. But that's not true. We'll need it for BMessages that the app posts to itself. My thinking right now is that the win32 message pump will need also to check for BMessages in be_app->MessageQueue() and dispatch them to the correct BHandler. I'm still trying to figure out how to determine what the correct BHandler is.

### 2000-01-17 (Mon, 12:06:35)

Menu and message management is now in pretty good shape. The MessageWorld applet behaves exactly as it should, including the window-closing and quitting operations. Getting the Quit item's use of PostMessage to work correctly forced me to fix a problem in the BMessage copy constructor. Now moving on to the BasicButton applet.

### 2000-01-17 (Mon, 17:27:21)

The BasicButton applet is now building and running, but not yet creating a button. In digging into it, I found more startup and shutdown details that were missing from BeEmulation. This applet does its window creation in its implementation of BApplication::ReadyToRun, so I had to make sure that member function gets called at the right time. I'm trying to implement things like this in more or less the same way that the Be Book claims Be OS does it, so instead of just calling the app's ReadyToRun() function somewhere in the init code, I enqueue a B_READY_TO_RUN BMessage for handling in the general-purpose BMessage dispatcher that I've built into the Windows message pump.

This applet also used a different technique for posting the application B_QUIT_REQUESTED message that wasn't quite working until about an hour ago. I think the interaction between handling of WM_DESTROY and B_QUIT_REQUESTED messages is pretty much right now, but I need to go back and make sure it still works with the other sample apps I've completed.

### 2000-01-18 (Tue, 16:26:21)

I've concluded that trying to use the BApplication class in any way before the app creates its own BApplication object is a mistake -- it introduces a lot more ugliness than it prevents. So I've changed WinMain to communicate the application's command-line and HINSTANCE to BeEmulation.dll using just a couple of simple setter/getter functions. I'm now making sure all these sample apps work okay with this simpler startup/shutdown code.

### 2000-01-18 (Tue, 17:37:17)

Yes, this is a much better way to do it. Much simpler and cleaner. All sample apps now start up and shut down using only the BApplication object that is actually created by the app itself -- we no longer have a separate one that is used within the DLL before the app creates its own.

### 2000-01-19 (Wed, 17:39:02)

The BasicButton is now creating a button, and creating it in the right position. You can click on the button, but it crashes because of code in the wndproc's WM_COMMAND handler that is too specific to menu controls. I'll have to figure a cleaner way of getting information from the BeOS object to the wndproc so that it can be enqueued for dispatching to a BHandler. The Windows message-cracker macro may be getting in the way here. I need to look at whether the WM_COMMAND LPARAM argument would be more generally useful (i.e., could always pass in a pointer to the sending BeOS object) if we weren't using the message cracker in this case.

### 2000-01-20 (Thu, 10:40:29)

I think I have a good, simple design for handling different kinds of WM_COMMAND messages now: both the BButton and the BMenu classes are working with it, and the BasicButton sample applet is working correctly. The scheme is that, for every win32 object we create (control, menu, window, etc.), we store a pointer back to the corresponding BeOS object in the GWL_USERDATA window-long. We won't use any other window words, window longs, win32 atoms or whatnot to get at BeOS info from the emulation layer -- just this one consistent scheme for associating win32 and BeOS objects.

I may go ahead and try to fix a problem with the button label font before moving on from BasicButton. I'd originally thought it might be a good place to get window resizing modes working correctly, but this example just uses FOLLOW_LEFT and FOLLOW_TOP, which is regular win32 behavior. I'll probably look for another example that demonstrates resizing modes better.

### 2000-01-21 (Fri, 16:00:16)

I'm working on implementing BeOS window resizing, and just realized that I'm going to have to subclass every control that emulates a BControl. I'm trying to decide whether to use the regular BView wndproc for that, or to use a separate one -- maybe even a separate one for each subclassed control type, as we did with ClarisWorks. It shouldn't be too difficult to go either way at this point, so I think I'll try first to avoid too much separation. It made for kind of a mess with ClarisWorks.

### 2000-01-21 (Fri, 17:53:26)

Window resizing modes (B_FOLLOW_BOTTOM, B_FOLLOW_RIGHT, B_FOLLOW_ALL, etc.) are now working correctly, so next I'll move on to implementing other control types. I wound up having to separate BControlWndProc from BViewWndProc for subclassing purposes, but I don't think I'll have to have separate wndprocs for each control type. We'll know for sure within the next day or two.

### 2000-01-24 (Mon, 14:48:06)

I can't seem to find a BeOS sample app containing a real dialog, so I'm working now on a larger sample app that combines MessageWorld with BasicButton, and adds some or all of the other basic control types. While putting it together I noticed a little bug in MessageWorld -- the BView hwnd isn't handling WM_SETCURSOR messages properly. When the cursor changes into the resize arrows as it passes over the window edge, it doesn't change back to the regular system cursor when it's over the interior of the window. That shouldn't be too hard to fix -- just wanted to write it down so as not to forget it.

### 2000-01-24 (Mon, 17:37:38)

Today I took the first steps toward combining the MessageWorld and BasicButton sample apps into a new ControlWorld applet. I got it a version of MessageWorld with a button in it building and running under BeOS, and discovered that my implementations of BView::AddChild and BView::AttachedToWindow are incomplete -- they don't yet properly support nested BViews. I'm fixing that now -- the first version of the combined applet, with the nested BView (i.e., BButton that's a child of another BView) will probably be working by mid-day tomorrow.

### 2000-01-25 (Tue, 11:49:29)

I've finished making BView::AttachedToWindow recurse properly so that child views know when they're attached, and in the process resolved some Z-ordering problems between parent and child BViews -- children are now on top of parents, at least by default. So this little ControlWorld applet now appears to behave just like it does under BeOS. Under the hood, however, I have a feeling it's still not right, because the BButton's MessageReceived member function isn't getting called on button presses. Instead, the button-click message is being dispatched to the owning window's MessageReceived function. I need to add user-visible behavior to each control's BeOS message handling code so I can tell for sure I've gotten it right without having to spend time in the BeOS debugger.

### 2000-01-26 (Wed, 17:45:42)

I'm trying now to get the app's DialogNewDoc.cpp to compile so that, as I work on getting the rest of the basic BeOS control types to work, I'll be using real-world functioning code. It's a bit harder than I expected. When I first saw how tangled up this module was with the rest of the app, I thought I might as well go ahead and try to get the whole app to compile. After about an hour of heading down that path I concluded that it would be at least a week of work. It looks like the first step would be to modify the makefile to support win32 builds -- an MSVC automake project would be very tough to create and to maintain in parallel with makefiles for other platforms.

### 2000-01-27 (Thu, 12:26:05)

It looks like there are five Be headers that conflict with MS headers: headers\be\interface\Control.h, headers\be\media\Buffer.h, headers\be\support\Errors.h, headers\be\support\List.h, and headers\be\support\String.h. Normally I would deal with this by making a rule that within the app the include-file search path must always go first to Be headers and then to MS headers. That may not work here, though, because Be's String.h #includes the c-runtime string.h (differing only in case). Under Windows we need to be using the MS version of the c-runtime string.h. I'm going to experiment with fixing this by trying to add a path to the #include somehow.

### 2000-01-28 (Fri, 11:25:44)

It looks like I'm going to have to add quite a few new rules for configuring the MSVC environment to build Gobe Productive -- enough to compound the project-definition maintenance problem and make it essential to use makefiles for production builds. I'm getting very close to being able to build the app's DialogNewDoc.cpp (after going down quite a few blind alleys), but at minimum it's going to require adding all the Be header folders to the #include-file search path in exactly the right order.

Here's something else. We need to add both __INTEL__ and DEBUG to the list of predefined preprocessor symbols. (Microsoft normally defines only _DEBUG for debug builds.)

### 2000-01-28 (Fri, 17:07:58)

So I've finally gotten all of the app's headers to compile under win32. Or at least I've gotten all the ones #included by DialogNewDoc.cpp to compile, and given the amount of header tangle in this codebase, I'd guess that it's a fair percentage of the total. I've still got 48 link errors to resolve before I'll be able really to start making this new-doc dialog work, but they don't look too hard: just a bunch of BeOS things that I haven't yet gotten around to implementing, plus all the TDialog and TString member functions, and maybe a few others. While it's still reasonably fresh in my memory, I need to write down what I've done to make all this work, and a little about why I've done it.

First, I'm using the /FI (Force Include) compiler command-line switch to effectively insert StdAfx.h and BeEmulation.h at the top of every .cpp file in the app. "StdAfx.h" is an odd name, I know, but it's Microsoft's standard name for a header which encapsulates the subset of the win32 API that you plan to use -- every Windows programmer in the world will know exactly what this file is for. I've extended its normal usage a little to include conflict resolution; everything we do to resolve symbol name conflicts (both preprocessor and non-preprocessor) between win32 and BeOS headers is in StdAfx.h. BeEmulation.h defines all parts of the interface to BeEmulation.dll that aren't defined by the regular BeOS headers. It's not much at this point: just some debug stuff and a couple of accessor functions for passing information into the DLL.

Having to make the whole win32 API visible to every .cpp in the app is something I'd wanted to avoid, but if we don't do that, it won't be practical to #ifdef the BeOS headers to add win32 data, and that would make this emulation a lot more difficult to write and maintain. I did try a couple of days ago to back out some of the #ifdef'ing I've already added to the BeOS headers so as to avoid this, but quickly saw that it would be much more expensive than simply using macros in StdAfx.h to resolve all the win32/BeOS symbol name conflicts.

Second, I'm relying on an ordering of the #include-file search path that lets me resolve file-name conflicts with a simple set of rules. We always search in this order: (1) the BeEmulation folder; (2) the app folder(s); (3) the BeOS header folder(s); and (4) the win32 header folder. So, when we have to modify a BeOS header, we just put the modified copy in the BeEmulation folder so that it overrides the unmodified copy. When both win32 and BeOS use the same name (or names differing only in case) for different headers, we go ahead and let both win32 and BeOS pick up the BeOS version (because of the search order), but it all works because before #including the win32 headers we forcibly include the win32 versions of these same-named headers in StdAfx.h with a statement like this:

    #include "../include/string.h"


... which guarantees that the win32 version (which always lives in a folder named "include") is read instead of the BeOS version (which never lives in a folder named "include").

I've also had to fix a bunch of problems which triggered cascading inclusions of wrong header versions by putting #includes of same-named but non-standard headers in #ifndef _WINDOWS blocks. All of these were in the app itself, mostly in Headers.h. I had to split the debug macros out of the app's Headers.h into a new header named DebugMacros.h (which Headers.h now simply #includes) so that it could be included by the version of Table.h in BeEmulation -- I couldn't find any other way to fix all the redefinition errors you get if you try to make Table.h compile both inside and outside the app.

### 2000-01-31 (Mon, 10:16:35)

There is a fairly good MS Knowledge Base article on "Unicode Support in Windows 95 and Windows 98" at http://support.microsoft.com/support/kb/articles/Q210/3/41.ASP. Support for UTF8 under NT4 (and presumably Windows 2000) is described at http://support.microsoft.com/support/kb/articles/q175/3/92.asp. From what I can tell, there just is no support for UTF8 under Win95/Win98.

### 2000-02-01 (Tue, 15:32:35)

It seems like I'm spending an awful lot of time just dummying up UNIMPLEMENTED() member functions for BeOS classes so that I can get get things to link and run in the debugger. I think now that if I had spent a few hours writing a little tool to do this early on, it would have saved days of work. I might try to whip up something in awk tonight; it might be doable in just a couple of hours.

### 2000-02-02 (Wed, 13:15:49)

Awk is such a handy little tool. It took me about an hour to write a little awk script that does 95% of the work required in generating "UNIMPLEMENTED()" stub functions -- it's already saved several hours in whittling down the unresolved external list for the tiny little part of the app I'm trying to get running (the Document Size dialog). Here is the full source for the script:

{
# Delete the words "static" and "virtual" anywhere they appear on the line.
sub(/static/, "");
sub(/virtual/, "");

# Delete leading and trailing whitespace.
sub(/^[ \t]+/, "");
sub(/[ \t]+$/, ""); # Delete trailing semicolon. sub(/;$/, "");

# Compress multiple tabs/spaces into a single space
sub(/[\t ]+/, " ");

# If we still have something on this line ...
if (length($0) > 0) { # Parse out the member name and the return type. memberName = substr($0, match($0, /([A-Za-z0-9_\~]+)(\()/), RLENGTH); returnType = substr($0, match($0, /([A-Za-z0-9_\~]+)([ \t])([\*\&]*)/), RLENGTH); # Prefix member name with CLASSNAME:: -- you can replace it with the right class name in the editor. sub(/([A-Za-z0-9_\~]+)(\()/, "CLASSNAME::&"); print$0;
print "{"

# If the returnType is not "void" ...
if (match(returnType, /void/) == 0)
print "\t" returnType " result = 0;";

print "\tUNIMPLEMENTED(\"CLASSNAME::" memberName ")\");";

# If the returnType is not "void" ...
if (match(returnType, /void/) == 0)
print "\treturn result;"

print "}\n\n";
}
}


### 2000-02-03 (Thu, 11:15:34)

This little awk script has been a huge help; it lets me do in five minutes what used to take thirty or forty.

### 2000-02-07 (Mon, 16:58:17)

I've been struggling today with an irritating compile error: Microsoft's "error C2666: '[]' : x overloads have similar conversions." Microsoft has a poorly written and unusually defensive explanation of it at http://support.microsoft.com/support/kb/articles/Q106/3/92.asp. It happens when an operator is overloaded according to whether it is const or non-const, and the compiler has to do its own conversion of an index argument. This seems to trigger what seems to me a bug in its determination of which version of the operator to use.

Anyway, here is the scheme I'm using to deal with problems like this. First, make sure that, in both versions of the index operator, its argument type is int-length so you won't have to add type casting in all the places where the code is just using a constant with the index operator to get a const result. In places where the code needs a non-const result, you have to add type casts so as to defeat the implicit type conversion which seems to trigger the bug. This gets you past the errors with the fewest possible code changes.

### 2000-02-10 (Thu, 17:03:12)

I've checked all the BeEmulation sources into CVS under Phoenix/BeEmulation (note change of location -- it's now under the app) and am returning to the problem of getting dialog code in the app to build and work at a minimal level.

### 2000-02-14 (Mon, 10:44:14)

I've gotten everything checked into CVS now, and have verified several times that I can delete everything locally and then get back immediately into a fully productive state just by doing a full CVS checkout. I found it a little difficult at first to keep track of pending changes because CVS makes local sources writable by default -- I normally determine what I may have changed locally just by listing local sources that are writable. I tried changing the default by setting cvs_options=-r in an environment variable, but it doesn't seem to work. This, however, does work:

	CVSREAD=yes


This makes all local sources initially read-only, which is a more familiar working model for me.

### 2000-02-21 (Mon, 11:56:18)

The whole app compiles and links under Windows now. Next task: getting it to build under Scott Lindsey's makefile system so that we can create a win32 build monitor.

### 2000-02-21 (Mon, 17:44:56)

I read through the GNU Make docs today. It looks like it will be good enough to support a reasonable win32 build system, and will allow large parts of our makefiles to be cross-platform. It's excruciatingly slow, however, so we may need also to maintain an automake version of the system just for efficiency.

### 2000-02-24 (Thu, 10:41:58)

GNU Make is starting to look extremely flakey. I spent at least an hour yesterday trying to get the string substitution functions to build the include-paths list for CFLAGS. Out of any five plausible ways of using any one of these things, it appears to me that only one is likely to work. Brings back memories of the endless sea of PolyMake bugs -- not many crashers, but thousands of little things that just weren't very robust during its early years.

I'm trying now to get a very simple but very long dependency line to work. It's the list of all the .obj files that get linked into the executable, and GNU Make is being very obtuse about it. This needs to get better.

### 2000-02-28 (Mon, 17:11:55)

Okay. The makefile is working reasonably well now. The link step works okay, the browser database is getting updated, dependencies are automatically updated, useful info is left behind when the build fails but is all cleaned up when it succeeds, etc. And I've got a simple build monitor written, but not yet tested. This build monitor is a little smarter than Apple's in that it only sends mail to people who have touched files implicated in build errors.

### 2000-02-29 (Tue, 11:37:11)

I thought I'd make a quick note of this while I'm thinking about it. Pkware is using an interesting banner-ad system described here:

### 2000-03-02 (Thu, 10:44:25)

As much as I prefer makefiles over IDE-style project definitions, I have to admit that they are sometimes hard to deal with. I've just finished wasting at least two hours, probably more, trying to figure out why the Phoenix Makefile no longer works under Windows after Scott Lindsey's changes yesterday. The reason, it turns out, is that a variable named MACHINE, which we set at the top of the makefile, was getting silently reset to an unexpected value inside makefile-engine, the include for which is no longer ifdef'd out for Windows. I've changed all the win32 ifdef'ing over to use the OS variable, which should be more reliable, so things are working again, but it illustrates one of the downsides of using Makefiles.

### 2000-03-06 (Mon, 16:09:55)

Forgot about having to read resources that have the resource name tacked onto the end. Got that working today, and implemented LoadResource (which keeps resources in memory until the resource file is closed). Looks like next I have to get a minimal BPath implementation working. That's close; it shouldn't take more than another hour or so.

### 2000-03-07 (Tue, 10:35:13)

Did a very minimal BPath implementation this morning, and am now finally back into fleshing out the parts of the emulation that are most used in the app's dialog code. It looks like my next task will be to add support for finding views by name to my BView emulation.

### 2000-03-07 (Tue, 18:00:18)

I'm now into implementing BListView, and with Scott Lindsey's help just discovered an oversight in the code that maintains BWindow/BView hierarchies -- when one BView was attached to another BView which itself is already attached, the child BView's owner was not being set, although it's child BView's owners were being set correctly.

### 2000-03-09 (Thu, 10:39:15)

Still trying to get this New Doc Dialog working. I was amazed at how easy it was, actually, to get past all the resource and window/view heirarchy problems. That seems all to be working fine now (well, actually, I need to remember to get the new splash screen bitmap -- BMPm.101 -- from Scott). But the controls aren't visible in the dialog window, and I just figured out that it's because they're being created outside the window -- too high and too far to the left. I'm not yet sure why.

### 2000-03-10 (Fri, 17:45:45)

I have buttons showing up in the app's New Document dialog now. The main problem turned out to be that I had not added support for B_FOLLOW_-type tracking on resizes of BViews -- I only had it working for BWindows and their children, so it worked one level down the hierarchy, but no further.

The buttons are blank, however, and are not correctly located within the dialog window. Figuring out why we have those two problems is the next task on my list.

### 2000-03-23 (Thu, 13:14:16)

Just finished writing a little launcher applet for the BeOS 5 install CD. It has a couple of logo bitmaps and configurable button text and button actions. It's called "Launcher." I should probably check its source into CVS, but I'm not sure where.

### 2000-03-23 (Thu, 18:19:59)

I fixed a big mess in the way that HWNDs corresponding to nested BViews and controls were being maintained, and it turned out to correct all the control positioning problems I've been chasing for the last few days. Next I'll be focusing on control labels -- the buttons in the New Document dialog are still blank; seems like it shouldn't be too hard to figure out why. It may also be related to why the listbox items are blank.

### 2000-03-24 (Fri, 10:34:26)

I figured out why the New Document dialog's buttons were coming up blank -- I was setting the button's window text from the view name instead of from BControl::Label(). In the sample applets that I'd gotten to work earlier, the same string was passed into both, but Phoenix seems to economize its use of view names. My guess is that essentially the same problem is causing the list box items to be blank. I'll chase that next.

### 2000-03-28 (Tue, 15:23:46)

I'm trying to get message dispatching out of the wndprocs so that BMessages are enqueued and ultimately dispatched in the same order that they would be under BeOS, and I'm having trouble now mainting BLooper/BHandler associations. I've got BHandlers floating around that have NIL fLooper members. I've corrected two or three problems in the last couple of hours that I thought were probably causing it, but it's still happening. Hmmm.

### 2000-03-28 (Tue, 17:18:57)

Okay, it looks like BHandler are now reliably getting associated with BLoopers at the right times, but I still have a problem with BViews that don't get their NextHandlers set, for some reason. It's probably not directly related to the immediate task, which is to get BMessage dispatching promoted up into the message loop so that it all happens in just one place and in the same way that it would under BeOS, but I'm still worried that there is something fundamental missing in my BView creation code.

### 2000-03-29 (Wed, 10:04:52)

I figured out why I was seeing NIL NextHandlers for certain BViews. It turned out to be the first view at any level in the hierarchy which had this problem -- I'd just overlooked an edge case in AddChild. Now that this is fixed, buttons in the app's New Document dialog are working, because the BMessage is now getting passed up the chain of BHandlers until it gets to the right one. The BMessage is still getting dispatched from the wndproc instead of from the top level win32 message pump, however. I plan to fix that today.

### 2000-04-04 (Tue, 11:24:23)

I'm having trouble with BListView, which probably shouldn't be surprising, but it's tantalizingly close. There are several problems now. One is that the WM_PAINT handler and the WM_DRAWITEMHANDLER are getting different DCs, with different fonts selected into them, so listbox text changes its appearance when items are selected. Another is that listbox text is being drawn too far down, by about the height of a title bar; of course that suggests a window/client-area confusion, but I can't find it. I'm also not getting proper adornments around the listbox -- that's probably just some mistake in the windowstyles I'm passing into CreateWindow. And of course the listbox isn't actually working yet because I haven't implemented SetSelectionMessage, but I don't think that's going to be very hard. The wrong-DC problem seems like the most worrisome one here, so that's what I'm working on now.

### 2000-04-04 (Tue, 13:25:19)

Well here's a win32 gotcha that really sucks. As near as I can tell, it's something inside the win32 dialog manager, not in the LISTBOX control, that causes an owner-draw listbox to get WM_DRAWITEM messages. So, if you're trying to use an owner-drawn listbox outside of a regular dialog, you only get WM_DRAWITEM messages (which seem to have the right DC for the item) when the selection changes. The consequence is that you wind up drawing the item one way when the listbox first appears, and another way when the user clicks on an item inside it.

This may force me to go back and create real win32 dialogs for
BeOS windows that appear from the look-and-feel flags to be dialogs. That might be better long term -- I used to wish that we'd taken the time with ClarisWorks to use dialog windows that win32 recognized as such -- but I'm going to experiment with one more thing before biting that bullet. Maybe I can just forget about handling WM_DRAWITEMs and do all listbox drawing in the WM_PAINT handler.

How did we deal with this in ClarisWorks?

### 2000-04-04 (Tue, 18:08:26)

That approach turned out to work reasonably well, at least for drawing purposes, although the absence of a real win32 dialog may still have something to do with the remaining problems I'm having with listboxes. They do sort of work now, however. They draw okay, and you can click on a listbox item and it will ultimately get you to the right place in the code.

### 2000-04-05 (Wed, 10:33:59)

I just solved the problem I was having yesterday with win32 listboxes not getting LBN_DBLCLK messages -- I just needed to add an LBS_NOTIFY to the window styles passed into the win32 CreateWindow. So we've now got full functionality in the dialog's controls, although there are still some other problems with the dialog's general functionality. The only parts in the list, for example, are WP and GR. And we've got a bunch of aesthetic problems. We've got an assortment of off-by-one problems with the edging, for example, and even if they're fixed, the control will still look ugly and flat; it needs 3D edging. In fact, the whole dialog needs all the aesthetic stuff that we'd get for free using a real win32 dialog, so maybe I do need to investigate making that change.

### 2000-04-07 (Fri, 10:17:05)

I wrote a little code yesterday that traverses the BView hierarchy on FrameResizes looking for clipped children. It exposed part of the window-sizing problem I've been chasing for the last day or so. I had the code that adjusts BWindow bounding rectangles in its FrameResized function: a virtual. The app overrides it, so win32 and BeEmulation were getting out of synch in their understanding of BWindow sizes and positions.

It didn't clear up the problem with the New Doc dialog getting sized 20 or 30 pixels too short, however. I'm still looking for that. I'm also seeing a clear failure of the layout code to do enough horizontal resizing of a BListView parent -- maybe the scrollview. I just realized that this may be because I'm suppressing too much BScrollView behavior; I probably at least need to let it get FrameMoved and FrameResized messages.

### 2000-04-17 (Mon, 14:15:04)

BBitmap is now implemented well enough that we can accurately draw all the bitmaps in the New Document dialog. Because the app relies on being able to write directly into the BBitmap.Bits() buffer, however, we're presently maintaining a copy of each bitmap's pixel data and updating win32's copy from it just in case the BeOS copy has been modified. This may cause performance/memory-consumption problems. Looks like the solution may be to use a DIBSection so we can draw directly into the DIB, but even a DIBSection doesn't let us treat the bitmap data just as an array of bytes. Need to do some more looking.

### 2000-04-19 (Wed, 11:38:49)

I'm now trying to get document windows to create themselves, and I'm alternating between crashing in menu code and crashing in a lot of initialization code that only started executing yesterday. I'd been skipping it until yesterday because it is meant to run in a separate thread, and something relatively uninteresting down inside it has been crashing for the last month or so. The document window menu code depends on having all that initialization done, however, so I'm getting it to work now. It's gotten all the way through several times, but I've discovered in the last hour that the reason is partly because I've got an emulation error related to ownership of dispatched/invoked BMessages. I just fixed the most obvious parts of that problem, so now I'm back to crashing in initialization code.

### 2000-04-25 (Tue, 17:57:41)

The app's debug dialog is now working, although it still has a bunch of graphic defects. I'm working now on the Document Settings dialog because it contains an edit field, which ought to be fairly easy to get working. I've now gotten it to create the win32 EDIT control and to draw more or less correctly. Should be able to wrap up support for communication with the control sometime tomorrow.

### 2000-04-26 (Wed, 17:11:11)

It turned out that, to do a reasonable job of implementing BTextControl, I needed to follow the BeOS model more closely than I'd expected to. I had to implement BTextView corresponding to the EDIT control, and another hwnd for the BTextControl which, at the moment, is a STATIC control with an EDIT control as a child -- unconventional, but it seems to work. I've still got a positioning problem with the EDIT control, and I don't have any communication yet between any of these new entities, but I can now see pretty clearly how the communication will need to work. I expect to have it all done sometime tomorrow.

### 2000-05-01 (Mon, 15:22:39)

I now have the BeOS doodle applet up and running under win32, with no changes to any of the doodle code proper. Had to fix a bunch of little emulation errors to do it, and had to turn on thread-spawning. It has a relatively complex menu and event-handling structure, and that's all working, but it's not doing much drawing right now. Before I try to figure out why, I'm going to fix support for creation of invisible windows to see if it improves the appearance of the app.

### 2000-05-03 (Wed, 16:18:35)

This doodle applet is turning out to contain lots of little challenges, but all useful, so far as I can tell. It exposed an error this morning in my implementation of BView::ResizeTo, and an error yesterday in my implementation of SetTargetForMenuItems (or whatever that function is called). It has a floater, so I had to get that kind of window creation working right, and that has improved the app's functionality. I'm only just now getting into its drawing functionality, however. I'm working now on getting the bitmaps in its floater to draw correctly. They now draw just as thin little black rectangles -- wrong colors, and either the wrong height or the wrong origin in the floater, but correct horizontal placement and width. My best guess is that the height problem is a client vs window coordinate confusion somewhere, since the bitmap rects are too short by about the height of the title bar. That's what I'm chasing now.

### 2000-05-08 (Mon, 10:53:49)

Here's where I am now on support for drawing modified bitmaps. It appears that, when you create a 256-color DIB with a specified color table, Windows reorganizes the color table for some reason -- probably to get system colors into the first 16 (or is it 20?) slots. So, when you call GetDIBits later on, the pixel (i.e., color-table index) values are different, and it gives you the reordered color table.

So for the time being, at least, I'm just maintain a copy of the original bit values. If this copy is available (see below for the one case where it won't be), we always return it from BBitmap::Bits(). We synch up the win32 bitmap with this copy in two places: in SetBits, and (if we detect that the BBitmap's bit values may have been modified via a call to the BBitmap's Bits() function) in DrawBitmap. This scheme has bitmaps in the BeOS doodle applet drawing correctly now.

I'm planning to throw away our copy anytime a BView is made a child of a BBitmap for purposes of drawing into the BBitmap, but that code isn't written yet. We may be able to get away with this long term, since there may never be cases where we need to directly modify a BBitmap via its Bits() buffer after drawing into it via a child BView.

I'm moving on now to figure out while I'm getting strange LineTo failures in this doodle applet, and I'll probably implement support for clipping regions after that.

### 2000-05-08 (Mon, 12:20:57)

The strange LineTo failure turned out to be an easy one -- it was just an uninitialized PenSize() value. I'm now defaulting PenSize() to 1.0, as the Be Book says we should. I also found and fixed one of the things that been causing some of the window sizing problems in the app. It looks, however, like doodle isn't going to let me do anything meaningful with the clip region until I get some click handling in place, so I may need to go ahead and do at least some of that now. Could also implement BRegion and get it unit tested, however.

### 2000-05-09 (Tue, 10:41:26)

One of the mysteries I'm dealing with here is that, when I was doing the initial round of this bitmap work a couple of weeks ago, I couldn't make GetDIBits work with an HBITMAP created by CreateDIBitmap, but it ultimately did start working with an HBITMAP created by CreateCompatibleBitmap. That's exactly the opposite of what you would expect and what the SDK docs seem to imply about GetDIBits. So now I have a DDB that I should be able to draw into, and in fact can draw into if you judge only by the return codes of win32 drawing operations. But the bit buffer returned by GetDIBits isn't changed by any of these drawing operations. I've been tempted to experiment with a DIBSection, since that is what you're supposed to use for drawing into DIBs, but as near as I can tell (despite the odd success of GetDIBits), I'm not using a DIB.

### 2000-05-11 (Thu, 09:50:51)

I discovered yesterday afternoon that part of the problem with my draw-into-bitmap code is that you can't get anything out of the bitmap while it's still selected into a DC. Fixing that made it possible at least to get bits out of the bitmap that I'd forced into it via SetDIBits.

Now I have a theory about why I'm not able to draw into the bitmap with operations like LineTo, FillRect, etc. The more I read and pour over bitmap-related sample code, the more it appears that only two operations are actually supported on the dc into which the bitmap is selected: BitBlt and StretchBlt. My guess is that I have to create two memory DCs: one into which the bitmap will be selected, and another into which I'll draw. After the drawing is done, I'll try BitBlt'ing from the second into the first. If that doesn't work, I'm putting this aside for a while and moving on to BRegion.

### 2000-05-15 (Mon, 17:13:42)

Fixed a heap corruption today, as well as an error in maintenance of the BView/BWindow hierarchy that was happening when an attached BView was explicitly removed. I'm now trying to figure out why we always seem to create WP docs coming out of the New Document dialog -- I'd like to see whether a GR doc is drawing any better.

### 2000-05-16 (Tue, 16:51:30)

I finally got Graphics documents to create this afternoon. The problem(s) turned out to be mostly in BListView and BScrollView, and were primarily errors in BMessage creation and posting. I'm returning now to drawing problems.

### 2000-05-19 (Fri, 10:30:20)

Still can't figure out where all the bad area-fills are coming from in document windows. I've gotten the client area of doodle to draw pretty well now by adding code to BScrollView::AttachedToWindow that undoes adjustments that client code has made for menubar and scrollbar positioning -- those are outside the win32 client area, but inside the BeOS client area. I had hoped that this work would at least fix the errors around the edges of GP document windows, but no such luck.

I have some suspicions that part of the problem has to do with bad clipping regions. I'm seeing an awful lot of filling and drawing operations that aren't having any visible effect on the screen. Most of them seem to be in offscreen drawing that isn't controlled by the debug dialog's "Offscreen drawing" checkbox -- there seem to be lots of places in the app where we should be respecting that flag but aren't. But I don't think that's the whole explanation.

I think I'm going to put this investigation aside for a little while and work on a better fix for the problems we are having around the edges of document windows. Getting rid of the scrollbars that win32 is creating automatically should be a good first step.

### 2000-05-22 (Mon, 17:26:36)

Finally got the splash screen to draw correctly. The problem turned out to be that I was using BView::Bounds within code that was trying to complete the BView::AddChild process (in BView::set_owner(), to be specific). I didn't realize until I traced through it carefully that BView::Bounds wants to return win32 client coordinates, which it can't do in the normal way until the BView's win32 hwnd has been created.

### 2000-05-23 (Tue, 16:20:33)

I've fixed another half dozen or so places where BView drawing operations weren't respecting BView::HighColor and BView::LowColor, and seemingly as a result, the content area of graphics document windows are now beginning to draw. I say seemingly because I also removed a FillRect in the default implementation of BView::Draw that I now believe is unnecessary and wrong, but that may also have contributed to this improvement. I've also added code to convert BeOS patterns into win32 brushes for use in drawing operations, but it's not getting called, apparently because we are always using solid patterns in these simple drawing cases, so I don't know whether it is working correctly yet -- can't think of an easy, reliable way to unit test it.

This is a note to myself that I need to make sure the CHECK_WIN32_CALL macro is working correctly; there is something suspicious about the number of win32 api failures that have gone away since I started using that macro.

### 2000-05-25 (Thu, 10:12:49)

Finally got content areas of WP documents to draw. The problem turned out to be entirely clipping-related, and boiled down to two errors. One was just a simple mistake in BRegion::Set that was forcing a lot of regions to have zero width. The other was a difference between the win32 and BeOS models for what the clipping region looks like when there is no clipping region: the Be OS GetClippingRegion returns a valid region that describes the whole window, minus a bunch of stuff, whereas win32's GetClipRgn returns 0, meaning that there just is no clip, even though drawing is still clipped at the edge of the window, at least.

### 2000-05-26 (Fri, 13:44:21)

Jeez Louise. Build problems up the wazoo today. This last one was particularly frustrating. It turns out that parsedate.h, which I had to copy over into BeEmulation/win32 from its original (and probably bogus) location in a BeOS posix folder, had its #include in an #if __BEOS__ section, and #defined _IMPEXP_ROOT to nothing for other platforms. It took me a solid hour to figure out why I was getting link errors on the symbols defined in it.

### 2000-06-01 (Thu, 11:31:53)

After talking to Holdaway about it, I made a few changes in this new TMenuBar::InContentArea() scheme last night, rebuilt the whole app, tested it, and then checked it all in, thinking that I'd been very careful about it. This morning I found out that I missed making the BMenuBar-to-TMenuBar changes in Phoenix subfolders, and didn't see the problems because we're not yet building external parts under Windows, so I broke the BeOS build. Tom helped me get it straightened out.

So, before I plow ahead with more work on win32 drawing, I think I need to get those parts building and loading under Windows just so things like this don't happen again. I plan to start just by getting the Clock part to build, since it's so simple. If that turns out to be easy, I'll go ahead and do all the rest of the parts, get them to load when the app launches, and maybe get them to run a little bit.

### 2000-06-07 (Wed, 11:43:34)

I got bitten by a ridiculous cluster of GNU Make bugs while trying to get the makefiles working again under Windows. The following six-line makefile fails because it doesn't know how to create api.dep from an api.c in the current directory:

%.dep : %.c
@echo Making $@ from$< using a pattern rule.
-@echo TEMP is "$(TEMP)"  Under GNU make 3.79, here is what it produces:  TEMP is D:DOCUME~1COLEBR~1LOCALS~1Temp TEMP is D:\DOCUME~1\COLEBR~1\LOCALS~1\Temp  So its rule apparently is that it will treat backslashes as quoting characters unless they appear in strings enclosed by double quotes. Note that it does its best not to give you any clue that this is what it is doing, because if you allow make to do its own echo of these commands (i.e., if you remove the '@' prefix from the operation lines) the echoed strings always include the backslashes. ### 2000-07-19 (Wed, 10:41:00) Here is another abominable thing about GNU make, while I'm thinking about it. Macro names are case sensitive, which is not a bad thing in itself, but macros inherited from the environment must be written in all-caps, because this thing converts all environment variables to uppercase. This seems to be a change from earlier versions. Some change notes would certainly help. ### 2000-07-19 (Wed, 11:52:34) Okay. Here is one change in the 3.79 version of win32 GNU make that I admit (begrudgingly) is good: they seem no longer to be exec'ing through COMSPEC all the time, and so they aren't always enforcing that stupied 1024-char limit on the length of command lines. Sometimes they still do, however; haven't figured out what the rule is on that. ### 2000-07-27 (Thu, 16:50:02) God what an awful week this has been. Most everything is finally building under GNU make now, including all but two of the parts, but getting it all to work has been really tough. ### 2000-08-07 (Mon, 10:28:33) It looks like I'm about to get everything building again this morning -- about half the parts were no longer compiling or linking, but the problems were easy to fix. Only one build error in BeEmulation. None in Phoenix. I think my next step is going to be implementation of a resource-handling scheme that we can actually ship with. We'll need it anyway just to get parts working (unless Scott Lindsey did something about the problem of conflicting "resources" folder names under the app last week) so we might as well go ahead and deal with it now. Having the right resources bound into each .exe and .dll will also save us some debugging grief over the next few months. ### 2000-08-09 (Wed, 11:18:14) Parts are now sort of working -- spreadsheet documents can be created and are somewhat functional. We're running into heap corruptions in several places (bringing up the SS format dialog, for example), so I'm adding the dHEAPCHECKING flag to the debug array, as Holdaway suggested doing a month or two ago. It should make it a lot easier to find this kind of thing. ### 2000-08-09 (Wed, 15:42:05) I just got bit for the second time by the strangest GNU Make bug yet: sometimes it fails to parse headers.depend because of something mysterious in the first 50 or so lines. It happened on Monday in one of the Parts makefiles, and I discovered I could make it go away by commenting out one perfectly innocuous dependency in the first dependency list. It just now happened in the headers.depend #included by the app's Makefile, where it may be more serious. It's looking more and more like I may eventually have to start fixing bugs in GNU Make. ### 2000-08-10 (Thu, 08:58:12) It looks like we're going to have to depend on the C-runtime DLL: MSVCRT.DLL (or MSVCRTD.DLL for debug versions of the app). The reason is that it looks like it's going to be too messy to override malloc, free, etc., in DLLs that depend on the app (such as the spreadsheet part) so that they are forced to use the app's versions. I had started looking into doing this because the SS heap corruption I was struggling with yesterday turns out almost certainly to have been caused by the problem described at http://support.microsoft.com/support/kb/articles/Q190/7/99.ASP: you can't allocate memory in one copy of the C-runtime and deallocate it in another. The only disadvantage connected with using MSVCRT.DLL is that it adds a little installation complexity. It should reduce codesize with no noticeable effect on speed, and it means I can get rid of the AppAllocator and AppDeallocator callbacks that BeEmulation.dll was using to work around this problem. My guess is that it would be very difficult to use the same kind of workaround in the spreadsheet part because of how C++'s new and delete work. We can begin using the C-runtime DLL just by changing a compiler switch, so I think it's clearly the way to go. I'm not yet ready to give up on the idea of reducing our installer dependencies to zero, however -- I hate apps that don't work unless they are installed in just the right way -- so I want to investigate a scheme for tacking all of our critical DLL dependencies onto the end of the .exe so that we can split them out if we don't find them on first launch. ### 2000-08-11 (Fri, 11:42:28) The app is building again, now using libgobe and the C-runtime DLL. We can create Presentation documents for the first time. I'm thinking it may now be time to get translators building. ### 2000-08-14 (Mon, 08:11:26) Tom, Scott Lindsey, Carl, and I talked on Friday about how to get grid menus (see BMenu's B_ITEMS_IN_MATRIX) working under Windows and Linux, and ultimately how to implement the menu-bar fill control. I'm actually not sure what it's called; it's the one that has several pop-down grid menus for fill colors, gradients, patterns, etc. I don't think we reached a complete consensus on what to do about the menu-bar fill control, but we agreed that simple grid menus should be emulated using the BeOS API in BeEmulation. So I'm going to make a start on that before moving on to getting translators building. I'll see if I can get the Shapes pop-up working first. ### 2000-08-15 (Tue, 09:52:13) I'm working now on a mysterious failure to set bitmap bits correctly for the toolbar shapes popup. It seems to have something to do with copying one bitmap to another. My current theory is that I've got something wrong in a call to GetBitmapBits or SetBitmapBits -- I just found and fixed an error of this sort in a a debug-only function (CheckBitmap), so maybe there's another one somewhere else. If this doesn't pan out, I'll probably look next for DDB/DIB confusions. ### 2000-08-15 (Tue, 15:31:37) This one is really hard to find. I'm about to test the theory that our SetBits() code is not working for bitmaps of different color depths -- i.e., that you can't call one bitmap's Bits() function and pass the result to the SetBits() of another one unless they have identical bit depths. Along the way, however, I've corrected several small errors in BBitmap, so the time hasn't been completely wasted. ### 2000-08-16 (Wed, 16:39:11) What a nightmare this bitmap stuff is. It seems like the more errors -- clear, unmistakeable errors -- that I fix, the worse they draw. But I've found one step that I think is definitely worth taking. Since DIBs are generally more manageable than DDBs, and in particular since they are friendlier to drawing operations now that we have this DIBSection thing, I'm going to start creating all BBitmaps as DIBs if the have a pixel depth greater than 8 or if they have the B_BITMAP_ACCEPTS_VIEWS flag. Plain old 8-bit bitmaps need to remain DDBs because DIBs are so much slower to draw. ### 2000-08-22 (Tue, 11:41:30) Grid menus (i.e., BMenus with the B_ITEMS_IN_MATRIX flag set) are now working at a minimum level under Windows. The main problem turned out to be in getting correct implementations of BMenu::Show and BMenu::Hide. I had secondary problems in RemoveChild -- wound up completely rewriting it -- and in the BWindow constructors and destructor -- we weren't deleting BWindows created offscreen for purposes of drawing into bitmaps, and it was making it really hard to see other problems where failure to delete BWindows was involved. That's all cleaned up now. So now, I still need to fix the background color problem with these bitmaps that are drawn offscreen, and I've got a few other little bugs and aesthetic issues to deal with. And then it's on to the more complicated grid menus -- fill color, fill pattern, etc. Those involve tear-off and a much more complicated mouse-tracking system. ### 2000-08-24 (Thu, 11:48:42) ### 2000-08-25 (Fri, 18:45:00) It turned out that grid menus weren't working quite as well as I'd thought. My earlier #ifdef'ing-out of Tom's asserts related to BMenu window ownership was masking lots of little problems in the way AddChild and RemoveChild were working with BMenus. Pulled Scott Lindsey in to help with some of those; he suggested doing a RemoveChild at the end of BMenu::Track to disconnect a grid menu from its artificial BMenuBarWindow owner. That helped a lot, and so most of those problems are gone now at the BeOS level. Now, however, I have to find a way to deal with them at the win32 level -- have to be able to disconnect and reconnect a child window from its parent without otherwise changing its state. ### 2000-08-28 (Mon, 10:45:00) Had good luck with the problem of disconnecting and then reconnecting a win32 child window from its parent: GetParent() and SetParent() do exactly what I need. I can now track through the fill control with all of its different kinds of menus appearing and disappearing, and with none of the mysterious win32 "invalid DC" errors I was getting before I had the parent/child disconnect/reconnect code working. Now I have to tackle some problems related to terminating and restarting the whole fill-control. ### 2000-08-29 (Tue, 11:07:58) Okay. I think all the tracking and entry/exit problems with this god-awful fill control are taken care of now. The entry/exit problems turned out to be primarily timing-related. For example, if you clicked outside a tracked grid menu at just the right time, the wndproc would see the click before the tracking loop would see it, which meant that a win32 window activation event would happen, causing the win32 menu to drop behind the document window. Dealt with that just by making sure the BMenu::Track terminates on activation changes. Now. If I could just get the damn things to draw .... ### 2000-08-29 (Tue, 16:53:54) The god-awful fill color/ink control is finally working pretty well under Windows. It draws correctly (except for gradients -- need a StretchBlt implementation of DrawBitmap for that), and all the tracking entry/exit behavior seems to be correct. I'll probably get gradients drawing next just so it will be cosmetically complete -- I doubt that will take more than a few hours. Then I'll need to implement tear-off support. That will probably take a couple of days. ### 2000-09-06 (Wed, 09:25:44) Yesterday I got all the translators building under Windows. I still need to modify upddlls.bat so that they get copied into the right location after a build, and of course ultimately I'd like for this step to be handled in the makefiles themselves (probably as part of building the "tree" targets that already exist). Before I move on to the next thing (probably the Chart part), however, I'm going to try to get zlib building under Windows. It's used by the Word translator, and although I worked around the link error just by #ifdef'ing out the call to zlib's uncompress() function, it reminded me that there are a couple of other places where I've done the same thing. So I'm digging around in the cygwin sources for it; I'll probably check the sources in once I get them incorporated into the win32 build process. ### 2000-09-07 (Thu, 11:01:22) The Chart part is now building, but doesn't yet work. The problem seems to be resource related, but I don't have any other clues about what it might be. I've also got the libz compress() and uncompress() implemented, but punted on linking in libz statically for the time being. Instead, we're depending on libz.dll (gotten from ftp://ftp.freesoftware.com/pub/sourceware/cygwin/. And I just learned a few minutes ago that we're actually depending on the 1.1.3-4 rev of the DLL; probably need to fix that. At the moment, however, I'm thinking about CVS branching and merging, and in particular about creating a permanent branch in our CVS archives for code that isn't known to build correctly on BeOS. I'm thinking that Carl and I (and probably also Bruce, Tomy, and Scott Lindsey) should normally work on a branch. We could call ours the Win32 branch, and theirs the Linux branch. The main branch would be Cross-Platform, but would effectively be the BeOS branch. Those of us working on the Win32 or Linux branches would always merge from the main branch as part of updating our local sources, but we would only merge back into the Cross-Platform branch when we know that everything is buildable under BeOS. We'd have to verify that by rebooting and building the Win32/Linux branch under BeOS. Or maybe it would be better to have just one branch, probably called "Port" or "Porting," so that Win32/Linux changes would normally be shared, but not visible to developers working primarily under BeOS until the Porting branch is actually built there. ### 2000-09-08 (Fri, 17:39:22) ### 2000-09-12 (Tue, 14:33:25) I did create a "porting" branch, and on Friday worked out the procedures for maintaining it, but I've been in build hell ever since I switched over to developing on the branch. I can build the app, but not all the parts and translators, and the app can no longer create spreadsheet documents because of a bizarre memory allocation failure that must be a side-effect of a build problem (probably inconsistency between the app and some DLL). Every build error I've tracked down has turned out to be real (i.e., the same error is in the HEAD branch -- not unique to the porting branch). So I tried to checkout and build the HEAD branch on Gargoyle (my debug-target machine). For what appear to be many different reasons, none of which I've been able to isolate completely, I can't get anything to build on that machine. Just for example, in certain contexts that don't appear to be unusual, GNU Make can't locate certain executables on that machine unless you hard-code DOS-style paths to them. In these same contexts, I've verified that the PATH is right. I'm using the same version of GNU Make on both machines (v3.79), but other parts of the cygwin distribution may be different. Unfortunately, I'm more certain that the cygwin distribution on Gargoyle is correct and current, because I just downloaded and installed it yesterday. ### 2000-09-13 (Wed, 08:41:58) I'm still in build hell this morning. Here is the current problem. There are two Parts -- Spreadsheet and Presentation -- that depend on TBlockStreamWriter, which is part of Translators/TranslatorLib, and is not exported from the app. This is what I get when I link these Parts without linking in the TranslatorLib:  Linking obj_DEBUG/Presentation.dll .... Creating library obj_DEBUG/Presentation.lib and object obj_DEBUG/Presentation.exp PRExport.obj : unresolved external symbol "public: long __thiscall TBlockStreamWriter::Error(void)const " PRExport.obj : unresolved external symbol "public: long __thiscall TBlockStreamWriter::EndChunk(long)" PRExport.obj : unresolved external symbol "public: long __thiscall TBlockStreamWriter::WriteInt32(long,long)" PRExport.obj : unresolved external symbol "public: long __thiscall TBlockStreamWriter::BeginChunk(long)" obj_DEBUG/Presentation.dll : fatal error LNK1120: 4 unresolved externals  Linking TranslatorLib into the Parts causes a huge cascade of other link problems. Linking in just the one necessary object file from TranslatorLib -- BlockStream -- doesn't work because of inline'd member functions in TPoint (and elsewhere); the inline'd functions cause duplicate symbol errors, since they are defined in both BlockStream and the app's export table. (Why they have to be defined in BlockStream instead of just expanded inline, I don't remember.) Yesterday I experimented with exporting the TBlockStreamWriter class so that these two Parts can get it from the app's export table. That didn't work, but now I don't remember why, so I'm doing that experiment again. It's an expensive test, because BlockStream.h seems to be included just about everywhere, but it's about half done now. ### 2000-09-13 (Wed, 09:51:28) Here is the reason that exporting TBlockStreamWriter from the app doesn't work. It's kind of a tri-state problem. BlockStream.cpp depends on TPoint, which lives in the app, which forces the Excel translator to depend on the app's export table. The Excel translator also depends on a lot of other non-exported stuff in BlockStream, however, so you get duplicate-symbol errors on TBlockStreamWriter when you try to link it with TranslationLib and an app symbol table that exports TBlockStreamWriter. Of course, translators aren't supposed to import from the app, so the solution here is probably to go ahead and export TBlockStreamWriter in TranslationLib, meaning that it will be exported needlessly (but harmlessly) by translators, and exported from the app for use by the Spreadsheet and Presentation parts. But then where is BlockStream supposed to get its TPoint symbols? Should TPoint be moved into libgobe? Here's some late-breaking news. I've been trying to build the HEAD branch on this machine (LYLE) while writing this -- it just failed trying to build the Excel filter, which is additional confirmation, I think, that the problem I'm trying to solve here is a real one: not a side effect of working on the porting branch. ### 2000-09-15 (Fri, 12:02:11) All those linking problems that have been giving me grief all week are finally resolved. Several changes contributed to getting it all straightened out. The most important is that libgobe.lib is now statically linked only into libbe.dll under Windows; its symbols are then exported from libbe.dll for use by everything else that needs it. We also determined yesterday that BeOS builds no longer need to confine __declspec's to .cpp files -- we can now declare imports and exports in the headers on both platforms, which eliminated a lot of headaches in exporting libgobe symbols, and promises to make a lot of other import/export issues much simpler. ### 2000-09-18 (Mon, 09:01:04) I'm getting a lot of assertion failures in spreadsheet documents (most or all seem to involve maintenance of a keyboard-accelerator table), but if I ignore them, I can get a simple chart to appear. Still haven't succeeded in getting the chart dialog up, however, because of stack corruption crashers that I believe are resulting from calling methods in objects that have been statically cast to the wrong type. One of these was responsible for a similar problem I was having last week, although I don't remember the context now. ### 2000-09-18 (Mon, 10:49:17) Charting seems to be working pretty well now, with the exception that 3D charts are blank because BGLView is entirely unimplemented. Bruce will probably be able to implement it with calls to lower-level OpenGL functions more efficiently than I can, so I think I'm going to leave charting as is for a while, and move on to ImageProcessing parts. ### 2000-09-19 (Tue, 11:55:16) Have I mentioned that I hate GNU Make? It has taken me more than a day to get the app and all its components to build on my secondary machine -- this is with a set of makefiles that works fine on my primary machine. And I'm still struggling with parts of it. One of the most irritating things about is that its "-d" (debug) and "-p" (print symbol table) switches change the behavior of the program -- makefiles execute differently depending on whether these switches are set, which often makes them useless in debugging problems. ### 2000-09-19 (Tue, 15:05:11) I'm beginning to doubt that this CVS 'porting' branch I've created is going to be useful. I've determined that at least one of the problems I've been having this week is rooted in a flaw in CVS's branching model. The flaw is that, when a new file is created on the main (HEAD) branch after a side branch is already in existence, merging the HEAD into the branch does not apply the branch label to the newly added file. The file will be added to the local directory where you did the merge, and CVS knows about the addition in an odd way -- you sometimes get unusual messages from CVS updates in your local merge directory that refer to these files as "new born" -- but if you try to checkout the whole branch in another location, you won't get the newly added file. This would almost be tolerable if we had a reliable way of knowing when these files are missing, and of getting the right versions of them when they are present. But when I build the app with HttpClient.cpp missing, make fails in the worst possible way -- quietly -- even though its debug output makes clear that it knows the file is necessary and missing. The debug output suggests that it thinks it has successfully built the targets that are downstream from this file (i.e., the .dep and the .obj), even though it clearly hasn't. I'm wasting too much time on this. ### 2000-09-20 (Wed, 09:29:25) Tom just suggested something that may be the answer to the branching problem I was worried about yesterday. He said he thought that the porting branch should be recreated every time it is merged back into the HEAD branch. That's probably a good idea. I'm sure it would solve some of the problems with files that are added on the HEAD after the branch is created, just because we would know the branch would soon get repaired. Whether it would solve all of the problems, however, I don't know. ### 2000-09-21 (Thu, 08:43:03) I've fixed all the crasher-level problems with creating ImageProcessing parts, although we still get some non-fatal assertion failures. ImageProcessing part documents are initially filled with black instead of white for some reason. That could be related to all the "Unimplemented function: BBitmap::BBitmap(B_BITMAP_CLEAR_TO_WHITE)" warnings we're getting as we run, although I've been assuming those were probably inaccurate warnings. I think my next step -- at least for the next few hours, while my mind is still in Makefile hell -- should be to get some or all of the plugins building. Then I'll probably hook up some very basic printing functionality -- maybe just the printer dialog to begin with -- so that I'll have a better understanding of the code and a better memory of win32 printing issues when we start working on printing in earnest next week. ### 2000-09-22 (Fri, 17:21:48)  cd \gobe foreachf "/ad *.*" -e cvs checkout -A$n
foreachf "/ad *.*" -e cvs rtag -F BranchCreated-porting $n foreachf "/ad *.*" -e cvs rtag -b -r BranchCreated-porting porting$n




### 2000-10-11 (Wed, 11:26:00)

Image-Processing documents are sort of working now. Empty ones open up with a white background (they were black until yesterday afternoon), and as of this morning, we can open up ImageProcessing documents created under BeOS. So I'm going to put them aside for a little while and return to getting us set up for profiling.

One note about image processing, however, before I forget it. The reason they were initially black is that they use monochrome bitmaps, which under BeOS use 0 bits to represent white pixels, and 1 bits to represent black pixels. Windows uses the opposite convention for monochrome bitmaps (which, if you think about it, makes more sense, given that RGB 0-0-0 is black), so it looks like under Windows we are going to have to make all of our low-level drawing code reverse black and white when the destination is a monochrome bitmap. It's probably something that can be done somewhere in the AutoBrush class, but I'm not going to worry about it until I have an example of something that is not working because of our current handling of monochrome bitmaps.

### 2000-10-17 (Tue, 09:01:25)

I got the new BoundsChecker installed yesterday and fixed the first half-dozen or so of the errors it found; I tried to clear out the ones it found during launch and creation of a blank graphics document just so Carl and I wouldn't immediately be trying to fix all the same errors. I stopped on an error that is going to be harder to fix, but that is related to the work on tear-off menus that I need to do today. It identified places where we are treating HMENUs as HWNDs by mistake. We're getting win32 API failures that cause confusing downstream errors every time we do that, so I need to get that cleaned up before doing a lot more on tear-off menus.

### 2000-10-19 (Thu, 09:04:40)

I think I'm back now to a point where I can focus on tear-off menus again. I spent most of yesterday morning working on a change in our build process that requires BeOS resources to be unzipped under each obj_DEBUG directory instead of under the app, and I spent yesterday afternoon trying to get a debuggable release build up and running so that I could have Tom look at a release-build-only crasher in the HTML translator while he was here. I want to find out whether the god-awful performance we're seeing in this translator is unique to the debug build, but we can't know for sure if the release build is going to crash every time. I did finally get the release-build problems resolved after he left. They turned out the be caused in part by mixing debug and non-debug libraries, which was happening because some of the makefiles still copy libraries up out of the appropriate obj_ directories into the parent directories, so client makefiles just get whichever version of them was built last.

That's all straighted out now, but I still haven't succeeded in months at getting a complete build at home. Last night I thought for sure it would work, but I was shut down by a mysterious "bad address" failure from GNU's bison utility. It's always something.

### 2000-10-23 (Mon, 09:32:46)

I finally got everything to build successfully at home this weekend just by making the intended output of that bison command -- parsedate.cpp -- by hand. Had a bit of a scare when it crashed on launch, but then realized that the machine I was running on has always had a problem with crashes in its printer drivers when its default printer (which is normally remote) is not connected. So I checked and, sure enough, other apps were also crashing when I tried to print. We crash on launch in this situation because of our perverse desire always to know the printable area of the default printer. It makes us look worse to crash on launch, however, and of course looking at the current default printer to determine page sizes it is getting hopelessly old fashioned. But I guess that's the least of our worries now.

Today I'm changing course on the drag-rect code. I'm going to use a transparent non-moveable window overlaid on top of the whole screen. Should be simpler and more reliable than trying to let Windows move a transparent window around and drawing the drag rect at its edges.

### 2000-10-24 (Tue, 09:56:30)

We're now doing a passable job of drawing the drag rectangle for tear-off menus. The worst current problem is a timing dependency: in a BeOS mouse-tracking loop (which is what the app is using to make these drag rectangles work), if you move the mouse continuously, we just keep filling up and dispatching messages from the win32 message queue -- we don't get back up to the BeOS mouse-tracking loop unless you slow down enough to let the win32 message queue empty. I'm going to try to fix it with a new version of PumpPendingWindowMessages(), probably called something like PumpSpecifiedWindowMessages(), which will return control to the BeOS tracking loop on a more predictable basis, maybe once every five or ten messages, or after processing every message of a specified kind.

I'm also having trouble preventing creation of a taskbar button for the transparent full-screen window that I'm using for drawing the drag rectangle: I may have to use the invisible-parent technique described at http://msdn.microsoft.com/library/psdk/shellcc/shell/Shell_Int/Taskbar.htm.

### 2000-10-25 (Wed, 12:03:50)

Tear-off of matrix menus is now in pretty good shape, but I'm having a hell of a time getting it to work for regular win32 menus: creating another window while TrackPopupMenuEx() is running seems to be poor form, so I'm reorganizing a little so as to experiment with creating the transparent drag-rect window before the menu pops up. Maybe then it will be possible to draw on it in the middle of TrackPopupMenuEx().

Had to touch a globally included header (View.h) to do this reorganization, and while waiting on the resulting build, found some interesting statistics on monitor resolutions and color depths currently in use.

### 2000-10-26 (Thu, 17:42:11)

I finally got real win32 menus to tear off reliably, but it wasn't easy. It did turn out to be necessary to create the transparent full-screen drag-rect window before popping up the win32 menu, but with that done, simple drawing on the drag-rect window in the middle of TrackPopupMenuEx() turned out not to be a problem. For some reason I couldn't use SetCapture(), however, to funnel mouse events to the drag-rect window when the user tries to drag during a TrackPopupMenuEx(), so I had to go find where the WM_MOUSEMOVE messages were really going and force them back to the drag-rect window. Modifications to the app code were all related to faking out its assumptions about separate threads, but were really not too bad -- maybe a half dozen lines or so changed.

There are three remaining problems that I know about right now: (1) clicking back into the MICN ("mini-icon") menu bar while a menu is popped up causes a nasty-looking assertion failure, but it looks for all the world like an app error to me -- I haven't been able to figure out why it doesn't happen under BeOS; (2) it's possible to get into a state where an extra click is required to terminate tracking in the win32 menu, but I'm not sure exactly what triggers it; and (3) RemoveChild is doing the wrong thing for pop-up win32 menus that are not children of a BMenuBar -- the Transparency button on the Graphics-document button ribbon is an example; it removes the document window's menu instead of removing the popup menu from its parent.

### 2000-10-27 (Fri, 14:20:06)

Today I took a break from working on tear-off menus and did the makefile work necessary to start adding the Windows-specific resources we will need: icons and version resources, mostly, I think, but probably other things too. I also repaired PromoteDebugBuild.bat -- it had been broken by our move from resources in a .res folder to real win32 .res files linked into the binaries -- made it capable of promoting both debug and release builds, renamed it PromotePhoenixBuild.bat, and checked it in. Doing this reminded me that we have some .dll dependencies that aren't dealt with by this promotion batch file -- I know we depend at least on MSVCRT.DLL, and it seems like I discovered one or two others in trying to make this thing run at home last weekend. I think I'm going to reboot under Win98 and see if I can spot some of those, maybe also fix any Win98-support problems that may have crept in recently.

While I'm thinking about it, here is the URL for instructions on Profiling Multiple .DLL and .EXE Files.

### 2000-10-31 (Tues, 07:45:44)

It turns out that the win32 IsMenu function just doesn't work as a way of distinguishing HWNDs from HMENUs under Win98. It returns TRUE for windows that are clearly not menus, although I don't seem to be able to catch it with an assert immediately after window creation; it only begins to return false positives after some other triggering event that I haven't yet identified. Maybe IsMenu() works as an equivalent of IsWindow for HMENUs: i.e, capable of telling you whether the menu has been destroyed or is not an HWND at any level, but not capable of distinguishing between kinds of HWNDs.

Who knows. The answer for us is going to have to be a simple separation of HWNDs and HMENUs, and no reliance on
IsMenu(). I'm adding another member variable for the latter to the BView class and straightening out all the code that assumes the mWin32Hwnd member could be an HMENU.

### 2000-11-01 (Wed, 07:23:00)

Rats! Even with all our HWND/HMENU confusion eliminated, we are still drawing most of the PartBar icons directly onto the Win98 desktop instead of onto the PartBar itself. This is one hell of a hard problem to track. It's timing dependent, for one thing; if you step through the events leading up to it in the debugger, it doesn't always happen. I do have an assert now that reliably catches one of the error conditions associated with it. The assert uses the Win32 WindowFromDC function to find HWNDs in the BWindow/BView hierarchy that are associated with the wrong mDisplayContext. It shouldn't take too long to track it down now.

### 2000-11-01 (Wed, 18:47:00)

I know now that the Win98-specific problem we are having with drawing certain icons directly onto the Win98 desktop is caused by massive HDC leakage somewhere, so I'm in the process of eliminating most of our calls to GetViewDC, which can allocate a DC that the caller may or may not free. We need to use the AutoDC class instead, which takes care of freeing the DC when it goes out of scope, if that is appropriate (i.e., if it's not a DC that we got from BeginPaint.

### 2000-11-01 (Thurs, 08:38:00)

Finally! The Win98-specific problem with drawing icons on the desktop is gone at last. The HDC leakage was happening in DimBitmap. We were doing a GetDC(0) for every pixel in the bitmap (dumb, yes, but these bitmaps that require dimming are relatively small) and then failing to release it -- not a good thing anywhere, but especially not under Win98.

### 2000-11-03 (Fri, 10:06:33)

I fixed a couple of other crippling problems yesterday. The stack corruption associated with subclassed EDIT controls that I mentioned on Monday turned out to be caused by failure to use CallWindowProc in forwarding unhandled messages -- we were just calling the original window proc directly. And the problem with document content areas completely failing to draw turned out to be caused by failure to get paper-size information correctly from the printer's DEVMODE structure. It reminds me that this dependence on the current default printer for document sizes is something I've grown to dislike more and more about ClarisWorks, AppleWorks, and now GP. Most documents these days are not created with any intention of printing them on the current default printer. Why document page sizes have to be constrained to that is beyond me.

### 2000-11-06 (Mon, 13:47:46)

I forgot to mention that I finally got Microosoft's AlphaBlend function to work on Friday. The missing piece was just one value -- AC_SRC_ALPHA -- that needed to be plugged into the BLENDFUNCTION.AlphaFormat field. It was ridiculously hard to find, because the AC_SRC_ALPHA identifier does not appear anywhere in the headers we are using, and is also not in any of the headers you can download from Microsoft's web site as part of the Win2000 Platform SDK. I had to search the whole web for it, and finally found some web page written almost entirely in Chinese except for a little fragment of Visual Basic source code which gave the value of AC_SRC_ALPHA.

Anyway. AlphaBlending is working in the splash-screen bitmap now. I don't see any evidence that it is working anywhere else, but that may be because of other problems. Our Transparency slider doesn't seem to be working, for example, and I'm not sure the Transparency menu is working, either.

This morning I fixed a problem that was causing document-window menus to go away after calling Track on a popup menu. I'm starting to work now on some of our remaining bitmap-drawing problems. Pattern fills, for example, seem to fill with a pattern that is only vaguely related to the correct pattern, and gradients fill outside their boundaries.

### 2000-11-10 (Fri, 14:23:24)

I finally got BView::ClipToPicture working well enough that we can clip patterns and gradients into non-rectangular shapes, but it was one incredible pain in the butt. Here are a couple of things I learned today that finally gave me a solution. First, when you have a GDI path and you want to use SelectClipPath to turn it into a clip region, WidenPath is what determines whether the interior of the path will be included in the clip region. If you widen the path, the resulting clip region will contain only the path's outline; if you don't, the path's interior will be included. I had originally added WidenPath to ClipToPicture because the first picture-clipping example I managed to get working under BeOS had just two vertical lines. Since the picture had no interior, the WidenPath was necessary; without it, the clip region was empty. There may still be situations where we have to use WidenPath, but my guess is that it's unlikely. We'll see. I have an assert in ClipToPicture that will catch things like the no-interior situation; it detects and complains about completely empty clip regions.

Second, if you call SetParent to break the parent-child connection between two HWNDs, you need to make sure the child is hidden first. Otherwise, Windows will invalidate at least the parent of the parent, and maybe other HWNDs as well. My guess is that it's not smart enough to figure out which HWNDs actually need to be redrawn, and just invalidates everything in the hierarchy as a just-in-case measure. The problem is that, if you do this while you're handling a WM_PAINT, it can set off a sequence of WM_PAINTs that you can't escape, because each one will probably trigger the same call to SetParent. At least that's what was happening to us, down in the BView::RemoveChild() that cleans up the offscreen bitmap into which we were drawing the picture used to define the clip. This was a very difficult thing to find.

### 2000-11-13 (Mon, 08:43:38)

For at least the last six months or so, we've had to watch the Windows task bar flash several dozen times as the app launches. The reason was that BeOS BViews can be and often are created before they are attached to their parent windows. Under Windows, however, when you create an HWND without a parent, it's considered a child of the desktop and gets an entry on the taskbar, so every BView created during launch just for creation of offscreen bitmaps was briefly creating a taskbar button. I tried over the weekend to make sure that BView HWNDs are initially created invisible, since they shouldn't be visible anyway until they are attached to a window, but finally decided it would be a lot easier just to handle it in BBitmap's AddChild method. I do still think, though, that we have a more general problem here.

### 2000-11-14 (Tue, 07:50:03)

Here is a link that may come in handy pretty soon: "Creating and Sending a Message " using Microsoft's CDO (Collaboration Data Objects) API. It looks like it works only on Windows 2000, but it's not MAPI dependent and the example looks simple enough that we might want to use it for a Windows-2000-specific implementation of F)ile-S)end.

I made a lot of progress yesterday. The native win32 menus in the fill control are working again; they had lost their ability to handle clicks after the changes I made last week to reduce side effects of the message-pump operations in mouse-tracking loops, but they're working again -- we just needed to make sure not to pump the win32 message queue while the mouse cursor is still inside the menu.

And pattern-fills are now drawing correctly. The problem with the monochrome patterns was that the buffer passed into
CreateBitmap needed to be word-aligned. The problem with the color patterns was just that we were missing the "Ink Sets" folder underneath the app; I plan to add a step which creates that folder to PromotePhoenixBuild.bat today.

And alpha blending is now working on objects within documents that use bitmapped fills. Getting it to work solid fills, line-drawing operations, etc., is going to be tougher, but looks doable.

### 2000-11-20 (Mon, 10:06:42)

I made a good deal of progress over the weekend, but discovered some disturbing things, too. I'll start with the bad news. First, it looks like using AlphaBlend to display a bitmap containing per-pixel alpha crashes the 166Mhz remote-debug machine I use at home when it's running under Win98. It works fine under Windows 2000, and works with bitmaps other than the Phoenix splash screen. Second, it looks like the DEVMODE structure returned by the printer driver for our HP 932C contains bad dmPaperLength and dmPaperWidth values; it looks like they may be in millimeters instead of tenths of a millimeter. If that information isn't going to be reliable, it will be worse than not having it at all.

Mostly as a learning exercise to help us make a better decision about whether to use libart under Windows, I also wrote a couple of functions that will probably come in handy, particularly if I can make them faster: FillRectUsingAlpha and TextOutUsingAlpha. They work like the win32 FillRect and TextOut functions, but take an additional transparency argument that is used whenever it is less than 0xFF (opaque). Experimenting with using these functions to draw semi-transparent spreadsheet frames exposed a potential problem with SelectClipPath; it appears that, when you draw text in a GDI path, and then use SelectClipPath to convert the path into a clipping region, the interiors of the characters are clipped out instead of in. We will probably have to fix that with a RGN operation of some kind.

### 2000-11-22 (Wed, 11:28:00)

From: Cole Brecheen
To: dev@gobe.com
Sent: Wednesday, November 22, 2000 11:28 AM
Subject: cheap feature that could make us rich


### 2000-11-27 (Mon, 11:12:19)

Over the Thanksgiving break I worked on cursor management, and a bizarre Win98 DLL-loading problem: 45 seconds to load each DLL over a 10Mbps LAN connection -- problem goes away for a while after rebooting, but comes back consistently -- may be unique to the Win98 debug machine I use at home. I was beginning to reach the conclusion last night that the DLL-loading problem probably had something to do with calling AlphaBlend under Win98, but what the problem is, exactly, I don't know. Here in the office today I plan to focus on cursor management, but I'll check the DLL loading problem on a Win98 machine here.

### 2000-11-28 (Tue, 10:30:41)

I'm still working on cursor management this morning, but I think I'm getting close to the end of it. I discovered a couple of things yesterday that were contributing to our problems. The first was that, when you have overlapping HWNDs, win32 sends a WM_SETCURSOR message to both windows. Because BeOS quite sensibly does not send mouse-move messages to obscured windows, I had to add code to our WM_SETCURSOR handler that tries to make sure the HWND is topmost before passing anything on to BeOS code. The second was that WM_SETCURSOR was passing the mouse location in screen coordinates instead of client coordinates.

With those problems fixed, I'm still seeing several things that are wrong: (1) there is a zone about 1/4-inch wide at the left edge of a graphics document where the cursor does not change when it should; (2) disabled EDIT controls on one of the tool ribbons are setting the cursor, and setting it to the wrong shape, which then doesn't get set back to the right shape when you move the cursor back into the client area; (3) if you do it just right, you can move the cursor from outside to inside a document window, which should cause it to become a resize cursor only for an instant when it passes over the window edge, but have it remain a resize cursor instead of an arrow. And then of course we still have a problem with failing to detect the interiors of filled objects, which causes us to get a drag cursor only on object edges.

### 2000-11-29 (Wed, 10:05:07)

I'm still struggling with cursor management problems today. Last night I discovered that, if you move the cursor to some position where it changes to the I-beam and then exit the app, the next time you launch, CreateCursor will ignore the image data passed to it and return an I-beam cursor instead. It's very, very strange, but demonstrably true. In fact, I discovered in the debugger that I could force CreateCursor to pay attention to the passed-in image data by modifying just one byte of the image data, creating a cursor from it and then destroying that cursor, then restoring the image data to its original state and creating the cursor again. At the moment I have code checked in which does exactly that, but it's obviously covering up some other problem. I thought last night that the problem surely must be a resource leak, and I did find and fix a failure to destroy the cursors that we create, but that didn't solve the problem. So today I'm going to clean up any cursor-related BoundsChecker warnings just in case there are any other cursor leaks, and then dig back in.

### 2000-11-29 (Wed, 14:27:28)

Aaarrrggghhhh! I've fixed all the win32 cursor leaks, and the problem is still there -- the I-Beam and crosshair cursors are randomly interchanged after the first appearance of the I-Beam. I thought for a while after fixing all the leaks that maybe windows is remembering the last cursor set by any member of the window class, and restoring to that cursor anytime we do a FORWARD_WM_SETCURSOR. But we get the same problem even with all FORWARD_WM_SETCURSOR's removed (and with them removed we have additional problems with failure to get correct cursors on win32 controls). I need some way of determining when a cursor has gone bad (i.e., has gotten interchanged with a different cursor).

### 2000-11-30 (Thu, 11:42:48)

I thought last night that maybe this cursor problem was behind me, because I made a few changes on a build I did at home, and then couldn't reproduce the problem anymore. I brought that build into the office this morning, however, and it has exactly the same problem I was seeing here yesterday. At this point, I'm looking for any hack, no matter how gross, that will make the problem go away. At the moment I'm trying the friendliest possible handling of WM_SETCURSOR messages -- I'm just forwarding them -- and setting the cursor only in WM_MOUSEMOVE handlers. It doesn't help. Next I'm going to try to figure out why it's just this one custom cursor -- the crosshair -- that gets interchanged with the system I-Beam cursor. If I understood that, maybe I could at least shift the problem to some lower-traffic cursor.

### 2000-11-30 (Thu, 16:11:41)

I finally managed to put all these cursor management problems behind me by using CopyImage to duplicate the arrow and I-beam system cursors before using them. It seems pretty clean and reliable. I still don't understand how we could have been changing the system cursors without calling SetSystemCursor, but we clearly were. I guess it will just have to go on the big unsolved mysteries pile.

### 2000-12-04 (Mon, 10:04:02)

I'm working today on hooking up libart and freetype so that we can switch between them and their native win32 equivalents using a runtime switch. My first goal is just to get everything building and running at our present level of functionality with all the libart and freetype stuff compiled and linked in, but turned off via the runtime switch.

### 2000-12-04 (Mon, 11:28:42)

A quick reminder to myself: TextOutUsingAlpha() is not setting the HDC origin correctly for non-opaque drawing. If we're going to continue using it, that needs to be fixed. This was why the Preferences-Dialog listbox quit working a few weeks ago.

### 2000-12-06 (Wed, 09:38:48)

We are now running reasonably well with all the libart and freetype code compiled and linked in, but switched off at runtime. There do seem to be some side-effects even with the runtime switch turned OFF. As you enter text in a WP document, for example, it doesn't appear on screen until you press Enter. There also seems to be something wrong with drawing handles for selected objects in graphics documents -- the handles don't draw immediately, but then later do draw. I'm not sure what the trigger is.

But it's good enough to provide basic functionality while I work on getting us stable with the runtime switch turned ON. That's what I plan to work on today.

### 2000-12-15 (Fri, 09:38:17)

I've been struggling for days with a Win98-specific GDI-memory leak, and it is killing me. It makes me want to give up and go work behind the counter at McDonald's. Under Win98, we're exhausing the 16-bit GDI heap very rapidly (sometimes in less than a minute), after which the whole OS is prevented from drawing. HeapWalk shows the GDI heap filling up with hundreds of 48-byte fixed objects of unknown type. I have a feeling that they are DIB-sections. I'm about to test that theory now.

### 2000-12-18 (Mon, 14:46:33)

I finally determined exactly what was causing all those mysterious 48-byte fixed objects of unknown type that were filling up and fragmenting the 16-bit GDI heap. They appear anytime you delete a font that is still selected into an HDC. The delete appears to succeed -- it returns TRUE (meaning success), and leak-finding tools such as BoundsChecker don't detect anything wrong. But you do run out of 16-bit GDI heap space if you let more than a few hundred of these fixed-location objects accumulate. Win98 then quickly loses its ability to draw, and operations such as CreateCompatibleBitmap() start to return NIL with no sensible explanation via GetLastError().

Guaranteeing that our BeEmulation subsystem never deletes selected fonts has turned out to be harder than I expected. I spent ten or fifteen hours on it over the weekend, and got close, but didn't succeed in getting a completely clean run through all the asserts I added to detect this situation after determining what it was. I did finally succeed about an hour ago, however, so I'm now packaging up a build that I can turn over to the testers.

### 2000-12-20 (Wed, 11:14:16)

We wound up not delivering anything to the testers yesterday because of this god-awful fill control that's now broken again. Scott Lindsey changed it in some way that makes it easier to support under Linux, but I don't see any way to tweak the BeOS code to eliminate its dependence on a separate menu-tracking thread. So I'm going to quit working towards a clean non-threaded emulation. We just need something that works, and that won't break again.

### 2000-12-20 (Wed, 12:41:02)

It's hard to be productive when you're working in the app (as opposed to the BeEmulation DLL) because the app takes so long to link. Any change in the app involves at least four or five minutes of build time on my machine. It does allow a little extra time to think, however.

Anyway. Now that I know the app's fill-control code isn't even used under Linux, I'm beginning to see how we can make it work under Windows again.

### 2000-12-21 (Thu, 12:30:00)

I'm having trouble with an assertion failure that claims we are not detaching a BMenu from a BWindow before destroying it. Scott Lindsey says it points to a deeper problem in the way BMenus fit into the BWindow/BView hierarchy under Windows. I think he's right; I've tried before just to ignore the underlying problem here, which is that in the win32 version of this emulation BMenus claim to have BWindow owners even when they aren't visible. Ignoring it always seems to lead to some other complication, however, so I'm going to try and straighten out this whole mess over the weekend.

### 2000-12-22 (Fri, 12:20:00)

Today is officially a holiday, but I'm working at home on this BMenu restructuring problem. It's going reasonably well. I've eliminated a lot of complexity by separating a bunch of BMenu and BMenuBar code and deleting a whole class (BMenuBarWindow) that I don't think will be necessary anymore. Since BMenuBars are always visible when the document window itself is visible, it just causes needless confusion to treat the BMenuBar as a BMenu.

### 2000-12-26 (Tue, 12:10:00)

I'm still working on BMenu restructuring. It has turned out to be harder than I thought, but I do have menus working again. We still have crash-on-exit problems, however, resulting from confusion over what code is responsible for deleting the BWindows that we create as owners of B_MATRIX_LAYOUT menus. I expect to get those problems resolved within the next few hours, and should be able to check all this stuff in before I leave this evening.

### 2000-12-27 (Wed, 12:40:00)

Rats. Carl noticed this morning that my menu changes broke keyboard accelerators, and introduced menu-like side-effects (underlined characters) in some controls that aren't really menus under win32 (i.e., combo boxes). I'm fixing those now. And I still have a crash-on-exit problem that needs to be fixed before we can give a stable win98 build to the testers. I'd like to do that by Friday at the latest.

### 2000-12-31 (Sun, 14:15:00)

I think I've finally solved (or at least found a work-around for) an extremely frustrating build error that started plagueing us a couple of weeks ago. The problem has been that the linker sometimes fails because of an error in CVTRES, which complains about duplicate resources and a corrupt Phoenix.res file. There were never actually any duplicate resources that I could find anywhere, however. The problem was somewhat sporadic -- we'd see it happen, and sometimes just relinking would make it go away. Other times it would appear to go away after we deleted the Phoenix.res file, or after we deleted some of the files that the linker apparently uses to do incremental links of Phoenix.exe. But sometimes even that wouldn't work, and we'd resort to getting new resources, which pretty much requires getting new sources to match, and which generally involves rebuilding everything in sight, at a cost of at least an hour or two in build time. This past Friday, even that wasn't making the problem go away, and it caused us not to be able to produce a stable Win98 build on the last work day of the year. Not good.

So I packed everything up on Friday and decided to make it a top priority over the weekend to nail this problem down. I built at home Friday night and got immediately into the problem state, and then set about whittling the problem down to determine what was causing it. What I finally concluded was that, at a certain size threshhold (our .res file is now about 580K) CVTRES can no longer reliably convert it to COFF format in-place when MSLink invokes it. It's not a problem with any of the inputs to RC.EXE or with the Phoenix.res file itself. You can make the problem go away just by running CVTRES from the command line to convert Phoenix.res to COFF format before the link so that MSLink won't try to do it. If you do this specifying a different output file name, it always seems to succeed. I expect I will modify our makefile on Tuesday to do this automatically every time we link.

### 2001-01-03 (Wed, 11:33:44)

If you're looking for an easy way to make a living, don't pick software development. These last couple of days back in the office after the long weekend have been extremely frustrating. The workaround I thought I'd found on Sunday for the corrupt-Phoenix.res-file problem didn't hold; I started getting the error again first thing yesterday morning, and converting the .res to COFF by hand didn't help. So, since the CVTRES error message continued to complain about duplicate resource IDs, I modified the .rc-generation procedure to sort the resource ID list by type just to help track down any possible duplicates. And, oddly enough, that made the problem go away -- at least for now.

With that problem finally at bay, the debug build was looking pretty decent under Win98 early yesterday afternoon, so I started trying to package up a release build for delivery to testing. It, too, looked good -- better than it ever has in most respects -- except for one crippling problem: a crash on exit that required a machine restart. Not to worry, I thought; since our build process always links non-debug executables a second time with a symbol table, I can just debug the problem using those debuggable release-mode executables. Unfortunately they turned out not to be debuggable after renaming them, for example, from "Debuggable_Phoenix.exe" to "Phoenix.exe" -- apparently some reference in the .pdb file to the original name of the .exe or .dll as produced by the linker -- so I had to make some very tedious and not-very-pretty changes in the link process that allow the debuggable release-mode executables to be linked using the same names as the non-debuggable versions. That finally works now, after four or five hours of hair pulling, so maybe I'll be able to figure out what is causing the release-build-only Win98 crash on exit problem.

### 2001-01-08 (Mon, 09:10:15)

This morning, because of another crash-on-exit problem in the BMenu destructor that we discovered late Friday evening, I'm trying to completely sever all parent-child relationships between BWindows and BMenus. It looks like the right thing to do, and I've already got most everything to work with all the AddChild / RemoveChild stuff deleted from BMenu.cpp. But I'm left with a crasher in the fill control that I haven't yet tracked down. My best guess is that I'll have it all straightened out by noon.

### 2001-01-08 (Mon, 11:09:45)

I wound up not being able to break the parent/child relationship between BWindows and BMenus that seemed to be causing us problems on Friday. I fixed the crash-on-exit problem by removing some BWindow-creation code in BMenu AttachedToWindow that was duplicated in BMenu::Show. We may have to revisit this BMenu implementation, however. I just hope it can wait until after this version ships.

Since I'm waiting on some code from Bruce before I can make more progress with using LibArt to draw document window contents, I think this next task for me is likely to be drag-and-drop. The first step will be to change our Win32-clipboard handling code so that it uses the OLE clipboard instead.

### 2001-01-09 (Tue, 14:07:29)

I spent several hours last night struggling again with the MSVC profiler, but finally got good data out of it. It showed exactly where the worst of our speed problems are in dragging around large objects. It turned out that they resulted largely from a huge number of WM_MOUSEMOVE events generated because attaching a BView to a BBitmap for offscreen drawing purposes creates an HWND, which generates WM_MOUSEMOVEs, which causes us to create more offscreen bitmaps (it's part of a technique we use for determining whether the cursor is hovering over the interior of a filled object). The net effect was that we were getting and processing WM_MOUSEMOVEs constantly, even when the cursor was completely still.

### 2001-01-11 (Thu, 09:49:34)

I made a lot more progress yesterday on the speed problems we were having with dragging large objects around in a graphics document. There were two places in mousetracking loops we were allowing WM_MOUSEMOVES and WM_TIMER messages to be dispatched and handled. I fixed those by adding a new PumpAllButSpecifiedWindowMessages() function. Drag speed now seems fine. Bruce thinks there may still be a speed problem in his gradient rendering code, but otherwise this particular performance problem seems to be behind us.

So, drag-and-drop (i.e., OLE clipboard) support is still the next big task for me, but I think that first I need to fix some menu tear-off problems that have crept in over the last month or two. I also need to get printing to work with freetype/libart turned on so we can see what that's going to be like.

### 2001-01-16 (Tue, 10:07:04)

Yesterday I finally fixed what I hope are the last of our problems with tear-off menus. I had to add code that dealt with ending the drag-rectangle-drawing operation as a separate case, just as it has been dealing with starting the operation as a separate case. And I had to change the sequence of events involved in destroying the transparent full-screen window that we use as a drawing surface for the drag rectangle, because certain information associated with it has to survive long enough to let us erase the last rectangle drawn. Today I have to re-enter crash-on-exit hell -- another one seems to have crept in over the weekend.

### 2001-01-17 (Wed, 16:25:59)

I wound up spending most of yesterday afternoon and another couple of hours this morning just trying to get our floater activation states right. It was frustrating. We need to hide all floaters (1) when all document windows are minimized, (2) when the app is deactivated by activation of another app, and (3) when a modal dialog appears, and then we need to show them all on the converse of these events. Unfortunately, anytime we show or hide a window, win32 generates activation and deactivation events for other windows, and some of these events are also the ones we're handling to hide and unhide floaters. It gets complicated.

I think it's working okay now, however, with one exception: Holdaway says there are cases where floaters bring up modal dialogs, and in those situations it wouldn't be good to hide the dialog's parent window.

At the moment I'm trying to fix the fill control again. It turned out that a cross-platform bug I'd been seeing with a tab drawn in the wrong place on a second invocation of the control was a side effect of code I had added that abused the meaning of a certain member variable. Tom deleted the code, and now the control is broken again. He suggested adding another member variable instead of overloading the meaning of an existing one. That's what I'm experimenting with now, but I don't relish having to get back into this code.

### 2001-01-23 (Tue, 11:57:27)

Over the weekend I fixed most of our vertical scrolling problems -- horizontal scrolling is still not working very well at all. I also fixed several build problems that seem to have appeared out of nowhere. The profiler, for example, quit working because it claimed our executable was linked with a /FIXED switch. That has never been true, but it turns out that /FIXED has always been the default. So how was I able to profile before this weekend? I added a /FIXED:no switch to the makefile and now the profiler works again.

### 2001-01-24 (Wed, 15:15:37)

I'm working today on getting printing to work via libart and freetype. It's a mess, but I think it's going to work okay. I can't tell yet how big the print-spooler files are going to be, but I'm structuring the code to support a "Faster printing" user-settable preference that will let us print through GDI if we really need to.

While I'm thinking about it, here is a good article about how AppleWorks currently being used in the K-12 market that makes clear just how vulnerable Apple is going to be to any competitor capable of offering the same or better functionality in a well supported cross platform package.

### 2001-01-29 (Mon, 16:10:23)

I solved an irritating little printing problem today that turned out to be just an algorithmic error on my part, and so we are now able to print good-looking text that isn't really text, so far as the printer driver is concerned; instead, it's lots and lots of lines and bezier curves. I'm turning my attention now to printing graphics documents.

### 2001-02-01 (Thu, 11:23:45)

I just finished having to work around a bizarre set of problems that showed up for the first time on Peggy's Win98 machine: a Compaq Presario 1200 laptop. The root of it all seemed to be that all of the mutex- and semaphore-related APIs hang inexplicably on her machine. Since at the moment we're not multithreaded, I worked around it by adding tests that disable all those calls when we're running on a non-NT-based platform, but that's not a good long-term solution. We're soon going to really need at least one separate thread for handling the get-from-web process, so this is something I'm going to have to figure out. For now, however, these changes get the app running smoothly on her machine, and probably on some percentage of other Win98 machines as well.

### 2001-02-02 (Fri, 16:45:00)

The cursor positioning problem turned out to be even harder than the printing problem.

### 2001-02-06 (Tue, 11:13:24)

The learning curve on OpenGL is awfully steep. I've probably spent a good solid day now just trying to get it initialized correctly so that we can create a gl drawing context. My current theory is that it has some unstated assumptions about the HWND referenced by the DC for which you have to set a gl Pixel Format. Does the HWND have to be WS_VISIBLE at the time you set a Pixel Format for its DC? I'll have to determine the answer empirically, because the OpenGL docs don't say.

### 2001-02-06 (Tue, 17:46:06)

With a little help from an MSDN article on drawing to DIBs with OpenGL, I finally got OpenGL to initialize correctly under Windows just a little while ago. We still don't get 3D charts, but I'm pretty sure the reason is that the bitmap into which we're trying to draw starts out at zero size. I need to add code to re-initialize OpenGL when the size of the bitmap changes. I'm pretty sure I'm on the right track because Bruce made a similar change in the Linux version a couple of weeks ago, which I didn't understand at the time. Now I do.

### 2001-02-07 (Wed, 12:48:55)

Resizing OpenGL charts at the right time did work -- they are beginning to draw now -- but they are drawing upside down. They also seem to be distorted in some way that may be a row-stride issue.

### 2001-02-09 (Fri, 09:48:55)

OpenGL charts are now working at a sort of minimum level. They are being created at the wrong resolution, and the axis labels don't line up very well with the bars, but otherwise they look and act pretty much like they do under BeOS. Bruce says he thinks the resolution problem is also happening on Linux, so I'm going to put it aside for a few days so he can look at it there.

Today I'm going to try to get tooltips working again. The fundamental problem appears to be a window activation issue: creating the tooltip window through the regular BeEmulation BWindow mechanism deactivates the document window, with all kinds of side effects including destruction of the tooltip window we just created. So I'm thinking of trying to use the regular win32 tooltip control instead.

### 2001-02-13 (Tue, 09:27:57)

Tooltips are working again, with just a couple of lingering problems: the yellow tip-text rectangle is a little too large for the text, and we get a bit of flashing elsewhere in the UI when a tooltip appears. The first problem is probably the result of a dots-to-points or points-to-dots conversion that we're not doing somewhere. I don't know about the second.

Getting these things to work turned out to be a very typical Windows development experience. I spent most of Friday and a big chunk of the weekend trying to implement our tooltip support through the win32 common tooltip control, but never got the control to work at all, and still don't know exactly what I was doing wrong. I realized on Sunday, however, that using the common tooltip control as it was really intended to be used would require a lot of app level changes -- the common tooltip control doesn't provide a clean API for simply displaying a tooltip at a certain location for a certain length of time -- so I decided yesterday to go back to the BeEmulation method, which had been fairly close to working before. I solved the activation-event problem pretty quickly, and before noon had tooltips displaying correctly, but with the wrong background color. No problem, I thought: the emulation draws tooltips with static EDIT controls, and the mechanism for changing colors in EDIT controls is well documented. Right. I spent the rest of the day tinkering with code that should have worked, but didn't; I tested dozens of variations and theories about why it wasn't working, and finally discovered that all of Microsoft's instructions silently assume that you are smart enough first to make sure that the HDC's background mode is TRANSPARENT instead of OPAQUE. That's something I'll remember for six months or a year, but eventually I'm sure I'll have to learn it the hard way again.

### 2001-02-15 (Thu, 16:27:08)

I now have the Settings button in the File-Open dialog working very nicely. It did take more than half of yesterday to figure out exactly how to subclass the common file dialog these days. Since the first time I had to do this back in Win3.1 we've gone through at least two and maybe three generations of the standard technique for subclassing common dialogs, and there seem to be no examples of the currently approved method anywhere in MSDN or on the web. The SDK documentation is complete and accurate, however, so it's not too difficult just to follow the instructions. Now that I think of it, I probably could have found an example somewhere in the Platform SDK sample code, but chances are that it would have been unnecessarily complicated since I only needed to add one button.