In article , Mel Wilson wrote:
> What I was thinking there was that, when I encountered wxWidgets
> (through wxPython) all the class names that I was using seemed very
> familiar from my days writing switch-statement-from-hell C programs
> for Windows 3.1.
> The same catch-all wx.Windows class from which almost everything else
> descended, etc.

Yes, I suspect Julian Smart had used Microsoft's MFC framework for C++
before he started writing wxWindows (as it was then called) for
cross-platform development. There's some similarity in naming, and some
of the same techniques are used (where applicable, when there isn't
anything obviously better) ... but wx has it's own 'style' in which the
underlying platform details are more abstracted-away than in (say) MFC.

> I sound more disparaging than I really am.  I got some good stuff
> done, and most of what I knew from before adapted very easily
> to wxWidgets.

Yes, compatibility is helpful ... as long as you know where it stops!

> My example of non-Windows style would have been Borland TurboVision,
> and its descendant Object Windows Library.  Breaking down the huge
> Window class into View and Group made things much simpler.  Too bad
> that style didn't prevail.

[I remember those ... too bad OWL2 wasn't more widely adopted, I always
thought.]

A window is a GUI abstraction that carries a lot of baggage (especially
in Windows!) so a class that manages one is going to be big.

I don't recall what OWL, in particular, did to split that up (I still
have the manuals, somewhere ... and that was back in the day when
manuals were well-written and thorough).

--
Cheers,
 Daniel.

--- SoupGate-Win32 v1.05