These are two different conceptions of object order. Cindy's relates to the
order of the objects in the table, Mark's to their order on the viewing
screen. They are both unrelated as far as I understand it.
In a table, first come first served, they are in the order they are created,
or in that obtained from a SELECT... ORDER BY followed by a save of the
selection results. Several editing operations will change that order, such
as a combine (all basic objects are deleted, a new one added). The order in
the table is given by ROWID.
That record numbering system is altered only when a PACK is done, but not by
a plain SAVE (incidentally, a SAVE COPY AS acts as a PACK, is faster and
does not close the original displays). Greyed out (deleted) rows are
eliminated and rowid are reassigned. The object numbers in a workspace are
not affected then until a PACK is done. If an object has been deleted and
the workspace reopen, its label will not show of course but no error will
appear.
But after a pack, the absolute order is changed to the new compacted rowid
list (the relative order is conserved). One can of course correct object ids
in a workspace if he has both rowids before and after packing. That would
require adding a column updated with rowid before packing, and another with
rowids after packing. These 2 columns will give you the exact corrections to
make. One has to think about it before packing, if not ... One can also
imagine another scheme working with two tables as obtained with the SAVE
COPY AS approach.
Display order of objects depends essentially on how MI graphic motor works.
Its logic is basically not rowid. Much depends on which objects are involved
in the display window; different zooms may give different "orders". A good
proof is that "labels" specified as text objects in a workspace are
generally not in the rowid order.
The trick given by Mark of cutting and pasting the "bottom" objects to make
it appear on top works sometimes, but is a temporary solution. As soon as a
save is made, or if you pan out of that object and return on it later, the
internal "display logic" will take over and the previous "imposed" order may
not be respected.
There still are "dark" corners in all that, and I would like to hear more
about it.
Jacques Paris
============================================================
e-mail [EMAIL PROTECTED]
alternate [EMAIL PROTECTED]
gis activity (MapInfo mainly)
http://www.total.net/~rparis/gisproducts.htm
============================================================
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Knudsen
> Good Question! And I have absolutely no idea what the answer is.
>
> I doubt it is as sensible as any of the suggestions you made.
>
> It seems to be related to the last edited object. If you cut and
> past or delete and undo an object is USUALLY appears on top of
> the heap. But not always - and I haven't been able to work out
> any logic to how it works (for instance if it doesn't end up on
> top, try it again and it often does - go figure!).
....
> __________________________________________________________________
>
> -----Original Message-----
> From: Cindy Reid
> Sent: Monday, June 21, 1999 7:45 AM
> As I am painfully aware, obj order is very important in maintaining an
> appropriate link between a file, and the instructions within the
workspace.
> As I was sitting here "repairing" a map in which the labels rotated due to
> the re-creation of two of the objeccts, thereby making Object 23, Object
> 21, I was lamenting how futile that process seems. I mean, I seem to be
> faced with only two options. 1) Change the reference in the workspace
> itself (ie change the object number where it has be written by the
> workspace) or 2) relabel everything on the map, making sure that
> each labelis now in its correct place.
>
> But..... there has to be a better way. Then, as I thought about that
more,
> I realized that I fundamentally don't understand how MapInfo "thinks"
about
> object order. Is it truly tied to rowid? So that obj 1 is the first row
> in the data? Or is there some other hierarchy?.... If Obj 1 is the first
> row (record) in the data, then how does it account for unpacked records
> (cuz they are counted as rows by rowid). How can you figure out which
> object number goes with which object? If you could do that, then
> you could add a field to any table from which labels will be called, then
> simply sort on the obj_id, returning the "new" obj to it's place in the
table....
> But that assumes that MI thinks about objects in record/row order,
> not in order of creation......
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
