Parent Application Window Handle for Load/Save Custom Dialog

[evanolds]

I have custom windows that popup for loading and saving formats in one of my plug-ins. Is there some way to get the handle (other than hectic WinAPI calls) of the parent application window so I can call myform.ShowDialog(hwnd) and have it so the user can't flip back and forth from my window and the PDN window?

If not, will there be some interface for this in future versions?

[Rick Brewster]

What kind of custom save functionality UI do you need? (screenshot?) How does it go outside the scope of the current SaveConfigWidget stuff?

The load config UI is something I'd like to do for v3.0, we just never had a file format that needed it so we couldn't have done any testing or anything.

[evanolds]

Well the main reason I would think a custom save UI would be needed is for an animated format (animated GIF or animated cursor for example). The current save dialog...

... is fine for a cursor, but what about providing a preview of an animated cursor? Ok, so I haven't yet even started working on the animated cursor exporter, but there also was motivation for me to use a custom UI for the loader, which seemed to have an effect on the saver.

Since there isn't yet a setup for a default loader UI, as there is for the saver, my current icon loading plug-in analyzes the file and provides the user with a prompt to load a specific image within the file, since the icon files usually have multiple images within them. This is not a layered format so, while I did add the option to let the user load all available images, each as a separate layer, I felt it would be inappropriate to do so automatically, since they'll often probably just want one image from within the file.

So now I have my custom dialog that pops up to let the users choose a specific image in the icon file:

http://www.evanolds.com/images/icocuraction.png

This dialog always pops up if there is more than one image within the file.

Now this I haven't checked, it was more of an assumption so I apologize if it's incorrect, but I figured the regular save dialog, when it renders the preview, saves to some sort of temporary stream and re-loads from that stream to make the preview. If this is the case then I can't have my custom save code save multiple images to the file and have the preview created automatically, because then the load dialog would pop up.

So now here is my custom save window:

It provides "quick and easy" (I hope the users agree with that) ways to save multiple images in the file just by clicking check boxes and radio buttons. I could easily make the save config widget have those check boxes and radio buttons in it and use the default save UI, but then I am concerned about the multiple image fact spawning the loader dialog.

I think the default save UI is good the way it is, I would not ask that it had support for animated previews or anything, but I think custom dialogs will be desired for certain formats. I'm hoping to get animated cursor support in and if the other guy I saw posting about an animated GIF plug-in doesn't come through I may put that on my todo list as well, so animated formats will be the main thing. Please let me know if the issue I described about PDN using the loader to create the preview in the default save dialog is in fact valid, although I'll look through the PDN source if I get a chance to see for myself.

So I guess if there's not a work-around then I'm requesting a developer related feature, that being the ability to have a IWin32Owner (or whatever the class name is... can't rememeber, can't look it up have to run in 2 minutes) parameter passed to the saving code so the custom dialogs can be created with the PDN window as the parent window.

[Rick Brewster]

Well, one of the main points of the plugin framework is that you shouldn't be showing UI except when the framework asks you for it. This is crucial because otherwise it breaks any possibility of having automation scenarios. This may not be of concern to you for what you are trying to do, however.

Essentially, if the plugin framework is not handing you any UI context (e.g. asking for a Control or giving you an IWin32Window), then you shouldn't be showing UI. Heck we might be running you in a separate thread, or out of proc, or who knows what ... all things that don't play "nice" with UI. What if I want to start using the Paint.NET file format API in another program, like a command-line utility? Your UI will not make sense in that context.

By showing UI when you are not being asked to, you are working with a loaded gun. I'm sure you can use the global Application class to sneakily get some UI context, but things could change and in the next version it wouldn't work. Or you'll be called from some context that is incompatible with what you're doing.

Also, by doing things that the plugin framework is not to made handle, you are forcing me to break your plugin (and maybe other, "innocent" plugins too) if I ever do decide to add that capability to future version of the framework. Paint.NET v3.0 is almost guaranteed to reject your current file format plugins (not that you can't fix and recompile and republish of course).

Now, Paint.NET is not an animation program, and it doesn't make sense for me to place anything in the plugin framework to facilitate this. It would just wind up being some untestable functionality in there that may or may not be used -- always a very bad idea. Paint.NET is also poorly suited for working with icons because each layer is required to be the same size, so providing untestable-but-might-be-used-by-somebody functionality in that case is also not a good idea.

Having a "load configuration dialog" does make sense, and it will be critical to have if Paint.NET ever hopes to incorporate some form of RAW import functionality. I imagine it would work similarly to the save configuration dialog, with a LoadConfigWidget on the left and a preview pane on the right. There would also then be a LoadConfigToken so that the settings could be persisted.

The other thing I'm seeing is that you may be needing the ability to "reject" a SaveConfigToken. Right now in Paint.NET if you want to save as an image type that requires configuration, we show the configuration dialog the first time you save and then we remember the SaveConfigToken so that the next time you hit Ctrl+S we just re-use those settings. However it may be the case that the image has changed in such a way that you want to require the user to go through the configuration UI again. Does that make sense?

[evanolds]

Is there a possibility of having a callback function for the save API that invokes when the user clicks the image in the preview area?

This would allow me to let the users click the image to select the hotspot for cursor saving. It would also allow other plugin developers to let users "click to set transparent color" or other such things.

[Rick Brewster]

It's late so I don't have a decision or answer for you yet but I've filed a bug and assigned it to the 3.0 milestone at least.