|From:||Fu Steve X|
|Subject:||RE: Core dump in the latest CDK|
|Date:||Wed, 4 Jan 2006 14:57:03 -0500|
Actually the core dump was caused by a bug in my code -- I called destroyCDKScreen from a callback function. But It didn't bomb before.
I am in the process of testing my application with the new CDK. Will let you know more.
From: Thomas Dickey [mailto:address@hidden]
Sent: Wednesday, January 04, 2006 8:46 AM
To: Fu Steve X
Subject: RE: Core dump in the latest CDK
On Wed, 4 Jan 2006, Fu Steve X wrote:
> I don't use menus. Thanks!
I know that I have some email describing what you're doing with TAB,
but it would also be helpful to see how you're adapting traverse.c
> Steve Fu
> -----Original Message-----
> From: Thomas Dickey [mailto:address@hidden]
> Sent: Wednesday, January 04, 2006 8:18 AM
> To: Fu Steve X
> Cc: 'address@hidden'
> Subject: RE: Core dump in the latest CDK
> On Wed, 4 Jan 2006, Fu Steve X wrote:
>> Yes, I use CDK with Solaris Curses.
>> Now I know what happened. As discussed in the thread below, I moved the
>> InjectObj (curobj, key) in traverseCDKScreen around in order to register
>> callbacks for the TAB and ESC keys. That was in the previous version of
>> Now I do the similar thing in the new CDK, moving the call InjectObj
>> (curobj, key) to the first line in traverseCDKScreen. Callbacks for TAB
>> ESC work but that causes core dump.
>> Is there any way to get the callbacks for TAB and ESC to work correctly
> That's going to take some more thinking. In the current snapshot, I was
> looking at complaints from three different people who wanted to change
> traverseCDKScreen in different ways. I addressed part of this by making
> that a simpler function which calls reusable pieces.
> So it would be "simple" to solve your problem with ESC by making a new
> function corresponding to traverseCDKScreen() which doesn't use menus
> (I forget if you want to use menus).
> However, TAB is still embedded in the logic of the traverseCDKOnce()
> function. Also, traverse.c doesn't have its own key bindings. I think
> that's the problem we have to address.
> One thing that I have in mind to reduce some of this is to make Cdk use
> virtual bindings (keycodes unrelated to curses) as I did in dialog. Doing
> that would get rid of the literal KEY_TAB in the case statement, moving it
> to a binding table (which could then be altered).
> > > Thanks!
>> Steve Fu
>> -----Original Message-----
>> From: Thomas Dickey [mailto:address@hidden]
>> Sent: Tuesday, January 03, 2006 3:33 PM
>> To: Fu Steve X
>> Cc: 'address@hidden'
>> Subject: Re: Core dump in the latest CDK
>> On Tue, 3 Jan 2006, Fu Steve X wrote:
>>> I started to look at version 20051230. Some fixes works well such as the
>>> setCDKFocusFirst function and getting rid of multiple highlighted widgets
>>> when first popping up. Thanks so much!
>>> Please take a look at the core dump below. Thanks.
>> Is this with Solaris curses? There could be some place where it returns
>> a null WINDOW pointer that ncurses does not. A quick check with ncurses
>> and valgrind isn't showing me a problem.
>> The quick fix of course would be to add a null-pointer check in
>> fixCursorPosition(), but it would also be good to fix whatever problem is
>> producing the null-pointer check.
>>> Steve Fu
>>> ------------------------ cut here -----------------
>>> program terminated by signal SEGV (no mapping at the fault address)
>>> 0xffffffff7e225d50: wmove+0x0020: ldsh [%i0 + 6], %g4
>>> Current function is fixCursorPosition
>>> 215 wmove(InputWindowOf(widget), ypos, xpos);
>>> (dbx) where
>>>  wmove(0x0, 0x1, 0x1, 0x1b, 0x232d, 0x0), at 0xffffffff7e225d50
>>> => fixCursorPosition(widget = 0x100280670), line 215 in "scroll.c"
>>>  _injectCDKScroll(object = 0x100280670, input = 27U), line 375 in
>>>  traverseCDKOnce(screen = 0x100185950, curobj = 0x100280670, keyCode
>>> 27, functionKey = 0, funcMenuKey = 0x10005c1c0 =
>>> &`assn.exe`traverse.c`checkMenuKey(int keyCode, int functionKey)), line
>>> in "traverse.c"
>>>  traverseCDKScreen(screen = 0x100185950), line 370 in "traverse.c"
>> Thomas E. Dickey
> Thomas E. Dickey
Thomas E. Dickey
|[Prev in Thread]||Current Thread||[Next in Thread]|