Plugins must not use code internal to PaintDotNet.exe

[Rick Brewster]

This is a new change in v3.30 -- all the code that is in PaintDotNet.exe is now marked as internal. This will break any plugin that was referencing this code, which is something that was not supposed to be allowed anyway. However, no hard feelings -- as it turns out, in Visual Studio 2003 you couldn't do this because the IDE would not let you add an EXE as a reference. So I never marked this code as "internal". In 2005 this was changed, but I did not realize it for quite some time and still never marked things as internal. Also, I have never published any comprehensive documentation for plugins, especially of the "do this, don't do this" variety.

Going forward, if you want to use code from PaintDotNet.exe then my recommendation is to copy the code from the source code release into your project and use that copy instead. This will let you use controls such as ColorWheel, while also allowing me to change them without affecting your plugin.

[pyrochild]

Now you tell us

[KrisVDM]

This will let you use controls such as ColorWheel, while also allowing me to change them without affecting your plugin.

Rick, I don't know if you followed the discussion on viewtopic.php?f=16&t=22881, but basically they're begging and calling me names because I dropped the color wheel from the Drop Shadow UI.

I know I said so before, but I believe many effects and adjustments could benefit from a color wheel (or even tow for my duotones) in the effect UI.

Would you please consider adding Indirect UI support for colors?

Alternatively, could you give us some pointers on how to add your own controls to Indirect UI dialogs? I haven't looked for long, but did not see an immediate way to do it.

Kris Vandermotten.

http://www.u2u.info/Blogs/Kris/

[BoltBait]

Alternatively, could you give us some pointers on how to add your own controls to Indirect UI dialogs? I haven't looked for long, but did not see an immediate way to do it.

The IndirectUI system is a closed system and is not designed to be extended.

I know I said so before, but I believe many effects and adjustments could benefit from a color wheel (or even tow for my duotones) in the effect UI.

Would you please consider adding Indirect UI support for colors?

This would be a huge boon to us plugin developers.

Please, Rick?

[KrisVDM]

The IndirectUI system is a closed system and is not designed to be extended.

That was my impression as well :-(

This would be a huge boon to us plugin developers. Please, Rick?

That's two votes and counting ;-)

[pyrochild]

That's two votes and counting ;-)

I see that neither MadJik nor myself seem to exist anymore...

[Rick Brewster]

Clearly an IndirectUI color picker is much more important than it was, especially now that the code is marked internal. I'll look in to it.

[KrisVDM]

Clearly an IndirectUI color picker is much more important than it was, especially now that the code is marked internal. I'll look in to it.

Thanks Rick, we love you (always have ;-))

[Simon Brown]

Clearly an IndirectUI color picker is much more important than it was, especially now that the code is marked internal. I'll look in to it.

Could you also move it to a different DLL so that people not using DirectUI can access it as well?

[Rick Brewster]

Could you also move it to a different DLL so that people not using DirectUI can access it as well?

No. As I stated above, my recommendation is to make a copy of the control's code and to put that into your project.

P.S. It's "IndirectUI", not DirectUI... the latter is actually a Windows-internal UI toolkit

[Rick Brewster]

By popular demand... (currently in private testing... will be in the next beta update for all to use though)

(also, adding the color wheel to Bulge is just for show, it isn't actually using it)

(and yes, because this is IndirectUI, even file type UI can use this ... not sure why you'd want to, but hey I"m not one to judge )

[jchunn]

Impressive response time on that feature. Good work sir.