[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] SV: SV: form_button in XaAES
Jo Even Skarstein skrev:
[mailto:firstname.lastname@example.org]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
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)
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);
Hmm.. if we first make new things like this, lets try to make it as
simple as possible. The app should not need to keep track of focus,
except from cases where it places the cursor upon opening a window, or
wind_evnt(handle, event); would suffice. And then this function
returns 0 if event was eaten or 1 if not. Or vice versa. The only thing
the app should consider in this case is which of its windows it wants to
send the event to. If it needs to place an event at a specific edit
field, it can use the normal form_keybd() function.
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
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.
Yes. And while we're on the subject. I think that we need to change
things so that you get a toolbar handle when you attach one to a window.
Then this toolbar handle will have to be included in the WM_TOOLBAR
message, so that we open up for different toolbars in the same window.
This handle is not necesssarily the tree address, I want to hide the AES
object trees from the app via objc_data() function call. This is under
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.
Well, yes. Altho I prefer the current solution (app is free to choose
where to direct the keybd event via form_keybd()) to a one that is not
well thought through.
Btw this would be a good opportunity to extend edit fields to handle strings
longer than the visible field (scrolling edit fields).
that is in the works in XaAES already. It is very easy to implement,
but the AES needs to keep extra info about the AES objects, which is why
I want to hide this from the app. objc_data() is a function call that
apps should use to get/set data in object trees. This frees the AES to
organize things without having to consider compatibility :)
Ok, how about this;
case EVNT_KEYBD: (and any other event)
examine the event, wanna intercetp?
get window ontop and
if (!wind_event(handle, event);
do something about the event
use event for own purposes.
To attach a toolbar to a window;
long tbhandle = wind_set(handle, tbtree, orient);
where handle is window handle
tbtree is object tree (or handle)
orient is how to place it within window
And WM_TOOLBAR message;
Since there is no space left in current message it must be extended!
And once we do this, I think we need to come up with a decent sceme
here as well. For example;
evnt_multi() takes an extra param indictating max size of one single
message in message elements. Then new message format could contain long
elements in contrast to todays short. So;
msg = message id;
msg = AppID of sender;
msg = Lenght of following data in message elements. That is ,longs
msg..msg[x] message data;
will remove our current restriction problems.
Now we can continue implementing decent toolbar handling :-)
msg = WM_TOOLBAR
msg = pid of AES (or sender)
msg = x
msg = tbhandle
msg = winhandle
msg = object index
msg = keyboard status
msg = tbhandle in which editfocus currently is
msg = index of object within tbhandle that has editfocus
So, its a lot of work doing something without getting stuck in a new
bad implementation :-) More ideas?