Shoutbox

Just thought of a small feature which might be nice for plugins; the ability to have a generic "Configuration" option...

Currently most plugins with configuration options use a command to show a dialog. Problem is, until the plugin closes the dialog the command will remain in the input box of the active conversation. This means the person on the other side will see the "X is typing a message" the whole time... kind of defeats it's purpose...

If the plugin API was extended with a Configure function, that could be used instead. This could be triggered using a default "Configure" menu option added to the Plus! plugins menu above the normal commands/tags, if present of course.


The benefits? No command, no "is typing" message, a common way of configuring plugins and it encourages plugin developers to add such a dialog...

That's a good idea. Also, Patchou could extend the API interface and add more events.

The idea is great, there should be a universal function called Conguration or something and when it's called, the developers are supposed to show a form or a dialogue or something...

quote:

---

Originally posted by Choli
That's a good idea. Also, Patchou could extend the API interface and add more events.

---

I hope a direct Nickname change could be included

* Mnjul is coding HopperSi

Well, you will be happy to know that's it's already there then . If you check oneof the screenshots I released this month, in the new Plugin section of the preferences, there's a Configuration button .

wow!! didn't notice that... that's great Patchou !!

edit:

btw, this is the screen shot:

I might aswell post a few of my requests for the Plugin API here

Parse sResult and STextToSend for Tags
Include some functions to get information about a contact e.g.

code:

---

GetPlusCustomName(Email As String) As String

---

<excuse my VB>

(on a sidenote MP!3 is looking to be very good)

I really like the screenshot, and what it will look like in the next version of Messenger Plus 3!! This will be diffentley be a great help for everyone I think and will be excellent where some features dont work togeather very well!!!

CAN"T wait for Plus!!!! (going crazy)

Patchou, if you were female I'd kiss you

...or you could pass that honor to the official Plus! babe of course



Anyways, looking good! I must honestly say I haven't followed the progress that much, I prefer to look at the end product when it's out (thus increasing the "wow!" factor in the end). Allowing the user to choose which plugins to load is a great idea indeed...


I agree with parsing tags in the plugin result, or at least make it an option for the plugin to decide. I included emulation features in my Delphi plugin framework which parses some Plus! tags, but it doesn't solve it all...

It does raise another issue: infinite loops when the output contains a tag which calls the plugin again. I think a nice way to solve that is to flag a plugin once it's been used in a message, then allow all other tags to be parsed (including other plugins) but not the ones which have been flagged. This still allows a plugin to use another plugin's tag in it's output, yet neither the plugin nor the other plugin called can use the first anymore, preventing loops. Hope that explanation was clear, assuming you haven't built that in already as well .



As for the extra functions, that might be nice. If they're gonna be implemented I would get rid of the SendMessage (as used in the toast) though, and instead provide a msgplusapi.dll or something like that... that'd make it easier for plugins, but of course requires some more work from Plus, so it might be good for later...

quote:

---

Originally posted by PsychoMark
It does raise another issue: infinite loops when the output contains a tag which calls the plugin again. I think a nice way to solve that is to flag a plugin once it's been used in a message, then allow all other tags to be parsed (including other plugins) but not the ones which have been flagged. This still allows a plugin to use another plugin's tag in it's output, yet neither the plugin nor the other plugin called can use the first anymore, preventing loops. Hope that explanation was clear, assuming you haven't built that in already as well

---

the loops are a problem. What about if pluging A uses a tag of plugin B and B one of A? If you mark plugings so they are called only once, some tags may not be parsed and if you allow plugings to be called several times then loops may appear.

That's a problem with no good solution...