It turns out that everything works as is if the table view has the
"plain" style, rather than the "grouped" style. So, the problem is
really that I didn't account for the fact that a grouped cell will be
horizontally shrunk if the custom cell in the nib file has the full
screen width.
This may in fact cause autoresizing issues (though it didn't in my
case because, as it happens, I had the correct autoresizing masks set
in the first place) and also my code was indeed broken in that it
didn't account for the correct cell content width. It worked for plain
table views because their cells have the full screen width for their
content views.
The solution, besides making sure that the autoresizing masks are set
correctly, is to do some extra horizontal shifting in the case of
grouped cells but, for efficiency reasons, we need to know whether a
cell is grouped or not early on, rather than when the cell is actually
drawn. Otherwise, one would have to implement the delegate method -
tableView: willDisplayCell: forRowAtIndexPath: and do all the math
there, much of which would be the same for every cell.
So, I added a boolean ivar 'inPlainTableView' to my custom cell class
and I set it when the cell is handed to the table view, in the method -
tableView: cellForRowAtIndexPath:, since I can ascertain right there
and then what kind of table view I've got. That way, the cell gets a
chance to do much of the math at load time, caching everything it
needs for the time to draw the cell.
The actual extra horizontal shift is simply the x coordinate of the
cell's 'contentView' in its parent view. Actually, it's *twice* that
for the items that are laid out on the right side of the cell and
which move inward. So, adding
if (! self.inPlainTableView)
{
CGFloat extraHorizShift = 2 * self.contentView.frame.origin.x;
targetDateLabelFrame.origin.x -= extraHorizShift;
targetTimeLabelFrame.origin.x -= extraHorizShift;
}
at the appropriate time, is pretty much all that needed to be done in
my particular case.
The solved sample project, in case anyone is interested, can be found
here:
http://www.restlessbrain.com/auto_res_mask/ARMaskIssue_solution.zip
Wagner
============
Hi Seth,
thanks for answering to my call for help. You make a good point.
Perhaps it is a problem with my code after all. However, not updating
the label positions still causes them to move and if I am not moving
them, someone else is. Anyhow, I created a sample project that still
shows the problem. It can be downloaded from:
http://www.restlessbrain.com/auto_res_mask/ARMaskIssue.zip
Thanks for taking a shot at it.
Wagner
On May 29, 2009, at 11:34 PM, Seth Willits wrote:
On May 29, 2009, at 1:38 PM, WT wrote:
I also tried turning off the "autoresize subviews" option in IB for
the container view (and all 4 elements, not that that should
matter), in the hopes that that would work since I compute the
correct coordinates for all elements myself. Yet, it still didn't
work.
Which seems to confirm that it is *not* a problem with the
autoresizing masks. (And if the containing view is not resizing,
then how could it be?)
I would say some pasted code is in order, here. Can you replicate
the problem in a small sample project?
--
Seth Willits
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
