[MiNT] form_button in XaAES

[Jo Even Skarstein <joska@online.no>]

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