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

Jo Even

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.

Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler:     TT-Digger;  http://digger.atari.org
A Home Cooked teXt editor:    AHCX