KN_Michael

Thanks for the ideas and warnings. @JBenghiat Regarding your suggestion: In solution 1 I am not able to edit properties of sub objects via object info pane if I understand correctly, do I? In solution 2 - there is no way to link objects with each other automatically via some constraints, so everything, even moving (as you mention) must be done manually by reacting to events of the parent, correct? I may go with solution 2 even though it means a lot of manual work - I will evaluate this solution though

Is it possible to create nested plugin objects - similar to what walls and doors, windows do? I want to place my own plugin objects inside other plugin objects but what I tried so far does not work, so I wonder about following: 1) Is this technically supported? 2) If yes, how would the process to create such a hierarchy work like?

Background We do push handles and some data into a tree structure and do use those handles quite often for some calculations and updates. This happens inside the idle event. The problem is, that FAST undo/redos SOMETIMES (its very hard to replicate) lead to handles being invalid in the sense of that the handle is not a null pointer but accessing the handle crashes the application with an invalid access exception. This tree data is cleaned and recreated on each file change/open so we only hold handles of the current active document inside the tree. Question Is there a way to validate if a handle is valid? I'd need something like following: bool valid = handle != NULL && gSDK->IsValidHandle(handle) But the second part does not exist... Any ideas how to solve this?

We do this as well but in some old plugins (older than 10 years) we did not do this yet. And additionally we sometimes make conversions that do not depend on the objects version but on the files version (some global conversions)..

We are currently saving some global data like some settings and also our internal file version inside the drawing header. The file version is used to convert our own data between our code versions. We have problems though with this solution with referenced files and also with working files. Whenever a referenced file is updated or we call refresh inside a working file, we must convert the new data from the referenced file or the project file if we are in a working file. Yes, this data can't be saved, but we must update it temporarily so that our tools and plugins continue working because they are designed in way in which they expect all data to be updated to the newest version. We run our conversion routine whenever the current document is changed, a new file is opened and also if a reference is refreshed or a working file is refreshed. Problem We can't access the drawing header of the referenced file or from the file that belongs to the objects that are refreshed in a working file, but we would need to know what the file version is there to decide, which convert function we must run on those refreshed objects. Question Is there another way to save file based data even if we are using referenced files and project files?

Thanks for the alternative solution, but I'm looking for a way to find out the filename of the referenced file that belongs to a symbol. The reason is, we have files with a lot of symbols (thousands, coming from imports) that are only used once and we want to provide a possibility to show our users a list of symbols that should be removed but therefore we must tell them in which file the symbol is defined.

I've seen this function already and checked it but I don't know what to do with the data returned in my case. I get the file paths of all referenced files but what now? I can not check if the symbol comes from this path or not with any function, can I? I did not find any... My only idea now would be to programmatically open each file, check if it contains the symbol and close it again - which is not very useful in my case as I want to show the information for all symbols inside a dialog. And this is not how VW internally does it when you open the resource browser and check the symbols.

I have the handle of a symbol definition and want to know where this symbol comes from. The symbol window shows this information, so at least VW can internally get this name. Can I somehow find out the file name from which a symbol definition comes from as well? VWSymbolDefObj symbolDef = ...; bool isReferenced = gSDK->IsObjectFromReferencedFile(symbolDef); if (isReferenced) { // how to continue here? TXString refFileName = ???; }

So far I'm comparing following: object type, object class, bounding box, object matrix, all values of VWObjectAttr, and all values in VWParametricObj for custom objects. I'm aware that this is a heavy task, but I'm trying to solve it currently. Duplicates come from imports as I've written above, especially from DWG imports. We do NOT control those imports, they come from other companies - so I can't improve anything on this side. We can see that there are apperantly duplicate symbols in the imported data - they are not unique and just differ in rotation or similar (although a smart purge could clean this as well, but this is not what I'm trying to do, that would be too much for now). To answer the why, we have really large files because we have a lot of data in each file so we are trying to optimise whatever is possible. We need to import stuff from other formats where we do not control data nor the format, again a lot of data comes into our files. Last but not least, our colleagues never work perfectly, which additionally leads to the need to optimise layouts... Additionally, we have already created a feature request for this purge command, but we won't get it in the near future (if ever), so I try to write my own solution for now.

