GUID

[vfrontiers]

Is it something I'm doing, or is it inherent in the system.

I've got an old part created some years back. Yesterday, I wanted to update it and SAVE as an AC12 object. All works just fine until the next time I open the file.

The old part AND the new part have the SAME GUID... so every instance of the NEW part that I placed (with new features) is now replaced by the OLD part and are missing all the new features.

These particular objects are actually LABELS, so I can't use the REPLACE w/ PARAMETERS feature of regular objects.

Anyone?

[Barry Kelly]

And here is the open library part by subtype dialogue with just the DOOR(WALL) subtype selected.
It has the same GUID as the library part editor.

I would have thought the library part editor would show the library part GUID but apparently not.
Hence why it doesn't change when you duplicate (save as) a library part.

[Anonymous]

Hello,

Converting the object to XML with LibDev Toolkit gives following info of the GUIDs;

<?xml version="1.0" encoding="UTF-8"?>

<Symbol UNID="{D20C9049-8F3F-11DA-A9BA-000D9344841C}-{870979BF-268E-4ACC-95DA-36A414FADA41}" Owner="1196638531" Version="23" Signature="1196644685" IsPlaceable="yes" IsArchivable="no">
<Ancestry SubIdent="0" Template="no" SectVersion="1" SectionFlags="0">
<UNID>{F938E33A-329D-4A36-BE3E-85E126820996}-{6CBED0C3-B08B-400F-AEC9-9625C3F2321D}</UNID>
<UNID>{103E8D2C-8230-42E1-9597-46F84CCE28C0}-{257A7271-109C-4C99-821D-566C0EAB2395}</UNID>
</Ancestry>

<!-- GDL SCRIPT ===== GDL SCRIPT ===== GDL SCRIPT ===== GDL SCRIPT ===== GDL SCRIPT -->

When the object is converted back to GSM the first part of the UNID {D20C9049-8F3F-11DA-A9BA-000D9344841C} remains static.

[Rob]

Converting the object to XML with LibDev Toolkit gives following info of the GUIDs;

<?xml version="1.0" encoding="UTF-8"?>

<Symbol UNID="{D20C9049-8F3F-11DA-A9BA-000D9344841C}-{870979BF-268E-4ACC-95DA-36A414FADA41}" Owner="1196638531" Version="23" Signature="1196644685" IsPlaceable="yes" IsArchivable="no">
<Ancestry SubIdent="0" Template="no" SectVersion="1" SectionFlags="0">
<UNID>{F938E33A-329D-4A36-BE3E-85E126820996}-{6CBED0C3-B08B-400F-AEC9-9625C3F2321D}</UNID>
<UNID>{103E8D2C-8230-42E1-9597-46F84CCE28C0}-{257A7271-109C-4C99-821D-566C0EAB2395}</UNID>
</Ancestry>

<!-- GDL SCRIPT ===== GDL SCRIPT ===== GDL SCRIPT ===== GDL SCRIPT ===== GDL SCRIPT -->

When the object is converted back to GSM the first part of the UNID {D20C9049-8F3F-11DA-A9BA-000D9344841C} remains static.

that is exactly what I thought - GUID is just a set of pointers to data structures as you can see them exploded with XML.

[vfrontiers]

Update...

I just created a new label (based on an old one that I created [btw, I have to do this to keep legacy projects working every time we upgrade to the new version of AC12])...

Anyway.. created LABELv12...

I place it in my drawing
All is fine
Close / Open up file again
Library report says the LABELv12 is missing
All labels previously placed show the big GDL DOT OF DEATH
Label tool shows this label as AVAILABLE in the pull down menu.
Select all labels / replace with the LABELv12
All is fine
close / open
-repeat ad infinitum.....

Can we get this right please! I know I will forget to check this next time I print and it will be a disaster.

[vfrontiers]

Can anyone explain this?

[Rob]

Duane,

strangely enough I have experienced the very same problem with my custom label. It seems to be a bug.

[vfrontiers]

If someone has 15min to waste on diagnosing this, could you follow these steps...

1. Install this label into your library.
2. Make it the auto label for walls
3. Draw a wall and auto label it (with this label, of course)
4. Select label and OPEN LIBRARY PART
5. Save Label with a new name
6. Select Label in plan and change it to the new one (do not RE-ASSOCIATE, just change the type of label)
7. Close, then open the file.
8. Check to see if the label STAYED with the new one or reverted back to the old one.

Also,
9. Delete the original label from your library
10. Close and open file and see if the placed label comes up missing.

[Erika Epstein]

Duane,
I followed your steps.

-After the first close/reopen file Yes, the marker reverted back to the first one.

- after the second close/reopen file all markers showed as dots/missing library part.

I selected and opened the label, yes it said it was missing. Re-selecting it brought the labels back. But reopening gives dots.

[vfrontiers]

Erika wrote:
Duane,
I followed your steps.

-After the first close/reopen file Yes, the marker reverted back to the first one.

- after the second close/reopen file all markers showed as dots/missing library part.

I selected and opened the label, yes it said it was missing. Re-selecting it brought the labels back. But reopening gives dots.

Thanks for verifying....

GS... Fix please....

[vfrontiers]

Even if you don't test, please feel free to download the LABEL... It's a kinda cool little tool that ASSOCIATES to a wall and reads the TOP or BOTTOM or BOTH and can also show elevation relative to SEA LEVEL (simple user input).

For some reason, the REAL ELEVATION tool does not GRAVITATE to walls, so this was needed for me.

Only works on LEVEL parapets (reads the wall top as typed in, won't read SEO tops)..