[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MiNT] SV: SV: form_button in XaAES
> -----Opprinnelig melding-----
> Fra: mint-bounce@lists.fishpool.fi
> [mailto:mint-bounce@lists.fishpool.fi]På; vegne av Odd Skancke
> Sendt: 7. september 2007 16:00
>
> But how to deal with situations where there is a mix of toolbar(s) and
> normal, lets consider a texteditor, contents in a window?
Don't let the AES handle keyboard events unconditionally, let the
application pass it back to the AES after it has done what it needs with the
event.
Let's say we offload everything that has to do with editable text fields to
the toolbar handler, but that it needs to be passed keyboard events from the
application. We could introduce a new call (or an extension to an existing)
for this:
case EVNT_KEYBD
examine the event, do whatever we want.
if there's one or more toolbars attached to the window,
pass the event to the AES so it can take care of focus
and editing. This must always be done so keyboard navigation
will work with toolbars:
form_toolbar_keybd(window, toolbar, event);
the result of this calls must indicate whether the key was used
or not. if it wasn't used, the application may want to use it
itself.
This will take care of editing and focus changes by keyboard. Any focus
changes by mouse events are handled by the normal toolbar handler. Also any
button events caused by keyboard navigation (like "clicking" on a button)
should generate a TOOLBAR message, just like when the button has actually
been clicked on.
Without some sort of simplified edit field handling the extended toolbars in
XaAES are pretty useless. The same can be achieved just as easy by using
objc_wdraw, and this will also work under MagiC.
Btw this would be a good opportunity to extend edit fields to handle strings
longer than the visible field (scrolling edit fields).
Jo Even
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.3/986 - Release Date: 03.09.2007
09:31