OpenEuphoria

Re: Re Win32lib questions

• Posted by "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV> Aug 25, 2000
• 436 views

Brian Broker wrote:

> BTW, David Cuny made the comment: "But since I'm no
> longer the primary coder, you might talk Matt into
> adding that feature. "
>
> Personally, I'm not sure I like this line of thinking.
> Do you really want to just hand over the project to Matt?

Actually, I've handed the project over to the community as a whole, and
asked Derek Parnell to adminstrate it. It's a done deal; there is currently
a site on SourceForge:

   www.sourceforge.net/projects/win32libex

Derek is (I believe) currently on vacation; when he gets back, he'll be
releasing Matt's version on the site as the 'official' release. I've already
adopted Matt's version for my own projects.

Matt is not the only person to do coding on Win32Lib; over the course of
time, quite a few people have had their fingers in it, from small
suggestions and bug fixes to adding major chunks of functionality. I'll
continue to have oversight on the project as time permits, but I really
haven't had the time to work on anything else recently.

For example, Matt has added in tree control to Win32Lib, and they were
crying for really clean wrappers - someone had suggested that the deserve a
class of their own. I suspect it'll take a few iterations to get it exactly
right. But I just haven't had a chance to even look at the new code, other
than for a few minutes. It's just not fair to the group as a whole to be
denied a new set of tools because of my scheduling issues. Better to release
it now, and have people who actually use the controls make suggestions, than
wait until I have free time and issue some sort of decree.

In addition, I think that the group as a whole has done an excellent job in
answering questions about Win32Lib without me.

So what's my role? Primarily, shaping what Win32Lib's API looks like,
avoiding API bloat, and making suggestions for future enhancements. For
example, I think that there should be multiple classes of windows. Instead
having to add obscure Win32 flags to the Window, there should be seperate
classes:

   ModalWindow
   SplashWindow
   PaletteWindow
   GraphicsWindow
   MDIWindow
   ChildWindow
   ScrollWindow

The ScrollWindow would have scrollbars. The GraphicsWindow would use the
persistant graphics, so people don't have to deal with the OnPaint coding
bit if they don't want to. I avoided using these before, because they eat up
a lot of memory per window, but it makes sense if you want to be able to
paint persistantly to a window. I can even imagine a DoubleBuffered window,
although I'd hate to code it.

Did that answer the questions?

-- David Cuny