Re: Focus Callback in CDK

[Thomas Dickey]

On Fri, 4 Mar 2005, Fu Steve X wrote:

> Hi,
>
> It seems there is nothing like the Motif type Focus Callback for CDK. Is
> that right? Because the regular Callbacks via key bindings or pre/post
> processing all require invoking a key.

yes, that's right.  The handling of input in CDK is a little odd (the
inject functions).  My inclination has been to keep it at least nominally
compatible with Mike Glover's version - it might be possible to revise
the internals to support real callbacks and leave the existing interface
intact (I'm not sure - Friday evenings aren't good for thinking that 
deeply into it).

> My scenarios is that there are two widgets on a cdkscreen, one ItemList and
> one Scroll. Once the user selects a parameter from the ItemList and hit
> KEY_TAB to traverse to the Scroll, the Scroll will refresh its data using
> the newly selected parameter.
>
> The only way I can get it to work is to hack the CDK traverseCDKScreen()
> function. Moving the following line from the default case to right before
> the big switch. I then bind the key TAB to the ItemList to refresh the
> Scroll. That also achieves another purpose. That is, now I can register
> callback for KEY_ESC for both widgets on the cdkscreen to handle the regular
> exit/quit. I'm not using the Menu widget anyway.
>                 InjectObj (curobj, key);
>
>
> Any graceful way to do that from the user code with hacking the system CDK
> code? It not, any side effect from the hack other than the behavior of the
> Menu widget being shadowed?

well (quick check), menus seem to still work.  That doesn't affect the
extra tab behavior that you note below, either.

The drawback to that would be if one of the widgets has an interpretation
for one of the keys that traverseCDKScreen handles.  Then one key would
do two different things.  (At least that's what I'd expect).

> Another abnormal for the traversal is that the first TAB I hit right after
> starting an application is always ignored. I had to hit TAB twice before the
> traversal to behave. I've seen this in both my own code and the sample
> traverse_ex.c.

I might have noticed that, and decided it was an artifact of how the
widgets process data (but it sounds more like a bug at this point).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net