Fileopen Plugin Installer

[Janoc Florez]

When I try to open a pdf with fileopen drm on it, instead of opening the pdf it will open a browser page prompting me to install the fileopen plugin. I have installed and tried to open the pdf again with the same result. I have tried multiple fresh installs of acrobat reader and the plugin, tried using the fileopen plugin remover provided on the website, running as administrator and various compatibility settings. I have contacted tech support of the company that provided the pdfs and they have no idea.

I remember I had this issue a couple of years ago and it drove me crazy and unfortunately I can't remember how I solved it. Iirc is was a relatively simple fix too. Unfortunely this seems to be a fairly obscure plugin and there isn't a whole lot of information availible out there. Any advice would be greatly appreciated.

Thanks for replying, I will certainly try, however I am not holding out much hope as on thier support page it says they only offer support to thier direct customers. I am a customer of another organisation who use thier product, and when I contacted the orgnisation that provides the pdf they had no idea how to resolve the problem. I was on the phone with them for over an hour today and they couldn't figure it out. Was hoping someone here would have some idea as I don't want to wait weeks while I go through a lengthy process involving several different parties.

That was my idea. Contact the maker. However, here is one more thing to try. Go to Edit > Preferences and look under General. Find the option "Use only certified plug-ins". Make sure there is NO CHECK MARK next to this option - the option must be OFF in your Reader.

FileOpen support page says it is only for licensed FileOpen owners. I am trying to use a FileOpen encrypted file and therefore cannot contact FileOpen support. I have emailed them using the simple in...@fileopen.com email but have not heard back yet. I do not have high hopes.

I have tried to check in the Acrobat's Plugins folder (/Applications/Adobe Acrobat DC/Adobe Acrobat.app/Contents/Plugins) if the plugin was installed but unfortunately it wasn't eventhough the installer says that it was succesfully installed.

If you want to download the standard to read offline, you will first have to install a plugin called FileOpen. On University computers FileOpen is available from AppsAnywhere, or on your own computer you can download the installer here:

Once you have the File Open plugin installed and have downloaded the Standard (make sure you save it to a location on your computer) you must open it with Adobe Reader or Adobe Acrobat.

I installed acrobat reader 11.0.01 and installed fileopen using the fileopen installer. The fileopen installer says installation completed successfully. When I open a file locked using fileopen, it just brings me back to safari asking me to install fileopen again. When I click on the test pdf on the fileopen site, it comes up blank.

I have developed a plugin installer. I know that this has been done before, but I wasn't happy with the existing solutions. I know that a plugin installer/management system is on Rick's ToDo list, but I wish to provide an intermediate solution, until the real one arrives.

This will let you open a zip archive (optionally renamed to have a .pdnplgn extension). It will read the containing .net assemblies and show the contained filetype and effect plugins. It will also show you what already existing plugins will be overwritten. If it was started from the effects menu, it will also allow you to preview effects (double click on the effect) before installing it. After clicking "Install" the plugins launch a seperate process which then waits until paint.net is closed by the user and after that copies the files to the paint.net directory. When the installation is complete, it will give you the option to start paint.net up again.

However, this won't just simply copy dll's, it will check if there are assemblies which are referenced by the selected ones and copy them as well. If existing, it will also read the PluginInstallerInstructions.xml file in the archive (see the example "ArgusPaintNet (Text).pdnplgn") which lets plugin authors specify non-.net references (like native assemblies or any other filetype) which should be copied and also files which should be removed (e.g. if you have renamed your effect assembly and want the installer to remove the old one).

I have read the rules over and over again and I don't think this violates any of them (perhaps the "side effect" clause on FileType plugins, but I could easily remove that) but I'm still not sure if this will be allowed. I have read an old thread where something similar was removed/banned, but I don't know what was actually done since the code was removed.

I contacted Rick and he said, that this functionality won't work out as a plugin, but would probably be okay as an external utility, and said, I should post this to the developer section and see how this goes from there.

