Category { "**Hidden**" } works for plug-in on 32 bit hosts but fails on 64 bit hosts - Alternative?

[C.Oldendorf]

I am experimenting with a simple plug-in that is supposed to execute a single specific task in combination with a PS panel.

So the panel's interface is written in Flex which calls my plug-in via jsx (PS scripting) and transfers some parameters that can be configured on the panel to the plug-in via its scripting capabilities - so far so good. The actual PS filter plug-in used in this shall only be executable in this way and I'd thus like it not to show up in the Filters menu at all.

I have been trying the solution suggested in this thread: http://forums.adobe.com/message/3854157#3854157

To summarize I specified "Category { "**Hidden**" }" in the plug-in's .r file and was subsequently still able to call the plug-in by means of jsx using its plugInUniqueID and jsx functions like stringIDToTypeID() and executeAction(). Anyway, that worked fine in 32 bit PS on the PC (I tried CS4 & CS5). I didn't build this on the Mac and its various platforms yet as it failed on the PC in 64 bit PS (I again tried CS4 and CS5).

The problem on the 64 bit hosts seems to be that as soon as I specify Category { "**Hidden**" } the plug-in does not get loaded anymore. If I make it visible in the menu it works fine but as soon as I make it hidden it can't be accessed by jsx plus the debugger says that no symbols were loaded for my source files when trying to set break points.

So obviously the Category { "**Hidden**" } solution does not work on all platforms.

Is there an alternative approach to this?

[ilvar]

First, I would suggest using the sample Automation plugin as your base - if you change the category there to "hidden", it most certainly loads and works (I suggest you to try it yourself - it takes just a mniute). Its always easy to work your way up from a working example.

Second, there are a lot of reasons why the plugin may fail to load on a specific platform. Have you specified you plugin as persistent ("Persistent {},") in the PIPL and is it not in the #if !defined(_WIN64) section somehow? Are you sure your x64 entry point exists? are all the dependencies properly satisfied on this platform? etc

[C.Oldendorf]

Thank you very much for your reply. The persistent remark might help me. I'm not sure if I have that right, I might have missed it. I'll review that on Monday.

In general the plug-in works when it's in a visible category so yes the x64 entry point etc. works alright. The reason I did not start out from an SDK example is that I really prefered starting out from a base where we have already meticulously solved various problems that existed in the SDK examples and which is known to now work on all legacy platforms we support (PS 6.0 PC and PS 7.0 Mac through all of the CS versions on either platform) - of course that requires a few ifdefs in certain places and the code warrior version is no longer mission critical but we're still keeping it for the moment - for sports if you will...

[ilvar]

Not a problem. I guess my main point here is that if Automation works as a hidden plugin on your platform, yours should as well and if it doesn't more often than not the propblem is in the PIPL (even though it could also be dependent libraries, your plugin entry points or simply an in-code plugin initialization failure which should also be ruled out one-by-one).

If you are stuck, you can still ran a 'diff' between your plugin's PIPL and the Automation one - it may give you some additional ideas, or run the precompiler on the resource is and see if the precompilation output still makes sense.

Good luck!

[C.Oldendorf · Accepted solution]

Thanks again. I don't really understand why it would be a requirement for x64 on the PC but making the hidden filter plug-in persistent in the PIPL solved the problem. When persistent it works when being hidden for x64 on the PC otherwise it only works when not being hidden...

This is the relevant section of the PIPL should anyone ever have the same problem.:

#else // we are in Windows

    #if defined(_WIN64)

        CodeWin64X86 { "PluginMain" },

        Persistent {},

    #else

        CodeWin32X86 { "PluginMain" },

    #endif

#endif

[ilvar]

I'm glad it worked. I would actually suggest you to mark the plugin as Persistent on both platforms if your scripting API expects to find it available at all times. PS makes no guarantees about keeping plugins loaded unless they are explicitly marked as such (using "Persistent{}"), so the fact your 32-bit instance keeped it in memory is no guarantee it will always be there (e.g. when PS gets low on memory/loads other plugins etc)

[C.Oldendorf]

I am reasonably certain that the 32 bit plug-in is NOT persistent and still works when being called by scripting in PS. PS just seems to be aware of what plug-in to load when a certain unique id is requested by the script. The same seems to apply when the plug-in is in a named category for the x64 hosts - then it also works when it's not persistent.

So I guess that the difference is an initialization one. On the x64 hosts the **Hidden** filter plug-in seems only to get processed properly during initialization when being marked as persistent - otherwise it seems to be ignored. If that's true it's at least peculiar.

If I recall correctly the persistent PIPL property doesn't even work for Filter plug-ins on older hosts...

Well, for the panel experiment that's a moot point since panels were introduced along with x64 or with CS3 at the earliest (I don't recall would have to check).

[ilvar]

The panels were introduced for CS4 which was also the first x64 release.
It is odd indeed... well, may be its yet another bug with non-persistent plugins. We long learned (the hard way) to keep all ours persistent to avoid a whole host of issues.