> > If I were faced with the same problem, I'd be working to find out why r and
> > bounds are apparently incorrect. I wouldn't want to shoot blindly by
replacing
> > seemingly unrelated libraries.
>
> Indeed, which is why I was loathe to copy any libraries around. Trouble is I
> wouldn't know where to start to find out why the values get set incorrectly
Well, the way I would go around it may not work for everyone. But it's what I
would do, and it usually results in getting the problem solved.
So your callback routine is being passed values that you think are incorrect.
Does gdb debug at the assembly level? I will assume that it does. If not, you
may want to work with a different debugger. PalmDebugger works at the assembly
level, but that runs only one Mac and Windows. There's another debugger out
there called "debuffer". That one runs only on Mac and Windows as well (though
the author only maintains the Windows version, and the Mac version is lagging
behind), but the source code is provided, so you can port it to Unix. I did the
Mac port, and it only took about a day.
Using the assembly-level information, I'd look at the parameters on the stack.
The prototype for the table callback function is:
void TableDrawItemFuncType(void *tableP, Int16 row, Int16 column,
RectangleType *bounds);
Using my knowledge of how parameters are passed on the stack, I'd know that the
stack looked like this after the LINK statement at the beginning of my callback
function was executed:
| previous stack |
| contents |
+----------------+ <- A6 + 20
| rP |
+----------------+ <- A6 + 16
| col |
+----------------+ <- A6 + 14
| row |
+----------------+ <- A6 + 12
| tbl |
+----------------+ <- A6 + 8
| return address |
+----------------+ <- A6 + 4
| old A6 |
+----------------+ <- register A6 points here
I could then find the value of A6, and then dump memory from that location,
examining the values pushed onto the stack.
If the memory location containing "row" contained the correct row number, than
I'd know that the problem was in my callback function. I would then try to
examine the code to see what went wrong.
If the memory location containing "row" contained zero when it shouldn't, then
I'd know that the Table Manager pushed the wrong value on the stack. I'd then
try to figure out why. At that point, I'd probably start tracing execution at
the assembly level. The Table Manager obviously should be in some sort of
nested loop, iterating over rows and columns, calling your callback function for
each one. The question is, why does the "row" loop variable appear as zero on
the stack?
So, I'd start tracing at the assembly level, using my reading knowledge of 68K
assembly along with the posted source code for the Table Manager. I'd start
with putting a breakpoint in my callback routine. Once I found that the "row"
value on the stack wasn't what I thought it would be, I'd single-step until I
got the RTS at the end of my callback. I'd then continue to single-step back
into the Table Manager routines, and attempt to match the assembly code with the
source code. I'd find out what memory locations or registers contained "row"
and "col" and see if they contained the expected value. If not, then I'd try to
find out why not.
By the way, I should also say that I would make sure that my statement of the
problem is correct. For instance, I'd check to make sure that the number of
rows and columns in the table isn't set to zero for some reason. After all,
that would explain why only zero was passed to your callback routines.
Anyway, that's how I'd approach it. I'd make hypotheses, get more information,
determine causes, test assumptions, etc.
Hope this helps,
-- Keith Rollin
-- Palm OS Emulator engineer
Simon Drabble <[EMAIL PROTECTED]> on 01/17/2001 03:00:11 PM
Please respond to "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent by: Simon Drabble <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
cc: (Keith Rollin/US/PALM)
Subject: Re: odd behaviour in pose
On Wed, 17 Jan 2001 [EMAIL PROTECTED] wrote:
>
>
> I've never heard of anything like this. The problem seems so "odd", as you
> appropriately put it. That's the only difference you see? And everything else
> is the same? You're using the same ROM image? You're emulating the same
device
The only difference is in the rendering of tables. Forms without tables render
fine.
> with the same RAM size? Is the 'pose' binary the same -- or was it compiled
> separately on the two machines? If the latter, was the same compiler used?
> Could there be some code generation problem?
Same binary (I copied it over), but was also happening with a freshly-compiled
binary on the troublesome machine. Same rom image, mem size, and emulated
machine.
>
> If I were faced with the same problem, I'd be working to find out why r and
> bounds are apparently incorrect. I wouldn't want to shoot blindly by
replacing
> seemingly unrelated libraries.
Indeed, which is why I was loathe to copy any libraries around. Trouble is I
wouldn't know where to start to find out why the values get set incorrectly --
the reason I thought libX might be to blame is because I imagine pose gets
sent some sort of window drawing events, but I know nothing about X
programming so I'm probably wrong here.
Any ideas how to go about tracking this down? I'm completely stumped..
Thanks,
Simon.
>
> -- Keith Rollin
> -- Palm OS Emulator engineer
>
>
>
>
>
>
> Simon Drabble <[EMAIL PROTECTED]> on 01/17/2001 07:11:21 AM
>
> Please respond to "Palm Developer Forum" <[EMAIL PROTECTED]>
>
> Sent by: Simon Drabble <[EMAIL PROTECTED]>
>
>
> To: "Palm Developer Forum" <[EMAIL PROTECTED]>
> cc: (Keith Rollin/US/PALM)
> Subject: odd behaviour in pose
>
>
>
> Running pose on my home Linux box (Suse 6.4, kernel 2.2.14) I have no problems
> (well, except those caused by my code :) ).
>
> Running on an almost identical machine (identical except for the X server &
> libX11) pose does not get the row & bounds parameters correctly in table draw
> data callbacks:
>
> static void DrawMainTableItem(VoidPtr table, Word r, Word c, RectanglePtr
> bounds)
>
> Stepping through my code in gdb, r is always 0 and bounds always the top row
> of the table -- I have multiple tables on different forms using different
> callbacks, and the values are always the same. Also for table load data
> callbacks.
>
> Not sure what might be causing this, although the near-identicality of the
> two machines tends to point the finger at X somehow being at fault.
>
> Has anyone else encountered this? is there a fix? I guess I could copy over
> the relevant X server and libraries but I'm only willing to do this if
> absolutely necessary.
>
>
> Simon.
>
>
>
>
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
