Open With Plugin
I have just installed 13.1.1 and my Open With plugin appears not to be working any more.
Obviously the Edit With and Open With menu items are not populated any more.
It's a little bit annoying as I have had only just figured out how to get my apps working through these menus :(
Has anyone got any ideas on how to fix this or am I putting a support request in?
Regards,
Mark
Addendum: From other posts it looks like there is a problem with the Open With Plugin 1.0.1. I have downgraded C1 for the moment, Open With Plugin 1.0.0 has returned and so have my apps.
-
"Addendum: From other posts it looks like there is a problem with the Open With Plugin 1.0.1. I have downgraded C1 for the moment, Open With Plugin 1.0.0 has returned and so have my apps."
For now, that's pretty much the fix.
0 -
No idea what your particular problem is caused by but my parallel (not replacement) 20.1 installation (using Windows 7) lost nothing from the Open With plugin. All is at it was.
How did you choose to update your system? Was it V20 before or an earlier version?
0 -
Also, what folders/files do you have in the
C:\Users\[User Name]\AppData\Local\CaptureOne\Defaults
folder?
0 -
I've got the same problem as well now since the most recent update to version 13.1.1; I'm using windows 10.. :(
0 -
This update should either be pulled or be flagged with a warning about the possible consequences of installing it.
1 -
SFA, sorry I don't know what was in C:\Users\[User Name]\AppData\Local\CaptureOne\Defaults, I have already reverted. I am using Windows 10 and maybe it is related, but if it is then I don't know why. Capture One know about it and have classified it as a bug. Since this is mainly a bug fix build and I was not having any problems with 13.1.0 the reversion is not a particular problem...Lets wait and see what happens I suppose. It is interesting that you have not had problems with Windows 7.
0 -
I'm the same. There is no longer anything showing up in open with/edit with. If I browse to the exe of Affinity photo, it then asks me as usual what file format etc. I choose psd, it creates a psd file then nothing happens. I then have to manually open Affinity photo and browse to the location and open the file. It works, but a pain in the neck
0 -
David Johnson,
What folders/files do you have in the
C:\Users\[User Name]\AppData\Local\CaptureOne\Defaults
folder?
0 -
Mark Witherington,
Did you perform a complete uninstall of 13.1.1. in order to revert?
Had you done the same thing before installing 13.1.1?
If so you could try installing 13.1.1 once again BUT IN ITS OWN FOLDER so that the 13.1 installation is unaffected. Not so much to use it as to see whether the Defaults folder I mentioned before contains any new folder or files.
In fact the file I am thinking of is not a 13.1.1. release introduction since my file is dated for Feb 2020 (or was until I made a quick change to my Plug-in settings in Preferences to verify that it is used.)
BuiltInOpenWithPluginSettings.xml
I suppose it is quite possible that Win 10 does things differently, There again reading responses across the internet for nearly all Win 10 "updates" over the years it has been around it seems that each new release sets out to "do things differently".
0 -
Hi SFA
In that path I only have the following file
0 -
BuiltInOpenWithPluginSettings.xml doesn't seem to be involved. Some program execution monitoring and a look at the log files show that the plugin crashes before accessing that configuration file, just after being initialized. Actually, on my system (Windows 10 Pro 1909), the problem clearly occurs when the plugin tries to access the registry data about .tif files :
[2020-06-30 17:05:51.336][000][ID:001, ]{PLUG } | Plugin initialization completed
[2020-06-30 17:05:51.336][000][ID:001, ]{PLUG } | InitializationOk: P1.C1.Plugins.Common.Wcf.IPluginHostOpenWith, P1.C1.Plugins.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=45b76d0ca35b690a| P1.C1.Plugins.Common.Wcf.IPluginHostSettings, P1.C1.Plugins.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=45b76d0ca35b690a
[2020-06-30 17:05:58.105][769][ID:009, ]{PLUG } | GetOpenWithActions -> keys: .tif, values: 1
[2020-06-30 17:05:58.121][015][ID:009, ]{PLUG } | Exception when trying to get result from the plugin - called from:The last line indicates that the plugin finds itself in an unanticipated situation.
1 -
Since the problem disappears after reverting C1 to the previous version (13.1), even on Windows 10 systems, the OS version also doesn't seem to be directly involved, unless the new plugin code is assuming something wrong about the OS when running under Windows 10.
To make it short, it's a bug in the new plugin and it should have already been fixed.
And I will not miss this opportunity to harp again about the necessity to definitively drop this plugin and to incorporate a real external editor manager into C1 directly.
4 -
SFA
No, I just installed 13.1.0 over the top and I did not completely uninstall due to fear of loosing all my settings, configurations and pre-sets/styles, etc.
I did try to install again and I noticed that the BuiltInOpenWithPluginSettings.xml file did not change. It has been suggested to me before that the BuiltInOpenWithPluginSettings.xml contains the list of Allowed Applications but I am not convinced this is the case. I have found that the contents does not represent the list of applications that I have available to me either in the working 13.1.0 version or the non working 13.1.1 version of Capture One.
This is what my BuiltInOpenWithPluginSettings.xml file has contained within:
<?xml version="1.0"?>
<ArrayOfKeyValueSerializableOfStringBoolean xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<KeyValueSerializableOfStringBoolean>
<Key>c:\program files\affinity\designer\designer.exe</Key>
<Value>true</Value>
</KeyValueSerializableOfStringBoolean>
<KeyValueSerializableOfStringBoolean>
<Key>c:\program files\affinity\photo\photo.exe</Key>
<Value>true</Value>
</KeyValueSerializableOfStringBoolean>
<KeyValueSerializableOfStringBoolean>
<Key>c:\windows\system32\mspaint.exe</Key>
<Value>false</Value>
</KeyValueSerializableOfStringBoolean>
<KeyValueSerializableOfStringBoolean>
<Key>c:\program files\windows photo viewer\photoviewer.dll</Key>
<Value>false</Value>
</KeyValueSerializableOfStringBoolean>
</ArrayOfKeyValueSerializableOfStringBoolean>...and these are the apps I have available through the plugin:
The file and the picture are plainly not the same. Note the picture is from 13.1.0 and not 13.1.1 (as I said earlier the BuiltInOpenWithPluginSettings.xml file did not change as a result of installing 13.1.1)
I have not tried installing 13.1.1 in it's own folder, I could try it I suppose...but I am a bit reluctant as I don't want to screw up my settings as discussed above.
As I said I have submitted a request and C1 returned the answer that it's a bug, and while I usually don't mind having a play to try and fix these things myself, I don't have time this week...maybe on the weekend ;) I want to make sure I fully backup all my settings before jumping in and have a play.
Regards,
Mark
0 -
Mark,
If you change a tick box setting (temporarily) in the Plug-in window posted using 13.1 does the .xmp file get updated with a change in the file together with an updated date and time for the file?
My 13.1.1 installation manages the xmp file as expected and seems to read the same file as 13.1.0 would since the data on my file before I ran my test pre-dated the 13.1.1 release.
0 -
SFA,
Good call, yes it does on 13.1.0. I have had so many problems with the OpenWith plugin during my time with C1, initially I could not get the plugin to recognise any of the apps I had installed (Nik being the main set of plugins I use, at least occasionally anyway. I managed to get them working with the Edit With and Open with menus maybe a month or so ago and have 'fiddled' with the BuiltInOpenWithPluginSettings.xml before. I finally managed to get them working with some help from the C1 support team and have even posted a detailed instruction to others on how to get this stuff working.
I am not dissuaded though, C1 is infinitely better than certain other editing applications I could mention ;). Having said that I am not sure if C1 has a beta test programme, if not then they need one to catch these teething issues before they get out into the general user domain. If they do then they need to make me one of the testers, because I seem to find the problems :D.
I will have a play with 13.1.1 on the weekend. If I make any headway then I will post here.
M.
0 -
Samoreen,
I agree about the dropping of the plugin and implementing a real external editor manager into C1 directly.
0 -
Mark,
It's strange, perhaps, but I have never had any problems with the Plugin as it is since it was introduced - possibly because I am still using Win 7. It may be old but it is at least stable on the basis that Microsoft are not fiddling with it any more. And of course it has long been considered "Mature" in that respect.
The only issues I have had relate to some applications that seems to register themselves for all sort of unsuitable file types and thus appear in a "possibles" list when they should not (easy to ignore of course) and a few thay seem not to register themselves with windows - possibly because they are expecting to run as plugins via other apps (notable Photoshop of course) or maybe the developers simply did not bother with the registration stuff in the installation routine, did but got it wrong or did but never maintained it if the mechanism varied. Who knows?
No Matter, it's not a big task to undertake a one time registration of the application in Windows and so make it available to the Windows version of the Plugin manager.
Your xml file seems to mismatch with your screen shot. That's odd. I wonder of the screen shot is looking at a different version of the file somewhere. Do you perhaps sometimes access your system using different user accounts?
Maybe Win 7 is somewhat more straightforward than Win 10 in the way that it manages things.
Maybe different to Windows 8 as well?
Win 7 has separate Appdata folder per user as far as I can see. However I doubt that would stop the system using links to a different user's file if, somehow, it "instructed" itself to do so. I would assume that the user.config file is the source of the information for all files and personalisations.
For what it's worth up to the 13.1.1 build the Appdata entries for the user.config file have always been in the Phase_One folder but since 13.1.1 they are in the Capture_One folder.
If, for any reason, the working user.config from 13.1.0 was not used (or not used correctly) when initiating the later installation one might expect previously set up data to disappear or, worse, the entire file to become unavailable for some reason.
For what it is worth I have a fairly simple setup with just a single active user plus the default windows Default and Public. accounts. There is one other user account set up for a specific purpose and unused for some years.
I have multiple C1 installation sitting side by side going back several versions and releases within versions are also installed in parallel. That makes reverting to a previous release easier in the even that a new release proves problematic for some reason. (That has very rarely happened in my case I am pleased to say - but then I often wait a few weeks before committing to a new release, especially if it is a new version.)
As C1 has developed the separation potential of all working setting, via Appdata and elsewhere, has been extended to retain ever improved ability to revert to an older implementation if required - something that is perhaps most important in a multi-user enterprise environment or for retouchers who may be required to work with different versions for different clients.
Thus I find it quite safe, at least using Windows (and in particular Windows 7 as my proofing experience), to install and use side by side installations. But of course I cannot safely recommend that without some caveats for people using other configurations.
The V13 user.config file contains entries for previous accessed plugins and the settings established for them - presumably at last use. Thus there is another file that can be checked to seek evidence of correct conversion (update by update) of an existing user.config file moved to the new update user.config file. (And of course that means there should be a sort of "Backup" for previously used configurations.)
Note these comments are specifically related to Windows and in particular Windows 7.
I have no useful knowledge of how this is handled for Macs - although I would assume there must be something similar handled through plists or whatever.
0 -
Hi,
Sorry for getting technical again but I think that there are some Windows 10 mechanisms that the C1 (plugin) developers don't seem to be aware of.
In Windows 7, file type associations are managed by the registry. For example, on my system, the HKCR branch of the registry has a .tif key that points to the Irfanview.tif alias (another entry in the same branch) and this entry indicates that TIF files should be opened by default by IrfanView.
However, I'm running Windows 10 and when I double-click a TIFF file, it's not IrfanView that opens it, it's FastStone Image Viewer. WHY ?
In the Windows 10 settings, Apps | Default Apps section, the user can specify what application should by default open an image file, be it a TIFF, a JPEG or whatever. In this Windows dialog, I have specified FastStone Image Viewer as the default image viewer (named Photo Viewer in this dialog).
So, whenever I double-click whatever file Windows considers as an image file, it is opened with FastStone Image Viewer. The registry settings for each specific file type are ignored unless Windows 10 doesn't recognize the file type as an image type. In that case, it resorts to the registry settings.
So I repeat (and I will repeat this until the stubborn developers at C1 understand that their approach is wrong) : the automatic registry scanning approach used by the OpenWith plugin to build the list of legitimate external editors is a **dead end**. It obviously ignores the above described mechanism. It **cannot** work correctly because there are too much different situations and possible conflicts. This is one of the many reasons for which the list automatically created by C1/OpenWith is often irrelevant and/or is missing legitimate applications.
The only reliable approach is the one I have already described : let the user specify once and for all what applications should be used as external editors, the executable location of each aplication and which export parameters should be used for each of these external editors. Period. That's the approach used in Lightroom and it works fine. Lightroom also allows developers of program installers to automatically add an entry in the external editors list.
I'm really wondering why the developers of C1 insists on using an approach for the external editors that never worked correctly, even before the OpenWith plugin thing appeared. All software engineers can make design mistakes. The good ones are able to acknowledge the mistake and fix it.
0 -
Samoreen, I don't disagree with your last post, particularly with the 'let the user specify once and for all what applications should be used as external editors' comment. I have made this comment myself in earlier posts (different thread similar topic).
SFA, I have all the apps I want to use configured and working under 13.1.0, and detailed the procedure I had to use to get the apps working in this post:
https://support.captureone.com/hc/en-us/community/posts/360011225157/comments/360001937137
Why there is a problem 13.1.1 is still to be determined, I will have a go at creating a parallel installation on the weekend and see if I can figure out what Windows/C1 it is doing.
I have generally found Windows 10 very stable and works with all my other apps seamlessly. C1 also works seamlessly, I just seem to be having some problems with the plugin, which may be completely unrelated to Windows 10...
0 -
This is really bugging me - excuse the pun.
At one point tonight, Edit With Topaz Denoise actually worked - and i noticed that when it did work, the Topaz application ICON was next to the plugin name - unlike the other Topaz application plugins - they were listed by no icon next to them.
Then tried grepping through the logs and came across this - basically the path to the Topaz applications is wrong ... except for the denoise application which worked.
Capture One is trying to access all the Topaz applications from the same directory of C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI - regardless of where the application is actually installed.
Each Topaz application is actually installed under its own directory:
C:\Program Files\Topaz Labs LLC\Topaz {app name} AI\Topaz {app name} ai.exe
BUT Capture One is trying to access ALL the applications from the same parent directory of
C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\ - obviously theat is why only Denosie worked.I have no idea where to go from here - but Capture One is not working as it should - PLEASE HELP
[2020-07-01 18:09:29.912][000][ID:011, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Mask AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:09:29.912][000][ID:011, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Sharpen AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:09:29.912][000][ID:011, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Studio 2.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:09:44.091][179][ID:008, ]{PLUG } | GetTasks -> Id: Topaz Denoise AI.exe, DisplayName: Topaz DeNoise AI.exe, Image: ImageSkipped, G:\Exmoor-milkyway\Capture\ISO-50\A7R00645_20.tif
[2020-07-01 18:09:44.097][005][ID:008, ]{PLUG } | GetTasks Topaz DeNoise AI.exe Topaz Denoise AI.exe
[2020-07-01 18:09:44.142][044][ID:008, ]{PLUG } | StartOpenWithTask -> FileHandlingTask: Files: G:\Exmoor-milkyway\Capture\ISO-50\A7R00645_20.tif, Id: d7facd10-a772-4222-86d6-059d07ebf180, Action: Id: Topaz Denoise AI.exe, DisplayName: Topaz DeNoise AI.exe, Image: ImageSkipped, Settings: SettingsSkipped
[2020-07-01 18:09:44.150][007][ID:008, ]{PLUG } | StartOpenWithTask d7facd10-a772-4222-86d6-059d07ebf180 Topaz DeNoise AI.exe Topaz Denoise AI.exe
[2020-07-01 18:09:44.150][000][ID:008, ]{PLUG } | Trying to start application Topaz Denoise AI.exe
[2020-07-01 18:10:38.692][542][ID:016, ]{PLUG } | GetSettingsAsync
[2020-07-01 18:10:38.958][265][ID:017, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Gigapixel AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:10:38.958][000][ID:017, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Mask AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:10:38.958][000][ID:017, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Sharpen AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:10:38.958][000][ID:017, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Studio 2.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:10:50.004][046][ID:016, ]{PLUG } | GetOpenWithActions -> keys: .ARW, values: 1
[2020-07-01 18:10:50.273][268][ID:016, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Gigapixel AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2020-07-01 18:10:50.274][000][ID:016, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Topaz Labs LLC\Topaz DeNoise AI\Topaz Mask AI.exe0 -
Howard, I would advise that you submit a request. They got back to me quickly and may be able to help. Also it will highlight the situation if lots of people submit requests...
0 -
Howard,
Am I right in thinking that Topaz Denoise AI is a standalone application, just like all the others the Topaz supplies, but that is can be accessed also via a Topaz AI Studio or something like that?
Clearly the path is wrong and that is your problem. The issue is why is the path wrong?
Is it something that the C1 Plugin gets wrong (or has previously recorded wrongly for some reason as yet unidentified)?
Or is it picking up something from elsewhere that is wrong?
Or has the Topaz installation somehow got into a strange state in terms of where stuff was installed?
Or, indeed, something else.
This looks like a local system referencing problem with one or more information exchanging files. and if it is should be really easy to fix so it becomes usable for you.
Without identifying the source of the problem there might be no certainty that it would not recur at the next update - but if a C1 update is the only source of the problem. It should be really easy to find and fix.
If a C1 update is NOT the source of the problem or, to put a slightly different slant on that, is the source of the problem but only because another problem that allowed an anomaly in file referencing expectations to slip through previously has been corrected, then there may be a few more things to consider.
0 -
Mark,
Iirc you asked a few posts back about a C1 beta testing program.
Yes there is one that is open to users. People can sign up under an NDA and many do.
Presumably they are representative of the wider user base in terms of how they use the software and the wide range (extremely wide these days) of hardware configurations they have available.
One sometimes wonders if they sign up just to get an early peak at what is new rather than to go testing and also report their findings ... but I think a fair few people do indeed take the responsibility as seriously as their workload and needs permits.
My guess would be that the next open beta exercise will be later in the year. Perhaps around November.
I think you would need to be logged in to your main Capture one Account (not the forum account) to discover information about the beta testing option.
0 -
Also found errors in the log:
[2020-05-30 11:42:22.598][187][ID:012, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 20.0.3\Plugins\OpenWith\Topaz Denoise AI.exe
**| at System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| at BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
So just as a quick test, i put a copy of the Topaz Denoise AI.exe in that directory - the Topaz Denoise AI ICON now displayed in the Edit With list ... but obviously when selected, although C1 tried to execute Topaz Denoise AI.exe from that directory, Topaz Denoise AI failed with an error.0 -
Howard,
It would be interesting to look in C:\Users\<user>\AppData\Local\CaptureOne\Defaults\BuiltInOpenWithPluginSettings.xml and to check which path is stored there for the registered apps. If it is the wrong path, try to edit this text file in Notepad (after exiting C1) and then try again.If there's no entry for your app, it's easy to add one :
<KeyValueSerializableOfStringBoolean>
<Key>path_to_exe</Key>
<Value>true</Value>
</KeyValueSerializableOfStringBoolean>Just make sure that this block is inserted before the last line of this XML file :
</ArrayOfKeyValueSerializableOfStringBoolean>
or just after this line (which is the second line)
<ArrayOfKeyValueSerializableOfStringBoolean xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
0 -
MANAGED TO FIX ITIf from WINDOWS Explorer i find an image file, i chose a tiff file, and right click and choose 'Open with' > 'Choose another app', then scroll to the bottom of the presented list and choose 'More apps', scroll to the bottom of the presented list again and choose 'Look for another app on this PC' and then go a find and select the Topaz application that was NOT initially listed in the open with list of apps.Now if i select the image, right click and and choose 'Open with', the Topaz application is now INCLUDED within the available applications listed.If i then check Capture One, then the Topaz ICONs and Applications are now listed under the Edit/Open With menu option and also the Preferences > Plugins.All Topaz applications can now be executed from the Edit/Open with menu option.
As a point of note, the BuiltInOpenWithPluginSettings.xml still shows the Topaz entries with NO PATH, just the exe file name between the <Key> delimiters1 -
I have the same problem. I do not have this issue on my laptop though. Both PC have the same version of COP and same Win10.
0 -
Howard,
I documented this procedure here (pretty much the same as yours):
https://support.captureone.com/hc/en-us/community/posts/360011225157/comments/360001937137
and linked it further up this thread...
M
0 -
Thanks Mark - i missed the link above :-(
But at least got to the same workflow to fix it and t's now working for me now - it was one of those problems that was really doing my head in :-)0 -
I too have this issue, and sorry Mark and others, but the procedure recommended is not working for me. I did try to revert to the previous c1 version, got the "plug in 1.0.0 to work, but the previous C1 does not recognize my latest work nor the files imported into 13.1.1. So far, C! tech support is of no help. Anyone have a solution that works with the latest iteration of "Plug Ins", please?
0
Please sign in to leave a comment.
Comments
77 comments