Thanks for the feedback. I'm aware that those objects are no plugin objects, my code only shows what I would like to have. Finally I'm trying to write my own purge function for symbols. We are importing a lot into our layouts and therefore I want to find symbols that exist multiple times (I assume sometimes we have 500 symbols that are actually the same). I would like to avoid a switch for each type and handle lines, rectangles and other types on a per type base, I would like a more generic solution (like iterating over every parameter). As this approach is error prone as I may forget a type, may forget a property of a type and so on... I was hoping that build in types do something like this as well. E.g. I can see something like "Coincident Duplicate Objects for" under the purge command - how does this command work? It finds duplicate objects and identifies them as duplicates - is there nothing that this command uses that I can use as well? @JBenghiat, thanks for the code shortening hint

I have something like following: VWObject obj = ...; // object comes from for each iterator e.g. VWParametricObj params = VWParametricObj(obj.GetThisObject()); for (int i = 0; i < params.GetParamsCount(); i++) { // read parameters... } My problem is, that I can't read the parameters of lines, rectangles and other simple build in objects. E.g. if obj.GetType() == kLineNode or kBoxNode, how can I get all existing parameters of this object? Other things I tried: Additionally, I tried GetCustomObjectDefinition, which seems not to work for build in object types. And VWRecordObj, but this does not work either, which makes sense, as I can see, that the build in object types do not contain any aux object of type kRecordNode...

I'm aware of the interfaces and use them. Still having 20 vlbs, I don't want to compile the same code into each and every vlb just for a simple thing like reading a setting file. Sure, it's not much code, but it goes against my coding style to compile the same code into every single vlb... As you are correctly reading, I'm governing which modules get registered for which user on which system and similar... Also, if I want to make a change in one vlb, I compile it, release it and I am finished. If I compile the code into every vlb, I have to recompile new releases for all of them as well and distribute them... If I do not use the VCOM interfaces inside plugin_module_main everything works fine of course and I do use this a lot anyways... I have just problems in this special case.

It does matter in my case. I do register tools, plugins and so on depending on a function from my core module (it reads a setting file). If I rename my core module to XCore.vlb, my Module1.vlb and Module2.vlb are loaded before my core module and calling a function from the core module inside `plugin_module_main` (<= this is the important part, all other code is called only after all modules are registered) will crash because the core module was not registered yet...

Via trial and error I found out that modules seem to be loaded alphabetically. Can I rely on this observation? I have something like following structure: Core.vlb Module1.vlb Module2.vlb And want to use functions of Core.vlb inside the plugin_module_main functions inside my modules. With the naming schema from above this works fine. Is it save to do it this way?

We created a small vs script with only one function in it (http://developer.vectorworks.net/index.php/VS:ReDrawAll) and call this one if we need to redraw the screen. Can be even created "on the fly" from within the code, something like this should work: TXString script; script += "import vs;"; script += "vs.ReDrawAll();"; VectorWorks::Scripting::IVectorScriptEnginePtr vsEngine(VectorWorks::Scripting::IID_VectorScriptEngine); bool outWasCompiledSuccessfully; Sint32 outLineNumberOfSelectedError; TXString outErrorText; if (VCOM_SUCCEEDED(vsEngine->CompileScript(script, false, outWasCompiledSuccessfully, &outLineNumberOfSelectedError, &outErrorText))) { if (VCOM_SUCCEEDED(vsEngine->ExecuteScript(script))) { // SUCCESS... } }

Background I'm trying to calculate connection points between objects by throwing each object I create/edit after creation/change/delete into a custom IVWSingletonUnknown object. In this class I have a simple queue collecting those objects. This queue is processed later on whenever vectorworks reports an idle event (kNotifyAfterPendingUpdate). In the idle event I now process the queue. What happens in the idle event I simply iterate over all objects in the queue, calculate some internal data (like connection point X is connected with object Y's connection point Z) and save this data into the objects (in a custom tag). Afterwards I call gSDK->ResetObject(handle) with every object that has changes - because connections are drawn by each object to be visible to the user. This works fine until I try to undo/redo events Problems I face It seems like that I can't change objects from the idle event without them being pushed into the undo table - I want to avoid this. I see that trying to undo a delete after the idle event regenerated objects is not working anymore - simply nothing is happening in VW although the old handle reappears in code but is not really restored as it does not reappear in VW. Can someone help me with this problem? Can I somehow exclude all actions done in the idle event from the undo system (without clearing the undo table)? I manually take care that objects push theirself into my singleton manager class after restore and before deletion and so on, so I really want that VW ignores any change I make to my objects in the idle event.