So.. I fear that what I have done till now won't be allowed, but I have still a little hope left since technically, the plugin only shows you plugins (similar to other plugins like the pinned Plugin Browser), the actual installation/file manipulation is done by an external program (you don't see this exe since it is included as resource in the plugin assembly and extracted to the temp folder when needed).

Since this might never make it to the public release section, I haven't put too much effort into it yet. It worked well on my personal computers with BoltBait's Plugin Pack and my own (included as ArgusPaintNet (test).pdnplgn), but it is not well tested. You probably wouldn't have a hard time to make it crash (e.g. by feeding it a corrupt archive).

I have a lot of ideas for improvement, e.g. highlighting conflicting assemblies (possibly with different colors: newergreen, olderred), detecting conflicts not only due to conflicting file names but also due to duplicate menu entries, providing an installer for the plugin, possibly with file extension association (so *.pdnplgn would automatically be opened by paint.net, this idea is actually the reason the FileType plugin version exists), but these things would require some work and thus time which I am not willing to invest before I know if I may release this on the forum.

I could relative easily covert this to an external utility but I think this would greatly reduce the user experience and I don't know if this would be worth the trouble. Furthermore, in contrast to the plugin solution, it would require "hacks"/ugly methods (somehow get the paint.net process, read registry keys, etc.) which are more likely to fail/be broken by a future update of paint.net.

Because you're not implementing a file type. You're creating something completely different. It will be in a location that doesn't really make sense to the user. So, in addition to this breaking the rules that I've laid out for plugins, it ends up parked in the UI at a location that doesn't really make sense for the end user. File->Open's job is to load images, not plugins.

You can install plugins without resorting to hacks. Finding the PaintDotNet.exe process and waiting for it to exit should not be difficult and I can help you with that code (System.Diagnostics.Process should provide most of this functionality). The install directory is stored in the registry key HKLM\Software\Paint.NET\TARGETDIR. You can even do version checking by going to the folder from that key (it'll probably be C:\Program Files\paint.net, of course) and checking the version of PaintDotNet.exe (e.g. with System.Diagnostics.FileVersionInfo). These are things that I am not going to be changing in a future release of paint.net: they're stable and you can rely on them. I just haven't documented them in a central location.

You are right, the location (File->Open) doesn't really make sense. I would argue that this is also the case for tools effect plugins like CodeLab, Plugin Browser, Color Harmonies or Effect Plugins which let you upload images to imgur or similar sites and that it at least is also not too far off (it still opens/loads something). But if you don't want that, I accept that.

I'll be honest, I'm not motivated to realize this as an external utility, it you don't want it as plugin in any way, I will probably just drop this. The reason is that I can't see such an utility being used by a larger user base. I would not download/install/use an utility, which is not somehow accessible through the paint.net UI and I guess others probably wouldn't either.

Edit: On second thought, with an external utility, I could get the file extension association functionallity back which died with the FileType plugin. I would still want the Effect plugin for two reasons: 1. To keep the ability to preview effects before installing and 2. to have a way to access the plugin installer from within paint.net. This mainly because I don't like shortcuts to little tools I rarely use clustering my desktop/start screen and remembering names so I can search them is also not my fort. Within the application which it is used for is the place I would want it to be.

I don't think this is likely, other than a real effect which can probably very simply be integrated into the internal assemblies, Rick probably has his own ideas for a real plugin management system and won't just integrate an external tool, even if it is good.

Ok. I have read the quoted statement, the reason why it wasn't clear to me if this included the effect plugin is, that your whole explanation why this shouldn't be done as a plugin was based on the assumption, that it would be a filetype plugin.

It may be a good idea to update the rules to include this (till the end it remains unclear to me, why this shouldn't be done as an effect plugin, a corresponding entry in the rules could help prevent such confusion in the future).

What we cannot do is give you the source code to the OP's project--we don't have it. But, many people around here know how to do many of the things his project does. So, if you ask SPECIFIC questions, we can probably help.

c80f0f1006