Jump to content

Module registration order


Recommended Posts

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?

Edited by KN_Michael
Link to comment

I doubt that modules are loaded alphabetically. (I suppose that it is more the order in which the operating system is listing the files.)


Mostly however it does not matter. You register the VCOM interfaces you define and then when really something is called in your modules, then alle VCOM interfaces are registered and you can use them.

Link to comment

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

Link to comment

The approved way to get modules to communicate with each other is via interfaces, described here: http://developer.vectorworks.net/index.php/VCOM:VCOM_(Vectorworks_Component_Object_Model). For every plug-in library, write an interface for accessing the classes provided by the plug-in. When you access the interface, you are creating a pointer to it, so by checking if the pointer is null, you can avoid crashed if the plug-in didn’t load or is not present. All the modules register and then run, so the order shouldn’t matter.


If I’m reading your post correctly, you have code that governs registration for one module in another module. This would take it out of the VCOM model, and I don’t think this is sanctioned. Your best options is probably to just share code files among projects, so each .vlb contains an independent copy of your preference-reading code.

Link to comment

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.

Edited by KN_Michael
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...