Moving table based on size/position of other table

Question

Level 1

49 points

Moving table based on size/position of other table

I have a feeling there's an easy fix to this... or there's no fix at all... but here goes:

I want to use Table 2 to show "total time" as the sum of all the times from Table 1. Table 1 is set to automatically filter out certain rows (basically, it creates a dynamic playlist based on certain criteria). What I want is for Table 2 to "float" a certain amount below Table 1, so that as Table 1 grows or shrinks depending on the filtered amount of content, Table 2 stays the same distance from the bottom of Table 1. Is this unreasonable? It seems I've seen tables "push" other tables around depending on size changes (not the desired effect in those cases, but what I DO want here).

MacBook Pro, OS X El Capitan (10.11.2), 2.4 GHz i5, 4 GB SDRAM, 500 GB SSD

Posted on Feb 9, 2016 10:49 AM

Reply

Answer 1

Best reply

Barry

Level 9

59,861 points

Feb 9, 2016 12:26 PM in response to macmikey

Hi mikey,

This seems to be the default behaviour in Numbers '09, but the feature may not have been included in Numbers 3. I'm sure someone will test and report on that before long.

Demo below is in Numbers '09.

Lower table is a duplicate of the upper one. After positioning the lower table directly below the original, I inserted two rows into the original and watched it 'push' the lower one further down, maintaining the space between them.

I reformatted the cells in column B to Checkbox, and checked a few of them.

Then I opened the Reorganize pane. and set the filter ("Show rows…") rule displayed:

Clicking the 'Show rows…' box produced this result:

Note: I had selected all non-header cells in column B before engaging the filter. The first image was captured after unchecking the 'Show rows…' box, expanding the table and leaving only the cells in the (previously) filtered rows selected.

As noted, the example is in Numbers '09/ Numbers 3 behaviour may differ.

Regards,

Barry

Reply

Answer 2

macmikey Author

Level 1

49 points

Feb 9, 2016 12:31 PM in response to Barry

Barry, this behavior is inconsistent in Numbers 3.6. Surrounding tables move sometimes, but not with any predictability or recognizable method. Sometimes they'll move, sometimes they'll sit still and "dynamic" tables will lay over top of them. I remember this working more reliably in Numbers '09, and would just use that one... if I didn't need other features in Numbers 3 more. Sigh...

But thanks for your insights. At least I now know I'm not crazy. (At least, not because of this!)

Reply

Answer 3

Barry

Level 9

59,861 points

Feb 9, 2016 3:38 PM in response to macmikey

Hi mikey,

Some things you might try in try to increase 'predictability'. Substitute "top" and "height" for tables in a horizontal row.

Align left edges of vertical stacks.

Make both tables the same width (and align as above).

Add a floating object (eg. long narrow rectangle) between the tables.

Haven't tried any of these, as I'm not running N 3, but it's the line of investigation I'd follow.

Regards,

Barry

Reply

Answer 4

macmikey Author

Level 1

49 points

Feb 10, 2016 9:30 PM in response to macmikey

Numbers 3.6 doesn't seem to respect aligned edges, table widths, or floating objects. When one table changes sizes, the other tables just sit there like idiots. Stupid Numbers.😐

I did have some success by just creating a final row in the offending table. Of course, this limits the number of lookups I can do, but as I'll likely never have a playlist longer than 30 songs, I think I'm in the clear. Oh well.

CORRECTION: They usually sit there. Occasionally they'll move--if they've been covered by a table that they failed to move with when it changed size the first time. When I would undo the size change, the lower tables would move in some inconsistent way toward where they'd come from. (That is, they'd head in the right direction, but never actually end up in the exact spot they'd been in.) Again, stupid Numbers.

Reply