PluginIDs

Posted by WillFa on Thu 25 Dec 2008 07:07 AM — 4 posts, 19,852 views.

USA #0
I'm writing a plugin whose design kinda evolved after noticing LoadPlugin()

The thing I'm noticing is that all the other Plugin functions want a PluginID, and GetPluginID accepts no parameters returning only the current plugin's ID. Is there an easy, direct way to get this for another plugin?

For Example:
PluginA calls LoadPlugin("C:\foo.xml")

How can PluginA get foo.xml's pluginID?

I've thought of the addxml module and parsing the file to get the id entity, or since PluginA uses SQLite, having a temp table that's GetPluginList() before calling LoadPlugin, and GetPluginList() a second time, and using SELECT * from b where id not in(select * from a)... (or a couple of for loops to invert key/value for the first, and if not knownPlugins[k] then heresMyNewId = k ; break )

Am I over thinking the problem? Is there an easy way to get another plugin's id from a file path?
Amended on Thu 25 Dec 2008 07:13 AM by WillFa
Australia Forum Administrator #1
Quote:

Is there an easy, direct way to get this for another plugin?


Another plugin you just loaded?

I suppose the simplest thing would be to call GetPluginList before loading the plugin, turn that into a table keyed by ID (rather than number), call it again after loading the plugin, and then call GetPluginList again. For each entry check if it was already in the previous list (by a simple keyed lookup). If not, that must be the new ID.

Another approach which would be fairly simple would be to read the first few hundred bytes of the plugin file, and with a fairly simple regexp find the id="<whatever>" line.

You could also utils.xmlread as you suggested. It might be a bit of an overkill when the regexp would probably be 99.9% reliable.
Australia Forum Administrator #2
I suppose you have seen this thread?

http://www.gammon.com.au/forum/?id=8767

Loading heaps of plugins can be tedious, and that plugin solved it by simply loading all the plugins it finds in a subdirectory.
USA #3
Over-thought the problem.

Since "Foo.xml" is specifically made to be within the framework of PluginA, Foo can
BroadcastPlugin(n, GetPluginInfo(GetPluginInfo(), 6)) during its OnPluginInstall.

n is arbitrarily decided.

PluginA has an OnPluginBroadcast(msgnum, id, name, txt) function to trap it.


Basically, PluginA shouldn't look it up, Foo should announce it.