Actually the glitch wasn't anything to do with TblGetItemInt -sorry.
The problem I had was with the new OS 3.5 approach for calling a table's
custom draw routines. They can now be called for any column and any row
and for many reasons. In previous OS's the calling sequence of the draw
routine was just for when a complete table redraw was required. It was
quite predictable and I had made use of this for optimisation logic.
I've now addressed the problem in my code but I thought you all might like
to know about it. I'm sure the new table redraw logic will break other
apps just as it did with mine.
Incidentally, some release notes for 3.5 would be nice. On the whole I
really like 3.5's way of doing things; it'd just be nice not to have to
spend hours discovering them! :-)
Christopher
Christopher Hunt wrote:
> Hi there,
>
> When I tap on a row in a table, the highlight returns the contents of
> the last row on the screen! In other words, the highlight is not
> inverting what is being tapped on. I also have problems with tables in
> other areas which I think could be related.
>
> I see that there's been some OS 3.5 changes with the way that
> TblSelectItem performs. Instead of merely inverting the contents of a
> column, the table is now called upon to redraw the column.
>
> I find this to be a good idea, but what I also find is that a call that
> I make to TblGetItemInt from within my draw routine results in a bus
> error. I store all sorts of things in sorts of columns and so need to
> have the entire table structure and anything it relates to available.
>
> Is this a glitch with 3.5?
