==================================================================
The problem:
OriginGroupExtension::OriginGroupExtension () {
initExtensionType(OriginGroupExtension::getExtensionClassTypeId());
EXTENSION_ADD_PROPERTY_TYPE ( Origin, (0), 0, App::Prop_Hidden, "Origin linked to the group" );
}
initializes the Origin property to null.
Then Document::Restore => readObjects => addObject => slotNewObject => ViewProviderDocumentObject::updateView => ViewProviderBody::updateData => ViewProviderGeometryObject::updateData =>
ViewProviderDocumentObject::updateData => ViewProvider::updateData => ViewProviderOriginGroupExtension::extensionUpdateData => updateOriginSize() => OriginGroupExtension::getOrigin,
the latter throws an exception because the origin property is null.
Afterwards, the origin property is initialized during Document::Restore => readObjects => ExtensionContainer::Restore() => PropertyContainer::Restore() => App::PropertyLink::Restore()
=> App::PropertyLink::setValue() => Property::hasSetValue, which triggers an onChange: Body::onChanged => BodyBase::onChanged => Feature::onChanged => DocumentObject::onChanged =>
Document::onChangedProperty => Document::slotChangedObject => ViewProviderOriginGroupExtension::slotChangedObjectGui => ViewProviderOriginGroupExtension::updateOriginSize =>
OriginGroupExtension::getOrigin,
now, the latter that is the same that was throwing the exception and generating the error message above, does not throw anymore because Origin has been initialized.
When creating a new object, isNew==true; whereas when loading a file, isNew==false. Therefore, when loading a file setupObject is not executed. SetupObject, effectively initializes
the extension via: Body::setupObject => DocumentObject::setupObject => OriginGroupExtension::onExtendedSetupObject.
DocumentObject * Document::addObject(const char* sType, const char* pObjectName, bool isNew)
{
[more code here]
// Call the object-specific initialization
if (!d->undoing && !d->rollback && isNew) {
pcObject->setupObject ();
}
[more code here]
As DocumentObject code is generic for all objects (workbenches), by design it was chosen to initialize the object only if new. Therefore a object or an extension of a object being restored,
between the addition (addObject) and the restoring of the properties, must by design expect it not to be initialized.
The solution:
Making use of the Restore flag at document level (the one at object level is not sufficient), no exception regarding the null property is reported during document restoring.
Ticket:
https://freecadweb.org/tracker/view.php?id=2530fixes#2530
* Observed bug: If an ArchWindow has two opening symbols (i.e. two sides
that can be opened), only one was printed in SVG.
* In Draft.getSVG.getPath, some edges got lost in the call of
Part.__sortEdges__. In contrast, Part.sortEdges does not skip edges. All
edges are retained.
* With this fix, both opening symbols are rendered in Draft.getSVG.
* While it works for my test case, I suppose, Draft.getSVG.getPath is
used in some other places as well. Thus, side effects must be checked
by experienced people.
The method execute must create the sshapes and vshapes objects. They must
1. exist in the cloned (parent) object (by calling the execute function)
2. and be copied to the clone object.
Then the SVG rendering in ArchSectionPlan can find it.
