Nicolas Goutte

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.)

I suppose that it is not possible. BuildResourceList and Co. (be it in C++, VS or Python) do only work on VW document of the current major version (e.g. 2022 document for VW 2022). That has been always that way, for as long as I know VW (i.e. 2007).

We (the interiorcad team) sorted this out by making our own assert-Macro, controlled by our own #define.

No, the whole quantize stuff is a feature of macOS. As long as you use Safari, you will have the problem. May be instead of zipping it , you could pack it in a signed and notarized DMG. (However, personally, I have only put installers in such DMG, not a single VW-Plugin that user could copy. Therefore I do not know it it works.)

Do you ZIP the plug-in and download it per Safari afterwards? Then in this case, the archive is quarantined. You have to de-quarantine the archive before you unpack it: xattr -d com.apple.quarantine archive.zip

Internally VW is metric (in Millimeters to be exact). That is why the exports are primarily metric too.