Serendipity Library's libraryStack handler not only checks to see if it is the target of the message, it also checks the state of a local variable to determine if libraryStack has already run once. [I don't want to reinitialize variables once the library is in use:]
A good choice, sorely absent from my example but well worth doing.
Note I do NOT pass libraryStack unless the target is not Serendipity Library, as I see nothing going on that other libraries need to know about. And if they do need to know if Serendipity Library is in use, they can check the stacksInUse property.
While for most practical purposes there will not likely be any other library or backscript that would need to know when a libraryStack handler is sent to your library, it is a possibility. While admittedly unlikely, over the years I've come to regard "unlikely" as "possible", and "possible" as "will happen sooner or later". I've found a majority of issues in using my work in other people's environments stem from making assumptions about the environment, which has led to my personal policy of always preserving the native state of things wherever I have the opportunity to do so.
Requiring polling the stacksInUse is less efficient for that purpose, but on balance if another stack needs an event-driven method the best place for that might be in a frontScript anyway.
Given that a library should always perform those two checks anyway (to see if it is the target of the message and whether it's been initialized already), what is the downside to passing that system message just as one would usually want to pass all others?
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
