So busy I don’t even blog!
I’ve been really buckling down and working hard on the Win32 port of AbiCollab recently. I’ve made some very large (at least, for me) commits without even posting ridiculously long blog posts about them, so you should either be a) proud I’m reforming my writing style or b) disappointed at the apparent lack of progress.
Last blog, all we had was a single, non-functional dialog. Well, now that dialog has a properly hooked-up “Add” button that really does bring up the Add Account dialog. This was a bit of a process: turns out the MinGW resource compiler doesn’t like compiling more than one resource file. After considering some Makefile-foo to call it repeatedly, I settled instead on a single over-arching resource file including each of the dialogs. (Which, by the way, are all completely designed and have functional resource files - I just can’t “get to them” in the UI yet so I haven’t copied and pasted the standard code behind them yet).
Dialog #2 - Date of Birth: July 20, 2007
Furthermore, we have an account backend (the TCP Backend) that is at least being registered and responding to our requests - it even draws (ugly-looking) controls in the Add Account dialog when it is selected from the drop down. And, even though it would be easier to not do so, I’ve implemented load and unload for the backend controls: even though only TCP realistically will run on WIndows for now, the dialog knows no such thing, and willingly destroys and re-creates the controls each time I select TCP. Exciting!
Tonight: Beauty only the programmer who was confused for quite some time by a non-standard definition of “height” could love. (Yes, the TCP backend builds and loads!)
(Note to others: the height of a ComboBox DropDownList control determines the maximum extent of the drop down menu, not the height of the edit control! Don’t let this fool you!)
So what’s next? Well, I’m considering adding a function to the AbiWord core (GASP!) to allow me to set the dialog handle manually in a DialogHelper, so I don’t have to essentially duplicate those functions. (This gets back to the instance thing I mentioned before: since we’re in a seperate executable image and need to use our own instance calling Win32 directly, we don’t use the DialogHelper’s tools to do that which would also initialize the hDlg in that class)
Furthermore, I’d like to figure out why the controls I’m painting in the TCP backend are both a) ugly and b) the wrong size. Hopefully from here on out, now that I have a useful amount of Win32 API experience, implementation will be reduced to just plugging the gaps between the WinFE and the cross-platform goodies Marc already wrote. (The second and a half dialogs went way quicker than the first…) I also need to work on some sort of signalling mechanism since the TCP backend uses an async/threaded system for handling packets. It looks like a message-only Win32 window is the way to go: fortunately I found a good tutorial.
Well, I must not have reformed my writing much - this is still really long! Oh well, it corresponds with a lot of progress. Keep on hacking, ants!