[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] SV: form_button in XaAES
Olivier Landemarre skrev:
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()?
Oh yes? It's supported in MyAES I thought this was the same on other
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.
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
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.