[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] SV: form_button in XaAES


Olivier Landemarre skrev:

And thats all, only manage messages, no redraw to manage, non-modal
window etc... This is quite cool and so easy.
I know about this, but atleast when I do this in XaAES I still need the
form_* functions to handle edit fields.
Oh yes? It's supported in MyAES I thought this was the same on other AES (never
test it on other AES!)

AES 4/4.1 and N.AES only supports TOUCHEXIT objects in toolbars. XaAES supports all kind of objects (introduced by Henk Robbers), but doesn't handle editfields. If you want to use edit fields you still need to use form_button and form_keybd. If MyAES doesn't need this it is just great! You must get in touch with Ozk and discuss this with him, as this really should be supported by both current AES'es. It will make it so much easier to write applications. Much easier than that stupid wdialog stuff.

Jo Even
I think it's not a problem for Odd! We need probably think wich flag add in appl_getinfo(), what do you think about this Odd? Perhaps in AES_WINDOW bit 14 or 15 to said TOOLBAR support full dialog box managment as form_do()?

Hmm.. its a very good idea, but exactly how do you decide when focus is where? I plan to support several toolbars in a single window, and then we need some semantics on how to figure out which toolbar has focus at any given time. How do MyAes do it now? If the application isnt notified in any way of a keypress when a window with toolbar attached is ontop, you cant have hotkeys in your app? Do you pass the normal ctrl+q, and friends to app instead of forcing it into the editable field? I dont like the idea that apps cant decide what to do with the key it gets, but perhaps if we come up with a good sceme on this :-)


One idea I have;
The AES manage all editing when a toolbar is attached. The user can, as a setupstage, tell the AES which keys it want to get notified of. Default would be ctrl+q/ctrl+s and friends (open/close/save/quit, etc.). This would make it possible for apps to gain more control, plus handling a toolbar (or dialog-window) would be greatly simplified. But one cannot 'close up' the possibility to get key events completely, which will get avoided by means of 'I want these keys' setup.

But how to deal with situations where there is a mix of toolbar(s) and normal, lets consider a texteditor, contents in a window?

I agree I dislike too wdialog!

 Yes! Its a good idea with a sadly braindead implementation.

 Best Regards,
Odd Skancke