Re: [MiNT] SV: form_button in XaAES

["Olivier.Landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

Hello Odd

>   Hello,
>
> 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 :-)

A lot of question, I have look in source code and just do a small program test
and it not work really as I think it work :-( but I have some answer for you:

Focus is put is done for toolbar only if user have done a click on it and if
there is edit fields in toolbar. Focus is realease for client if it click in
work area. Actually I not manage hotkey and they are lost if focus is on
toolbar, nor change of edit field with tab or arrow.
In fact this is very near from form_do(), I
actually not manage visual cursor too. I think I have some changed to do, to be
correct, I notice too a lot of trouble redraw :-(
Key for edit fields are totaly managed by AES, client have no idea of this as
under form_do()

>
>   Ideas?
>
> 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.

I think Hotkey should be transmit to client (except probably ctrl+v for gem copy
text in edit field).
Actually in my version it work only if application wait for keyboard event, I
think it should not but it's a little bit more difficult to manage!

>
>   But how to deal with situations where there is a mix of toolbar(s) and
> normal, lets consider a texteditor, contents in a window?
>
Actually I have no application like this, so never able to test, I have start a
small test software for this.

Regards

Olivier
>
> >
> > I agree I dislike too wdialog!
>
>   Yes! Its a good idea with a sadly braindead implementation.
>
>
>   Best Regards,
> Odd Skancke
>
>
>
>