Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Open With Plugin

Mark Witherington
  • Edited

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. 

 

 

 

6

Comments

77 comments

Date Votes
  • Samoreen

    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
  • Mark Witherington
    • Edited

    Joe, 

    When you look under plugins do you see the Openwith plugin? This is the only plugin you need to send files out to other applications. If you read back through the thread then you will see images of what the Openwith plugin should look like. The apps you can use to externally edit your images should be listed under this plugin, just make sure the check boxes are selected for the ones you want to use.

    If the apps you want to use are not in the list, then you can use the below procedure to make C1 detect the apps. Close C1, run the procedure for each app you find is missing and when you restart C1 then you should see them listed under the Openwith plugin. Make sure the new apps are checked and then you will be able to use through the EditWith and Openwith menu options. 

    https://support.captureone.com/hc/en-us/community/posts/360011225157/comments/360001937137

     

    2
  • Charlie

    From Windows Explorer find an image folder, select a file, right click on it. Select '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 find and select the application that was NOT initially listed in Capture One ‘open with’ list of apps – eg. This PC > LOCAL DISK (C:) > Program Files > Luminar Neo

    2
  • Filthy Lucre

    This update should either be pulled or be flagged with a warning about the possible consequences of installing it.

    1
  • Samoreen
    • Edited

    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
  • Howard Pyett
    MANAGED TO FIX IT 　
    If 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> delimiters
    1
  • Permanently deleted user

    Not to my knowledge.

     

    1
  • Samoreen

    Kevin,

    > They are using some sort of platform independent framework for C1

    C1 is a Microsoft .Net Framework application. The plugins are also written in a .Net language. The code is not obfuscated, so anyone can decompile it. But it's a complex application and it's not easy to find where the OpenWith plugin fails.

    Moreover, it seems that the Windows part of the development team has a limited knowledge of the OS (the whole team appears to be mostly Mac OS oriented). Unfortunately this leads to more problems in the Windows version than in the Mac version. Not only more bugs but also features present in the Mac version that are merely not implemented in the Windows version.

    1
  • fishmi

    Oh, God, was I naive. In the meantime I read here in the forum and some other articles about the Capture One support and it becomes clear that I can more or less forget my expectations of the support.
    Sure: Support costs money, but the program is not for free. You can expect that at least the serious bugs will be fixed. But apparently some Windows users have been waiting for it for a long time (for years).
    Of course, everyone sees the rating "serious" differently.
    Let me put it this way: Functions that don't work for all Windows users (with Win 10) should be fixed quickly. Bugs that only occur in certain configurations should be fixed as Prio 2.
    It's probably like Luminar: if Capture One didn't have such unique features, some users would already be gone.

    1
  • Samoreen

    Problem apparently fixed in version 13.1.2.35.

    1
  • Mark Witherington
    • Edited

    No worries, glad you got it working. This has tripped a lot of people up including me when I first moved to C1, I recognised the path you were taking as I remember doing exactly the same things.

    It looks like C1 uses Windows associations to determine the 'allowed' apps. 

    1
  • Charlie

    SOLUTION - Nik 5.0 and C1 15.3.0

     

    Julia Seutsova (Capture One)

    Jul 18, 2022, 20:19 GMT+2

    Hello Charlie,
     
    From Windows Explorer find an image folder, select a file, right click on it.  Select '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 find and select the application that was NOT initially listed in Capture One ‘open with’ list of apps – eg. This PC > LOCAL DISK (C:) > Program Files > Nik Collection
     
    When the image is again selected in Explorer, right click and choose 'Open with'.  The Nik Collection application is now INCLUDED within the available applications listed. In Capture One the related icon and Application should be now listed under the Edit/Open With menu option and also in the Preferences > Plugins”.

    Kind regards,
    Julia - Capture One Customer Support

    We encourage you to browse our Help Center for detailed product documentation, helpful pro tips, and much more.
    1
  • RBeci

    Dear Charlie, I could solve the problem base on your advice! Thank you so much! (I can't insert photo into this comment: "You can only upload images (jpeg, gif or png). Image uploads are limited to 2 MB.", my image is a jpeg and 59kb the size)

     

     

    1
  • Filthy Lucre
    • Edited

    "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
  • SFA

    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
  • SFA

    Also, what folders/files do you have in the

    C:\Users\[User Name]\AppData\Local\CaptureOne\Defaults

    folder?

    0
  • Richard Allen
    • Edited

    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
  • Mark Witherington
    • Edited

    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
  • David Johnson

    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
  • SFA

    David Johnson,

    What folders/files do you have in the

    C:\Users\[User Name]\AppData\Local\CaptureOne\Defaults

    folder?

    0
  • SFA

    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
  • David Johnson

    Hi SFA

     

    In that path I only have the following file 

     

    0
  • Mark Witherington
    • Edited

    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
  • SFA
    • Edited

    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
  • Mark Witherington
    • Edited

    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
  • Mark Witherington

    Samoreen,

    I agree about the dropping of the plugin and implementing a real external editor manager into C1 directly.

    0
  • SFA
    • Edited

    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
  • Samoreen

    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
  • Mark Witherington
    • Edited

    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
  • Howard Pyett

    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.exe

    0

Post is closed for comments.