Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Disabled plugin names

(1/2) > >>

duncanka:
Currently, if a plugin is disabled, it shows up in the Plugins manager not as the true name of the plugin, but as the filename.  Whether this is a bug, an oversight, or (for some strange reason) deliberate, I think it would be more intuitive if the display were consistent.

mandrav:
This is not an oversight, nor a bug.
The plugin's name is provided by the plugin on request. This means that C::B should load (and create a temp instance of) even disabled plugins.
So, disabled plugins just don't get loaded and their filename is displayed in the management window (so you know they 're there).

duncanka:

--- Quote from: mandrav on February 12, 2006, 08:57:31 am ---This is not an oversight, nor a bug.
The plugin's name is provided by the plugin on request. This means that C::B should load (and create a temp instance of) even disabled plugins.
So, disabled plugins just don't get loaded and their filename is displayed in the management window (so you know they 're there).

--- End quote ---
Ah, gotcha.  I see the problem.
But that raises another issue: is there a way to make the plugin information static by DLL?  Maybe have two separate functions for getting the plugin info, one dynamic one (the current getInfo()) and one static one (callable without a plugin instance, and which getInfo() would also call)?  Is there any reason the info has to be initialized in the plugin constructor, and not declared as a static struct?
Sorry if this is a ridiculous suggestion; I don't really know much about DLL linkage.

mandrav:
Well, this whole info struct could be moved to a separate function, outside the plugin's class. Just like the SDK version functions etc.

thomas:
That still requires the dll to be loaded though, otherwise you still can't access the name, so it is not much of a gain.

Navigation

[0] Message Index

[#] Next page