Looks good to me! I was able to add the plugin and test it.

First, great program. I've moved from Zempt over to this.

Now, the obligatory suggestions :)

- Zempt is able to do bookmarklets for easy posting... SharpMT, sadly, does not appear to be able to. (I got as far as registering a protocol for it, but then realized I've got not way to insert the data). I'd really really really like to see support for this.

- While the plug-ins will work as currently implemented, I think their value is reduced by a) hiding them in the Format menu and b) giving them a prescribed functionality.

The Format menu is very counter-intuitive and I only found it after purposefully looking through every menu.

Worse than its location, though, is that all plug-ins must act within the three parameters, return a list functionality. Right now, if I want a plug-in to take the currently highlighted word, search for it on various ecommerce sites and return a ready-made table of the various prices and changes from the last time I checked... I can't do it.

Ideally, plug-ins would be given the option of doing pretty much anything, any way, and it'd be up to the programmer and the user to determine how best to integrate them into the experience. This would fit in nicely with bookmarklets, because then there would be a way to access the entrytext, title, extendedentry, etc. fields.

I will say the plugins are available on the toolbar, but I'd love to be able to right click and get access to them.

@Bookmarklets... what's a bookmarklet?

@Plug-Ins - like James said: they're on the toolbar, so they aren't all that hidden... in that way, they're just like the custom tags. I also considered using Ctrl+Shift+# as an accelorator, but since the toolbar crashed, I opted not to :)

@Format - it's layed out like Microsoft Office... I figured that a 93% penetration rate would be good enough for me :)

@Plug-In - I had a long debate both with the users and myself with regards to security of the "hole" I'd be poking. Because of this, and the nature of plug-ins, there's no way I can just say "send whatever" and "receive" whatever. There's no way to code for it. SharpMT has to send something, so it needs to know what it's sending: that's where the three params come from. They can be used for anything within the plug-in, but they have to be collected, so text is what I went with. Then on the coming back side, I have to take what is returned, so I need to know what's coming back: I originally view this as a piece of text to insert. Could it be a table? Maybe, if more than one thing is selected, but then there's the question of how to format the table and what use as a delimiter, etc. That's why I expect one string to come in and it goes into the current selected box. I even make sure that I don't overwrite any text when a plug-in is select: I have no way of knowing or predicting that the text should be preserve or anything... but I'll consider the table idea. It all depends on the direction we see plug-ins going.

If you know how the data is going to be returned, you should be able to create a plugin to format tables and such right? If I send a value and get a array returned, why couldn't a plugin format that array however the author wants?

That's what I mean by "selecting" more than one. So like with the example, four lines are returned, so those can become rows. But what sets the columns? How to handle missing columns? What if come columns should span two, or rows that span as well? And then there's the formatting - one of the reasons why there's no insert table HTML tag is because of all of the different table settings between HTML 3.2, 4.0 and CSS... it's a good deal of Hell. At least that's my first thought - even the list box is somewhat new.

Maybe there should be ExecuteList() and ExecuteString()... the first is like Execute() now and returns an array - the other would return a string... in the case of a table coming back, the plug-in would be responsible in formatting a table... also the input dialog would have to know ahead of time (like the Params number) so it could hide the listbox and return to the draft when "Go" is over...

Bookmarklets are Javascript bookmarks in a person's browser that do something. They can either change a page (for example, redoing the stylesheet to get rid of ads) or, if a program is built for it, interact with other programs. (http://www.bookmarklets.com/ for more information. [That site says they only work in Netscape and IE, but, as long as the browser supports JavaScript, it can do bookmarklets])

If you wanted to allow SharpMT to work with bookmarklets, you'd have to set it up to parse command line inputs and programmatically add some keys the registry to make yourself a protocol. (I had set it up as sharpmt: when I was initially trying it).

I completely missed the button the toolbar the first time around... (I think it might be the lack of a tooltip). And I've never used plug-ins with MOffice, so I suppose that explains that... ;)

I guess I should clarify my position about the nature of plug-ins. First, I didn't mean to get everyone hung up on tables. That was just an example--I wanted to make the point that limiting the output of plug-ins at *all* was bad. If each plug-in is limited by your anticipating its release it might as well have been hard-coded by you to begin with.

What I'm picturing now would always involve SharpMT getting a string from a plug-in. And, really, I don't think it should matter to SharpMT what the string looks like, what it conveys, how long it is, if it's plaintext or HTML. It will be a string of some sort and it should be placed where the cursor is.

SharpMT wouldn't be worried about formatting the table--it wouldn't even know that a table was being pushed into the entry, all it cares is that it's a string and it belongs [here].

What would be even neater would be to have the plug-ins creating their own windows, la Winamp. That way, if they don't need any paramaters to be entered by the user, nothing pops up and they just do their thing, but if they need seventeen trillion paramaters, they can do that too. If you do it that way, you can also provide for more robust use of plug-ins in terms of what data can be sent, returned and manipulated.

@Bookmarklets - probably not, at least not for this release... it sounds like a rather robust thing that would take some investigation, so I'll put it on the todo list.

@The toolbar - that's a bug that there were not tool tips! So that'll be in beta 2. And the Format menu is a Microsoft cue, but yeah - if you don't use office it would be new to ya.

@PlugIn - I would make two Executes... one for a list that return an object[] and another for a string that would return. I did consider what would happen if the plugin wanted to make it's own Windows (for input) but I figured that would be a pain in the ass for the PlugIn authors. I could go by way of what IBlogExtension does: have "I've got my own UI" flag and have a third execute that returns a string and skips the UI... I'm thinking that an update to the interface is in order. :)

I'd like to second the request for bookmarklets! MT supports them directly, using their web-based method for creating blog entries, but the whole point of downloading a client is to use that instead. And Zempt does indeed support them, it's just that Zempt is a bit buggy and I'd prefer to use Sharp MT for all my entries.

The way I usually use bookmarklets is when I find a web page about which I want to blog, I right click on it and choose "QuickPost" (that's the MT 3.0 version, in MT 2.x it was "MT it!") or "Zempt This!" and it opens either a web entry page (for the MT version) or Zempt, with a link to the webpage already included as well as any text from that page that I had highlighted when I right-clicked.

It's very handy and I'd love to see it in Sharp MT!

Thanks!