adamhearn

Great work on the updates! I can confirm that Virtual Painter 5 is working once more

BUG - Virtual Painter 5 plugin now seems broken with latest or perhaps -1 change. That is to say that the VP5 preview is fine but the updates are not applied to the image in PDN (no crash or other error). Unfortunately I didn't keep a backup but pretty sure it was working when I first downloaded the shim. REQUEST - With the latest release can you set EnsureVisible true on the tree node that was last selected. Thanks! REQUEST - Would it be possible to make the "Run Filter" button the dialog's default button? I'm a die hard keyboard user and it saves a tab keypress if the button was default. Thanks! One thing I've never quite got the grips with is the workflow between PDB and the external filter bridged by your shim. I select the desired filter from the list and choose Run Filter. More often than not I'm shown a preview of the effect and some configuration options. I 'accept' the external filters user interface and I return to the shim's dialog. However, there are a couple of odd details from here. The first is that although PDN is showing an updated image if I choose to apply another filter from the list the image it is applied to is that prior to the first filter being applied. This seems wrong [to me] as if PDN is showing the updated image [albeit under the modal dialog] shouldn't I expect the filter to be on that 'the new base image' instead of what the image was when the shim dialog was first shown? The second remark is the usage pattern in general. On your shim dialog there is the option to 'OK' or 'Cancel' the dialog. It is OK that actually performs the update on the image [see previous note] and Cancel reverts the image back to how it was when the filter dialog was invoked. An immediate thought is that perhaps once a filter effect has been applied (using the external filter's UI) perhaps it should be regarded as a completed operation. There would be no need for 'OK' and 'Cancel' processing on the shim dialog but simply a Close that would do nothing more than close the dialog. To support this, changes to the image would be recorded in the images undo/redo stack managed by PDN so the user has full control over the workflow. I assume (yeah I know!) that you're aware of the external filter being applied or cancelled and can code against these 'events'? This 'idea' would also be a viable solution to the previous problem I described. Hopefully the above makes some sense! If it doesn't and you're interested I could produce a flow chart to better describe my thoughts!

Thanks for the update. Even Flaming Pear's Primus now works

What a great idea (the plugin)! Unfortunately I've found a couple of usage issues however (sorry!) so though I'd post them here in the hope that you can perhaps correct them! I'm running build 3.5.8 of PDN and 1.0.3.7 of PSFilterPdn.dll on Windows 7 SP1 x64. 1) Shim crashes when certain plugins are executed Sinedots II is a free PlugIn available here (in fact all the plugins available from this site exhibit the same problem). As it's the shim that crashes I put it under a debugger with Reflector Pro so 'source' was available. The callstack of the crash is: PSFilterShim.exe!PSFilterLoad.PSApi.LoadPsFilter.OpenReadDescriptorProc(ref System.IntPtr param0, System.IntPtr param1) Line 1612 + 0x6 bytes C# [Native to Managed Transition] [Managed to Native Transition] PSFilterShim.exe!PSFilterLoad.PSApi.LoadPsFilter.plugin_apply(PSFilterLoad.PSApi.PluginData pdata) Line 1652 C# PSFilterShim.exe!PSFilterLoad.PSApi.LoadPsFilter.RunPlugin(PSFilterLoad.PSApi.PluginData pdata, bool showAbout) Line 2107 + 0x9 bytes C# PSFilterShim.exe!PSFilterShim.Program.RunFilterThread(object argsObj) Line 159 + 0x17 bytes C# mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x83 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes mscorlib.dll!System.Threading.ThreadHelper.ThreadStart(object obj) + 0x4a bytes The offending bit of code is: private static IntPtr OpenReadDescriptorProc(ref IntPtr param0, IntPtr param1) ... Label_005D: if (aeteDict.Count > 0) <--- HERE { return readDescriptorPtr.AddrOfPinnedObject(); } return IntPtr.Zero; The variable aeteDict is null and accessing the Count property obviously causes a crash. Looking back through the stack, I see the following logic: public bool RunPlugin(PSFilterLoad.PSApi.PluginData pdata, bool showAbout) ... if (pdata.aete != null) { aete = pdata.aete; if (!isRepeatEffect) { aeteDict = new Dictionary<uint, AETEValue>(); } } It would seem that pdata.aete was null when this was executed so the dictionary object is never assigned a value. Personally speaking I'd always ensure collections are created and have no content rather than rely on logic to check for null. 2a) PDN crashes when Run Filter is pressed whilst current operation is still running A good scenario to reproduce the problem is to perform the Ghost effect [from Flaiming Pear's freebies pack] on an image. As it takes a while to complete it's possible to click the "Run Filter" button again. This will cause PDN to crash and the exception shows contention on the temporary image file: Exception details: System.IO.IOException: The process cannot access the file 'D:\Documents\Adam\Paint.NET User Files\proxysourceimg.png' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) at PSFilterPdn.PsFilterPdnConfigDialog.Run32BitFilterProxy(EffectEnvironmentParameters eep, PluginData data) at System.Threading.ExecutionContext.runTryCode(Object userData) at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() My personal feeling (again, I apologise!) is that if this is simply a "work" file then one should be allocated using the Path.GetTempFileName method. That obviously does not correct the actual error (being able to invoke the effect whilst it's already processing a request) which can hopefully be covered with some form of access control around the Run Filter button. 2b) Shim process does not always shutdown I've not worked out how/why but it's certainly possible to leave the process running - I have on a number of occasions. If I find a reproduceable scenario I'll let you know. Q - Do you plan to release the source code to this plugin? Perhaps it could be hosted in a repository provided by Codeplex or similar? Might allow specific plugin issues to be fixed by those it affects rather than rely on yourself - of course you may want it that way! Hopefully the above helps! Thanks again for putting the PlugIn together!