Get the field setter plugin here: http://cs.rthand.com/blogs/blog_with_righthand/archive/2006/07/11/1192.aspx

Cool!

Do you want us to host your add-ins in the 3rd party section?

Otis wrote:

Cool!

Do you want us to host your add-ins in the 3rd party section?

I prefer hosting it at home (literaly ) beacuse it gives me free hands. However, it would be nice to have a link (or did you have in mind that SVN of yours?) there. (where is this 3rd party section?)

BTW, here are my wishes for enhancing plugins:

• enable persistence of plugin parameters (of course, plugin has to support it, too)
• when you have the above feature, you can enable running plugin from command line

mihies wrote:

Otis wrote:

Cool!

Do you want us to host your add-ins in the 3rd party section?

I prefer hosting it at home (literaly ) beacuse it gives me free hands. However, it would be nice to have a link (or did you have in mind that SVN of yours?) there. (where is this 3rd party section?)

We don't have that at the moment in the download system, but I can re-create a page in the CMS with 3rd party links to resources like your plugin

BTW, here are my wishes for enhancing plugins:

• enable persistence of plugin parameters (of course, plugin has to support it, too)
• when you have the above feature, you can enable running plugin from command line

The plugin could save its state to a .xml file of course and load it again when it's started?

Otis wrote:

We don't have that at the moment in the download system, but I can re-create a page in the CMS with 3rd party links to resources like your plugin

That would be nice.

Otis wrote:

mihies wrote:

BTW, here are my wishes for enhancing plugins:

• enable persistence of plugin parameters (of course, plugin has to support it, too)
• when you have the above feature, you can enable running plugin from command line

The plugin could save its state to a .xml file of course and load it again when it's started?

Actually I am already doing this (well, not save, just load) through application settings. But I had a slightly different feature in mind. You could provide a mechanism for saving those xmls using different names. And likewise one could load named set just by picking a name from a combo box. In that way each plugin could have many different sets (imagine a very generic plugin that does many things) and you could easily invoke it from command line using correct property set.

Though a plugin could do that now as well, although it then would mean that the plugin's settings responsibility is moved from llblgen pro to the plugin.

So a plugin, which has a setup-tab, could offer different pre-sets.

Otis wrote:

Though a plugin could do that now as well, although it then would mean that the plugin's settings responsibility is moved from llblgen pro to the plugin.

Exactly.

Otis wrote:

So a plugin, which has a setup-tab, could offer different pre-sets.

Yes, and user could even store new ones or modify existing ones. Something similar to the presets of the generator.

Ok, but isn't this up to the plugin-writer? Or do you mean: the plugin should specify a set of xml documents and pass it as return types on a method call, so llblgen pro can call the method and store the xml documents and vice versa: when the plugin is loaded it gets handed a set of xml documents which are read by the designer ?