Module registration order

[KN_Michael]

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 May 2, 2019 by KN_Michael

[Nicolas Goutte]

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.

[KN_Michael]

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

[Nicolas Goutte]

Ah yes, then it is problematic. I do not know if this is the recommended way to do that or if there would be another. 

[JBenghiat]

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.

[KN_Michael]

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 May 3, 2019 by KN_Michael

[Nicolas Goutte]

I would say that if it has worked that way for you until now, then you should keep it.