OpenEuphoria

Re: Re Win32lib questions

• Posted by Matthew Lewis <MatthewL at KAPCOUSA.COM> Aug 25, 2000
• 441 views

David Cuny wrote:

> 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.

Even currently, there are others working on it.  Take Skoda's MDI project,
for example.

> 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 got the feeling that Al was referring to an MFC class.  To do this, we'd
have to turn the MFC class into a DLL, and then wrap the DLL.  I don't think
we'd gain anything from this.  Frankly, I see win32lib (in many ways) as the
Euphoria equivalent to MFC.  If that's not what Al meant, then I don't
understand what he was talking about with regard to 'class'.

> I suspect it'll take a few iterations to
> get it exactly
> right.

Absolutely.  Unfortunately, some aspects of treeviews and listviews just
don't fit nicely with existing stuff.  Specifically, addTVItem is a
function, while addItem is a procedure.  I think the solution might be to
create a new function addItemEx, which wraps addItem, addLVItem and
addTVItem.

> So what's my role? Primarily, shaping what Win32Lib's API looks like,
> avoiding API bloat, and making suggestions for future
> enhancements.

Our elder statesman. :)

> 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

I partly agree with this, but I'm a little hesitant about some of this.
What if you want an MDIChild that uses persistent graphics, for example?
Talk about API bloat. :)

On a similar note, I'm thinking that some sort of wrapping of xSetWindowLong
is in order.  I've had a request for an EditText without the autoscroll
property.  Of course, it would be pretty simple to copy the EditText to
another class, but it's probably easier to wrap a procedure to add/remove
properties.  The same might apply to some of the windows.

I just tested my SetWindowLong to remove ES_AUTOHSCROLL from an EditText,
but it didn't seem to work.  The control still scrolls.  Does anyone know if
there's something that needs to be called to update this sort of thing?

Matt