Nicolas Goutte

The object types are documented for the C++ function ISDK::GetObjectType: https://developer.vectorworks.net/index.php/VCOM:VectorWorks:ISDK::GetObjectType

Be careful: 1 m is 1000mm but only 100 cm.

OK, the trick seems to be that in PreSave a .swap is triggered on PreSave when the file is about to be overwritten. (Normal "Save" or Autosave on the same file) A .vwx in the other cases. "Save As" (or "Save" with dialog) can be catch by checking the path during PreSave and PostSaved: it is then the same (unlike for "Save Copy As", where it is different) An Autosave on Backup will have no .swap file in PreSave and its path is also different in PreSave than in PostSaved. (I think that these are all relevant cases. It was rather hard to find out.) PS.: all paths are get by ISDK::GetActiveDocument

Using ISDK::GetActiveDocument is no help either, as it still gives the real path of the document, not the one currently used to save. (Tested on Windows)

VW 2022 seems to have changed its behavior and sends the kNotifyDocPostSaved notification, when a backup is made. So my question is: how do I know that the current kNotifyDocPostSaved is due to backup and not due to a regular saving. (I have to do things when the file is saved normally, but not when it is saved as a backup.)

Thank you for the trick. It makes indeed a difference.

The code we are trying is similar to this one. (The crash comes in both cases, the #if 1 case (real documents) or the #else case (empty documents). using namespace VectorWorks::Filing; #if 1 // Opening real documents of Libraries\Default in the VW program folder IFolderIdentifierPtr libraryDefaultsIdentifiier(IID_FolderIdentifier); libraryDefaultsIdentifiier->Set(kDefaultsFolder, false); class Listener : public IFolderContentListener { public: EFolderContentListenerResult VCOM_CALLTYPE OnFolderContent(IFolderIdentifier* pFolderID) override { return eFolderContentListenerResult_Continue; } EFolderContentListenerResult VCOM_CALLTYPE OnFileContent(IFileIdentifier* pFileID) override { TXString path; pFileID->GetFileFullPath(path); if (path.ReverseFind(".vwx") >= 0) paths.Append(path); return eFolderContentListenerResult_Continue; } TXStringArray paths; }; Listener listener; libraryDefaultsIdentifiier->EnumerateContents(&listener, true); for (const auto& path : listener.paths) { IFileIdentifierPtr pathFileIdentifier(IID_FileIdentifier); pathFileIdentifier->Set(path); gSDK->OpenDocumentPath(pathFileIdentifier, false); gSDK->CloseDocument(); } #else // Opening only empty documents for (int i = 0; i < 100; i++) { gSDK->OpenDocumentPath(nullptr, false); gSDK->CloseDocument(); } #endif

We are currently limited by the problem that during a menu command only a limited number of VW files can be opened, because, even if are closing them, they are not immediately closed, but only when the menu command is done. Similarly, such an operation cannot be done either as a migration manager callback. Does somebody knows a way to get around this?

OK, my old Time Machine has still the old versions: - VW 2017 had a Python 3.3 (I suppose 3.3.2) - VW 2018 had already a Python 3.5 (probably 3.5.2)

- VW 2013 hat no Python yet - VW 2014 had apparently Python 3.3.0 - VW 2015 had Python 3.3.2 - VW 2016 had Python 3.3.2 Sorry, I have no VW 2017 and 2018 at hand to check what they had.

VW 2019 and 2020 use Python 3.5(.2) (Stay tuned, I tried to find the older version. I am sure that Python 3.3.3 was used but I do not know which VW)

I do not know a definitive answer to this. We do have our problems with invalid handles at times too. You can check not only that the handle is a nullptr but its dereference (*handle) too. However that is not enough either. The next step is to check its the parent layer return for that object. The layer and its parent should not be null. (Not sure if this is valid for symbols, because in in our code, why have extra code for symbols too.)

OK, thank you for your ideas.

I know only interfaces for handling a plug-ins' part of a migration. However that does not help me, as Batch Convert is triggered by the library conversion part of the migration, something which is pure VW code.

Is there a way to know that a code is called in the middle of a migration or in middle of a Batch Convert? (Both, Migration or Batch Convert, started by a user, not by our code. Therefore I do not have the option of giving a callback to the Batch Convert, as when I call the corresponding SDK call.)