[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] form_button in XaAES
Olivier Landemarre wrote:
Jo Even Skarstein wrote:
According to newcalls.txt it's strongly recommended to use form_button
and form_keybd in non-modal dialogs to allow XaAES' keyboard
navigation to work. However, as neither of these functions (together
with objc_edit) doesn't have a window context, they all ignore the
rectangle list. The result is that other windows get dirtied unless
the processed object is on top.
This is normally not an issue, as most windows doesn't process
keyboard and mouse events unless they're on top. There are currently
two situations where they do:
1. The dialog window has the WF_BEVENT attribute set. It's possible to
process mouse button events even if the window is not on top.
2. Another window has the "always on top" flag set (XaAES).
I'm working on a project where (1) is getting a bit of a problem. I've
tried some other applications (qed, artworx, smurf and toswin2) and
they all behave similar to my app, so I assume that there's not a
solution for this problem yet.
My suggestion is to add tree new functions in XaAES, xform_button,
xform_keybd and xobjc_edit. These have the same functionality, but are
extended with an additional argument - window handle. They will then
be able to observe the window rectangle list when redrawing, and it
will be possible to create non modal dialogs the proper way.
I haven't looked at the sources though, so I don't know if this is
possible. If not, perhaps these functions could be identical to the
old functions but not do any redraws. Then the application can do this
itself using obcj_draw.
Really I think some software are a little bit complicated, in my opinion
this functions where sub-function of the very old form_do(), with theym
a lot of developpers have done dialog box in window, this was
interesting, but now really I think it's obsolete because there is a
very simple way to do this, without programming anything:
And thats all, only manage messages, no redraw to manage, non-modal
window etc... This is quite cool and so easy.
Thanks Olivier for pointing this out.
The original implementation from N_AES was very limited.
When I left XaAES I had lifted all limitations on the type
of objects permitted.
You get a WM_TOOLBAR message if a (TOUCH_)EXIT object is actioned.
The beauty of the concept is that your program needs only
the one and only central evnt_multi loop.
I was hoping to make all obscure and complicated solutions
for non modal windows obsolete.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger; http://digger.atari.org
A Home Cooked teXt editor: AHCX