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

Re: [MiNT] SV: SV: form_button in XaAES



Jo Even Skarstein skrev:

-----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);
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 such. So;
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
      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.
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 development. 



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?
        if (no)
             get window ontop and
             if (!wind_event(handle, event);
                 continue;
             else
                 do something about the event
        else
             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[0] = message id;
   msg[1] = AppID of sender;
   msg[2] = Lenght of following data in message elements. That is ,longs
   msg[3]..msg[x] message data;
will remove our current restriction problems.

 Now we can continue implementing decent toolbar handling :-)

 msg[0] = WM_TOOLBAR
 msg[1] = pid of AES (or sender)
 msg[2] = x
 msg[3] = tbhandle
 msg[4] = winhandle
 msg[5] = object index
 msg[6] = keyboard status
 msg[7] = tbhandle in which editfocus currently is
 msg[8] = 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? 


 Best Regards,
Odd Skancke