RE: Focus Callback in CDK

[Fu Steve X]

Tom,

Thanks for your Friday evening work! :-)

Regarding the double-TABs required to start the traversal, it might be that some initial values are not set properly. I haven't look into the lower level functions. But adding the following line right before the big while loop in traverseCDKScreen did the trick.

        curobj = switchFocus (setCDKFocusNext (screen), curobj);

Thanks again.

Steve

-----Original Message-----
From: Thomas Dickey [mailto:address@hidden]
Sent: Friday, March 04, 2005 7:40 PM
To: Fu Steve X
Cc: 'address@hidden'
Subject: Re: Focus Callback in CDK

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