Re: [MiNT] WCOWORK implementation : conclusions.

[evan@coolrunningconcepts.com]

Quoting Jo Even Skarstein <joska@online.no>:

> Another variant of this argument was related to WINDOW and WINDOM
> components. It was claimed that WINDOW will get all confused if some
> components use WCOWORK and other's don't. If this is the case then this is a
> weakness in the design and specification of WINDOM (remember, all protocols
> and interfaces must be clearly defined and documented), or a result of
> sloppy programmers who doesn't read and respect specifications.

It comes down to - can any lib other than windom perform a wind_creat() ?
windom will pass it all the events.  If the 3rd-party lib uses WCOWORK and
Windom doesn't, then Windom gets the events wrong.  If the 3rd party library
doesn't use WCOWORK, and Windom does, then the window is created wrong.  I
can't say in all honestly that dividing the event handling code from the code
that actually opens windows and works with them is a bad thing, and I don't
think it is.

Can we have the all benefits of WCOWORK without this restriction?

> I sincerely hope Ozk continues his work and adds more functionality to
> XaAES. I want to see the above multipage forms and multiline editfields for
> example. Now that's something that will significantly simplify development
> of useful applications! Now, if I only could get my dead Milan fixed I could
> start programming again...

Multiline editfields is okay.   In fact, "Notepad" is just that, a big 
multiline
edit field.  Multipage forms ... tabbed windows I like, but tabbed dialogs I
don't care for much.