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. ⚠️

Adding Programs to "Open With" Plugin

IanS
Testing out C1-20. Anyone having any problems adding programs to the "Open With" plugin in C1?

I can't add any programs. Normally I just use Windows file explorer to add programs by right clicking a file and choosing open with form the Windows right click menu. In the past this has added rto program to the C1 "Open With" plugin.

Anyone tried to add a program to the "Open With" plugin?

Ian
0

Comments

32 comments

Date Votes
  • Samoreen
    Hi Ian,

    The plugin is lacking a Browse... button, so it's practically unusable. Just a joke.

    Here is a workaround that I just tested with DxO Viewpoint :

    1. Download the OpenWithAdd utility from here : http://windowsxp.mvps.org/openwithadd.htm . Unarchive and run. It's an old program but it works.

    2. Browse to the target executable, select it, give a friendly name to the entry (e.g. DXO ViewPoint) and click on Register.

    That's it. Relaunch C1. The whole story is available here : http://forum.phaseone.com/En/viewtopic.php?f=62&t=21727 . See the 10th post. 4 years ago, the workaround needed 6 steps. Now the first 2 steps are enough (the only advantage of the plugin).

    I really can't understand why they insist on not creating a decent external editors manager. That's beyond me.
    1
  • Franz Scherz
    I was testing C1Pv20 and wanted to test also interaction with one of my other programs (Farstone image viewer).
    I could open it but once I missed the list by one and opened 'Firefox' (God knows why this was in the list of 'Open With')!

    Since then 'Open With' is not working anymore at all!

    I found a log file for the 'Open With' plugin @ 'C:\Users\%user%\AppData\Local\CaptureOne\Logs\Plugins':

    [2019-12-07 23:47:56.291][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
    [2019-12-07 23:48:14.227][936][ID:010, ]{PLUG } | GetOpenWithActions -> keys: .tif, values: 1
    [2019-12-07 23:48:16.363][135][ID:010, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 20\Plugins\OpenWith\CaptureOne.exe
    **| bei System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
    **| bei BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
    [2019-12-07 23:48:16.367][004][ID:010, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 20\Plugins\OpenWith\firefox.exe
    **| bei System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
    **| bei BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
    [2019-12-07 23:48:16.369][001][ID:010, ]{PLUG } | Exception when trying to get result from the plugin - called from: GetOpenWithActions. Der Wert darf nicht NULL sein.
    **| Parametername: argIdentifier
    [2019-12-07 23:48:16.387][018][ID:006, ]{PLUG } | GetOpenWithActions -> keys: .tif, values: 1
    [2019-12-07 23:48:18.020][632][ID:006, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 20\Plugins\OpenWith\CaptureOne.exe
    **| bei System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
    **| bei BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
    [2019-12-07 23:48:18.023][003][ID:006, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 20\Plugins\OpenWith\firefox.exe
    **| bei System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
    **| bei BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
    [2019-12-07 23:48:18.025][001][ID:006, ]{PLUG } | Exception when trying to get result from the plugin - called from: GetOpenWithActions. Der Wert darf nicht NULL sein.

    Which has the lines (translated to english) Exception when trying to get result from the plugin - called from: GetOpenWithActions. The value should not be NULL. in there.

    The problem is that now on C1P v12 the 'Open With Plugin' stopped working as well!
    It just shows no entries and no entries can be added anymore! I reinstalled both versions but even then it's not working any more!

    So C1Pv20 changed something in windows when I added (wrongly) Firefox and since then Open With is not working anymore!

    I installed the SW also on my notebook and Open With working there and there are no errors in the log file.
    0
  • Samoreen
    Hi again,

    The 2-step process might not work with all programs. In that case please try the 6-step process. Maybe there's a limitation to the number of items in the list.

    I don't know how they determine that a program is allowed to be used in Edit with... but very frankly, I don't know what Microsoft Word and Firefox could do as external editors.
    0
  • Samoreen
    Ian,

    The 6-step process seems to work in any case. It's a little bit awkward but at least, it's a temporary solution until somebody wakes up at the C1 lab and decides to do something after all these years.

    Creating the entry in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts for one single extension (.tif for example) seems to be enough for allowing C1 to use the specified external editor for any file type.
    0
  • SFA
    IanS wrote:
    Testing out C1-20. Anyone having any problems adding programs to the "Open With" plugin in C1?

    I can't add any programs. Normally I just use Windows file explorer to add programs by right clicking a file and choosing open with form the Windows right click menu. In the past this has added rto program to the C1 "Open With" plugin.

    Anyone tried to add a program to the "Open With" plugin?

    Ian


    Not something I have tried often but as I recall nothing has added a program to the association list that easily at the point of selection.

    However popping into windows and setting up the association of file type and program seemed to tell Win 7 that the program I chose had something to do with image editing and it immediately appeared on the list of likely applications I might want to use.

    As I rarely use either Open With or Edit With and even more rarely feel a need to use them with a new piece of software that has not self registered on installation, I personally don't see this as a big deal.

    It might be more of an issue in an enterprise version where which application are allowed or disallowed might be centrally controlled. But I would guess people operating like that have things covered anyway.

    Just my 2 cents.


    Grant
    0
  • Samoreen
    Hallo Franz1,

    Exit C1 and try to temporarily rename C:\Users\<user>\AppData\Local\Phase_One\CaptureOne.exe_StrongName_y3yh4brhpfi14u41fltdrpfruizxirsn\13.0.0.155\user.config and see what happens when re-launching C1. Ditto for version 12.

    Be sure to backup the files because you will lose your app settings doing this.
    0
  • Samoreen
    SFA wrote:
    However popping into windows and setting up the association of file type and program seemed to tell Win 7 that the program I chose had something to do with image editing and it immediately appeared on the list of likely applications I might want to use.


    Using the file associations to manage external editors is a big mistake because 1) this doesn't work well, as demonstrated regularly since years and 2) because external editors are not necessarily related to a file extension. Only the user knows which file he'd like to send to which external program. This has to be managed with a separate mechanism as in any other application allowing to send/export files to another app.

    I don't know why the C1 developers made this decision but it is plain wrong. There's someone who is rather stubborn in this team.
    0
  • SFA
    Samoreen wrote:
    SFA wrote:
    However popping into windows and setting up the association of file type and program seemed to tell Win 7 that the program I chose had something to do with image editing and it immediately appeared on the list of likely applications I might want to use.


    Using the file associations to manage external editors is a big mistake because 1) this doesn't work well, as demonstrated regularly since years and 2) because external editors are not necessarily related to a file extension. Only the user knows which file he'd like to send to which external program. This has to be managed with a separate mechanism as in any other application allowing to send/export files to another app.

    I don't know why the C1 developers made this decision but it is plain wrong. There's someone who is rather stubborn in this team.


    It's a facility that Windows has supported for a long time and generally work unless the software provider makes an attempt to associate their application with every type of file in existence or, better, at least limited to files it can read and display though maybe not edit as we would understand it.

    Bad possibilities are that the file extension is shared by more than one type of file use by different application for completely different purposes or a program that can work with jpgs is assumed by Windows to be a "media" related file that can work with any other type of media related file or a user dives in to make their own associations and creates a mess.

    That last problem could, presumably, apply equally to a program entirely independent of Windows involvement. So i'll discount it.

    Now why a program should fail to register its file associations with Windows probably should be a discussion for elsewhere but assuming the sorts of programs people using C1 would use do indeed make the association correctly and are therefore available (unless there is potential for Windows to mess things up - unheard of I'm sure.) should C1 make use of the Windows associations or not?

    If it should then C1, with or without its own management of external editing programs, would still be susceptible to the false associations offered by Windows.

    On the other hand I rather suspect that if C1 required users to set up and manage their own list of connected applications by file type may users would complain that they did not need that added technical complexity in their lives when Windows does it for them everywhere else.

    And then of course there is the potential for the accidental association as per Franz1's post no matter how or where the associations are being managed.

    So basically, and one would hope more reliably as the industry develops new software and better installation procedure in the agile and web based world, the problem should not exist because possible associations should be registered accurately at the point of installation.

    And most people probably don't have a problem anyway since the more commonly used programs seem to be available as things are so far as I can see from my system.

    Perhaps this might become a rather niche and rare problem?

    I took a look at what Affinity seems to offer for plug-ins.

    So far as I could find in the help files they support (with warnings about the potential for third party software not working as expected) PhotoShop plug-ins. So as far as I could find spending a few minutes searching nothing as directly connected to an external editor as Capture One presents. Moreover I presume that PS related plug-ins somewhat self select in terms of being appropriate for use with a PS type of product. That's slightly different, it seems to me, to the way that C1 can be used.

    Whether one approach or the other is better is not necessarily something that can be given a binary answer.


    Grant
    0
  • Samoreen
    SFA wrote:
    On the other hand I rather suspect that if C1 required users to set up and manage their own list of connected applications by file type may users would complain that they did not need that added technical complexity in their lives when Windows does it for them everywhere else.


    What complexity ? Lightroom users are happy with the external editor manager provided by the software and I never heard anyone complaining about this feature being too complex. Also, I never ever heard anyone asking Adobe to make this mechanism Windows dependent. It's simple and easy. You select an executable, you define the export format and a few other details and that's it. The program is registered as an external editor once and for all. Currently, the complexity is with C1. The only good idea in C1 regarding external programs is the difference between Open with... and Edit with... In Lightroom, Open with... has to be handled with a LUA script. Not especially difficult but I'd prefer to have 2 separate commands like in C1.

    This is not a niche problem. Since RAW processing programs are generally unable to provide retouching features, many users need to resort to external applications (Affinity, PS,...) for some tasks. So external editors are very often a part of the workflow. Or is C1 pretending to cover everything ?
    0
  • IanS
    SFA wrote:
    Samoreen wrote:
    SFA wrote:
    However popping into windows and setting up the association of file type and program seemed to tell Win 7 that the program I chose had something to do with image editing and it immediately appeared on the list of likely applications I might want to use.


    Using the file associations to manage external editors is a big mistake because 1) this doesn't work well, as demonstrated regularly since years and 2) because external editors are not necessarily related to a file extension. Only the user knows which file he'd like to send to which external program. This has to be managed with a separate mechanism as in any other application allowing to send/export files to another app.

    I don't know why the C1 developers made this decision but it is plain wrong. There's someone who is rather stubborn in this team.


    It's a facility that Windows has supported for a long time and generally work unless the software provider makes an attempt to associate their application with every type of file in existence or, better, at least limited to files it can read and display though maybe not edit as we would understand it.

    Bad possibilities are that the file extension is shared by more than one type of file use by different application for completely different purposes or a program that can work with jpgs is assumed by Windows to be a "media" related file that can work with any other type of media related file or a user dives in to make their own associations and creates a mess.

    That last problem could, presumably, apply equally to a program entirely independent of Windows involvement. So i'll discount it.

    Now why a program should fail to register its file associations with Windows probably should be a discussion for elsewhere but assuming the sorts of programs people using C1 would use do indeed make the association correctly and are therefore available (unless there is potential for Windows to mess things up - unheard of I'm sure.) should C1 make use of the Windows associations or not?

    If it should then C1, with or without its own management of external editing programs, would still be susceptible to the false associations offered by Windows.

    On the other hand I rather suspect that if C1 required users to set up and manage their own list of connected applications by file type may users would complain that they did not need that added technical complexity in their lives when Windows does it for them everywhere else.

    And then of course there is the potential for the accidental association as per Franz1's post no matter how or where the associations are being managed.

    So basically, and one would hope more reliably as the industry develops new software and better installation procedure in the agile and web based world, the problem should not exist because possible associations should be registered accurately at the point of installation.

    And most people probably don't have a problem anyway since the more commonly used programs seem to be available as things are so far as I can see from my system.

    Perhaps this might become a rather niche and rare problem?

    I took a look at what Affinity seems to offer for plug-ins.

    So far as I could find in the help files they support (with warnings about the potential for third party software not working as expected) PhotoShop plug-ins. So as far as I could find spending a few minutes searching nothing as directly connected to an external editor as Capture One presents. Moreover I presume that PS related plug-ins somewhat self select in terms of being appropriate for use with a PS type of product. That's slightly different, it seems to me, to the way that C1 can be used.

    Whether one approach or the other is better is not necessarily something that can be given a binary answer.


    Grant


    Hi Grant

    C1 provide an "Open With" plugin that lets you control which programs are available when you right click an image. Prior to the plugin there was no way to control what programs you saw when you right click an image. As I understand it with Mac's the OS adds all programs automatically. In Windows you had to go through the procedure I outlined in my OP.

    C1 do not provide any documentation on how to add programs to the "Open With" plugin as was the case before the plugin existed. Any professional company should provide documentation on how to use the program? I don't mind a clunky way of adding programs, doing it through the OS is clunky but no big issue if it works.

    Something has changed because adding programs through the OS no longer seems to work. This could be a C1 issue or a Win 10 issue as Win 10 changes every 6 months. It is a developers choice as to how they program a particular facility but if you choose the OS then you leave your self at the mercy of the OS, which you know is changing every 6 months. I do not consider the latter option a professional choice. You just increase your support costs because you don't want to write a short sub routine to manage the adding of programs to the "Open With" plugin as DXO and LR manage to do.

    If C1 don't want to provide the option of linking to external programs then that is fine. To provide the facility that doesn't work is not.

    Just to repeat one final point. Can you find me any documentation on how to add programs to the "Open With" plugin - any company that won't provide any documentation is not acting professionally. This sort of issue is very counterproductive for Phaseone in that it generates a lot of bad feeling for no real reason accept laziness on the part of the programmers.

    I have a support case in and wait to see what reply I get. In the past I have found support to be very responsive to requests for help.

    I am a great fan of C1 and having an "Open With" plugin greatly aids the use of C1 and also provides an easy solution for the competing with LR where it not only has a good plugin facility but can carry out more operations internally such as HDR and Panos. Taking away the easy ability to compensate for C1's lack of internal functionality compared to LR by implementing a broken "Open With" plugin is simply not good commercial practice.

    I might struggle to write the code to manage adding programs to the plugin as it's a long time ago since I did any programming and it was in assembler, but my son certainly could. If I was project manager at Phaseone I would easily solve this issue by kicking the lazy programmer up the back side and get him to fix it with an afternoons work. These issues are simply unnecessary, Phaseone just fix it!

    Ian
    0
  • Samoreen
    IanS wrote:
    If I was project manager at Phaseone I would easily solve this issue by kicking the lazy programmer up the back side and get him to fix it with an afternoons work.


    Agreed. So would I (as a former developer/project manager).
    0
  • SFA
    You people must be seeing something different to me.

    This plug-in stuff is not something I use often but yesterday I want in search of some sort of possibly valid application on my system that was not already available for use by Open With or Edit with and did not appear in the tick list ofr available plug-ins.

    I found an old program that I don't think I have ever used and seems to date from 2011.

    I used the Window facility to associate it with a .jpg extension and that seemed to be enough to make it available as a C1 plug-in. I took and extra 15 seconds or so to associated with .tif and .tiff just in case some other applications were sensitive in that area.

    The program immediate appeared in the list of possible application available for Open With and Edit With and is also in the list of of program available for use in the Plug-In manager.

    I suspect that, had I actually used it to produce an output jpg or tiff when I first browsed to select it Windows would have created the association anyway and saved me a few seconds.

    Quite how any developer can avoid the influences of changes at the OS/System Coding tools level in the modern era and do so cost effectively I am not sure. Presumably for every revision that was later introduced they would also have to maintain and retest their code. All for something that most people using the application will probably used extremely rarely in situations that do not already work for them automatically.

    Over the past 2 or 3 decades I have regularly worked with software designed to allow data extraction from both text files and database type files.

    The vendor recognised that PDF files were become 'standard' i the industry and decided they needed to cater for those as well. They estimated it might take a couple of days to write their own code since there were published standards for how a PDF should be constructed. Just text content, not graphics.

    Months later they were still working to cater for all of the differences that were turning up in the wild either because the standards had been circumvented or because developers of major application had written their own version of a PDF print routine and not followed the standard at all. "Enhancement"s continued for some years trying to cater for all of the old drivers, sometimes more than one variant of a driver on the same 'mainframe' system, as well as the latest and greatest advances to the specification.

    Eventually they found a third party source for much the same facility an decided that they would use them as it was the third party's main business where as it was not meant to be their own main business.

    That change did not go entirely well and I suspect they quietly changed to yet another external supplier a year or so later.

    What should have been so simple simply was not at all simple. Nor really controllable.

    If, as a developer, one can foresee potential issues when external influences enforce change on your activities it makes sense to minimise the the number of risky contact points. Writing one's own manager increases rather than decreases that risk UNLESS one takes control of the entire application and writes everything but the most basic OS/file system interactions. You have to have a real need to go down into that level and in general only very wealthy companies with some extreme needs are likely to go that far and only then if they have time on their side and cash to spare for when things don't work out according to the Project Plan and budget.

    My opinions are based on this and many similar experiences over the years.


    Grant
    0
  • IanS
    SFA wrote:
    You people must be seeing something different to me.

    This plug-in stuff is not something I use often but yesterday I want in search of some sort of possibly valid application on my system that was not already available for use by Open With or Edit with and did not appear in the tick list ofr available plug-ins.

    I found an old program that I don't think I have ever used and seems to date from 2011.

    I used the Window facility to associate it with a .jpg extension and that seemed to be enough to make it available as a C1 plug-in. I took and extra 15 seconds or so to associated with .tif and .tiff just in case some other applications were sensitive in that area.

    The program immediate appeared in the list of possible application available for Open With and Edit With and is also in the list of of program available for use in the Plug-In manager.

    I suspect that, had I actually used it to produce an output jpg or tiff when I first browsed to select it Windows would have created the association anyway and saved me a few seconds.

    Quite how any developer can avoid the influences of changes at the OS/System Coding tools level in the modern era and do so cost effectively I am not sure. Presumably for every revision that was later introduced they would also have to maintain and retest their code. All for something that most people using the application will probably used extremely rarely in situations that do not already work for them automatically.

    Over the past 2 or 3 decades I have regularly worked with software designed to allow data extraction from both text files and database type files.

    The vendor recognised that PDF files were become 'standard' i the industry and decided they needed to cater for those as well. They estimated it might take a couple of days to write their own code since there were published standards for how a PDF should be constructed. Just text content, not graphics.

    Months later they were still working to cater for all of the differences that were turning up in the wild either because the standards had been circumvented or because developers of major application had written their own version of a PDF print routine and not followed the standard at all. "Enhancement"s continued for some years trying to cater for all of the old drivers, sometimes more than one variant of a driver on the same 'mainframe' system, as well as the latest and greatest advances to the specification.

    Eventually they found a third party source for much the same facility an decided that they would use them as it was the third party's main business where as it was not meant to be their own main business.

    That change did not go entirely well and I suspect they quietly changed to yet another external supplier a year or so later.

    What should have been so simple simply was not at all simple. Nor really controllable.

    If, as a developer, one can foresee potential issues when external influences enforce change on your activities it makes sense to minimise the the number of risky contact points. Writing one's own manager increases rather than decreases that risk UNLESS one takes control of the entire application and writes everything but the most basic OS/file system interactions. You have to have a real need to go down into that level and in general only very wealthy companies with some extreme needs are likely to go that far and only then if they have time on their side and cash to spare for when things don't work out according to the Project Plan and budget.

    My opinions are based on this and many similar experiences over the years.


    Grant


    So don't depend on the OS and write a short subroutine to manage the "add Program" dialogue. Even free software can do this like Faststone. The question is why don't they do this and make their "Open With" plugin work. Did you find any documentation?

    Seriously if you were project manager how would you sort this issue?

    Ian
    0
  • Samoreen
    OK. I'm too curious so I spent some time trying to understand how C1 (or its plugin) determines which programs should appear in the Open with/Edit with list. Interesting results...

    1. I was wondering why it takes so long when clicking on Edit with or Open with to get the program list displayed. This probably indicates a recurring code that is executed each time we open this menu.

    2. So I started a debugging session and traced what was happening. Here is what I found out :

    For each filename extension found in any of the folders imported in the C1 catalog, be it related to imaging or not (they can be .doc, .vrd, .mycustomex or whatever), C1 opens the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.eee\UserChoice registry key (eee being the extension). If it finds any program specified here, it will add it to the Open with/Edit with list. For example, I have a few HTM/HTML files stored in some of the image folders imported into C1. These are not images but they have to be there, this is my choice. For these files, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice says that the handling application is Firefox (my default browser). So, Firefox is added to the list. And so on... For a similar reason, my hexadecimal editor appears in the list although it has nothing to do there.

    Since I don't have access to the source code, I don't know when the list of extensions on which this (crazy) loop is based is created. Probably during the initial folder import. If I add files with irrelevant extensions "after the fact", the corresponding app doesn't appear in the list. Of course, this is a partial explanation of the problem since I don't want (and may not) do reverse engineering on this code.

    But this is enough to say that this is just first year programming student work.

    At least, C1 could look at the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.xxx\OpenWithList key. It would have a better chance to find there a relevant program. But the initial flaw is to consider that all files stored in an imported folder are possibly image files. By the way, it does the same with all sidecar files that could have been created by other applications. For example, C1 tries to find programs associated with .xmp or .dxo files. Which doesn't make sense.

    Anyway, this demonstrates that the Windows associations approach in order to maintain the Open with/Edit with list is merely a dead-end. Ian said it : it's now time to fix this. For Lightroom, the oldest non-fixed bug in my bug report list is now more than 10 years old. Phase One, are you trying to beat a record ?
    0
  • Dave R
    SFA wrote:
    You people must be seeing something different to me.

    This plug-in stuff is not something I use often but yesterday I want in search of some sort of possibly valid application on my system that was not already available for use by Open With or Edit with and did not appear in the tick list ofr available plug-ins.

    I found an old program that I don't think I have ever used and seems to date from 2011.

    I used the Window facility to associate it with a .jpg extension and that seemed to be enough to make it available as a C1 plug-in. I took and extra 15 seconds or so to associated with .tif and .tiff just in case some other applications were sensitive in that area.

    The program immediate appeared in the list of possible application available for Open With and Edit With and is also in the list of of program available for use in the Plug-In manager.

    I suspect that, had I actually used it to produce an output jpg or tiff when I first browsed to select it Windows would have created the association anyway and saved me a few seconds.

    Quite how any developer can avoid the influences of changes at the OS/System Coding tools level in the modern era and do so cost effectively I am not sure. Presumably for every revision that was later introduced they would also have to maintain and retest their code. All for something that most people using the application will probably used extremely rarely in situations that do not already work for them automatically.

    Over the past 2 or 3 decades I have regularly worked with software designed to allow data extraction from both text files and database type files.

    The vendor recognised that PDF files were become 'standard' i the industry and decided they needed to cater for those as well. They estimated it might take a couple of days to write their own code since there were published standards for how a PDF should be constructed. Just text content, not graphics.

    Months later they were still working to cater for all of the differences that were turning up in the wild either because the standards had been circumvented or because developers of major application had written their own version of a PDF print routine and not followed the standard at all. "Enhancement"s continued for some years trying to cater for all of the old drivers, sometimes more than one variant of a driver on the same 'mainframe' system, as well as the latest and greatest advances to the specification.

    Eventually they found a third party source for much the same facility an decided that they would use them as it was the third party's main business where as it was not meant to be their own main business.

    That change did not go entirely well and I suspect they quietly changed to yet another external supplier a year or so later.

    What should have been so simple simply was not at all simple. Nor really controllable.

    If, as a developer, one can foresee potential issues when external influences enforce change on your activities it makes sense to minimise the the number of risky contact points. Writing one's own manager increases rather than decreases that risk UNLESS one takes control of the entire application and writes everything but the most basic OS/file system interactions. You have to have a real need to go down into that level and in general only very wealthy companies with some extreme needs are likely to go that far and only then if they have time on their side and cash to spare for when things don't work out according to the Project Plan and budget.

    My opinions are based on this and many similar experiences over the years.


    Grant


    Grant I believe that you are using that soon to be unsupported antediluvian operating system Windows 7. Windows 10 has evolved a lot over the years and in its drive to simplify for the general user has made things like file association a lot more difficult if you are not trying to associate with a Windows app from the App Store. 😭

    Dave.
    0
  • Franz Scherz
    Samoreen wrote:
    Hallo Franz1,

    Exit C1 and try to temporarily rename C:\Users\<user>\AppData\Local\Phase_One\CaptureOne.exe_StrongName_y3yh4brhpfi14u41fltdrpfruizxirsn\13.0.0.155\user.config and see what happens when re-launching C1. Ditto for version 12.

    Be sure to backup the files because you will lose your app settings doing this.


    I tried this and it does dot change anything, the plugin still does not work.

    I also tried to add firefox with OpenWithAdd to 'overwrite' what's in there now but the only effect I have that I have now 4 instead 3 error messages whenever OpenWith plugin is used (on config or in Open wiith or edit with dialog).

    The problem seems to lies in the registry I believe because whatever IC1Pv12 or C1Pv20 (strange enough, the version numbers in the system says v13 but I believe nobody wanted to use 13 because it can bring bad luck).
    0
  • Franz Scherz
    Samoreen wrote:

    For each filename extension found in any of the folders imported in the C1 catalog, be it related to imaging or not (they can be .doc, .vrd, .mycustomex or whatever), C1 opens the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.eee\UserChoice registry key (eee being the extension). If it finds any program specified here, it will add it to the Open with/Edit with list. For example, I have a few HTM/HTML files stored in some of the image folders imported into C1. These are not images but they have to be there, this is my choice. For these files,


    I checked that and created a complete new catalog with no pictures in there and it still get these "BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)" errors for .tif!
    When I add a jpg and a NEF file the number of errors increase because also nef generates an error!

    Really stange.

    I am not a programmer to debug myself but for me it's clear that C1 tries to collect icons from the apps associated with a certain extension and this fails always.
    0
  • SFA
    David532 wrote:

    Grant I believe that you are using that soon to be unsupported antediluvian operating system Windows 7. Windows 10 has evolved a lot over the years and in its drive to simplify for the general user has made things like file association a lot more difficult if you are not trying to associate with a Windows app from the App Store. 😭

    Dave.


    I did wonder Dave, having found some information on line that suggests there have been a number of "enhancements" to Win 10 that, based on the screen shots, did not look like enhancements at all, though perhaps the screens might appeal as being a little prettier for some.

    Such is the nature of progress.

    Thanks for the warning!


    Grant
    0
  • Paul Steunebrink
    David532 wrote:
    Grant I believe that you are using that soon to be unsupported antediluvian operating system Windows 7.

    Antediluvian, I had to look that up. I learned something new today. 😂
    0
  • IanS
    Samoreen wrote:
    OK. I'm too curious so I spent some time trying to understand how C1 (or its plugin) determines which programs should appear in the Open with/Edit with list. Interesting results...

    1. I was wondering why it takes so long when clicking on Edit with or Open with to get the program list displayed. This probably indicates a recurring code that is executed each time we open this menu.

    2. So I started a debugging session and traced what was happening. Here is what I found out :

    For each filename extension found in any of the folders imported in the C1 catalog, be it related to imaging or not (they can be .doc, .vrd, .mycustomex or whatever), C1 opens the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.eee\UserChoice registry key (eee being the extension). If it finds any program specified here, it will add it to the Open with/Edit with list. For example, I have a few HTM/HTML files stored in some of the image folders imported into C1. These are not images but they have to be there, this is my choice. For these files, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice says that the handling application is Firefox (my default browser). So, Firefox is added to the list. And so on... For a similar reason, my hexadecimal editor appears in the list although it has nothing to do there.

    Since I don't have access to the source code, I don't know when the list of extensions on which this (crazy) loop is based is created. Probably during the initial folder import. If I add files with irrelevant extensions "after the fact", the corresponding app doesn't appear in the list. Of course, this is a partial explanation of the problem since I don't want (and may not) do reverse engineering on this code.

    But this is enough to say that this is just first year programming student work.

    At least, C1 could look at the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.*censored word*\OpenWithList key. It would have a better chance to find there a relevant program. But the initial flaw is to consider that all files stored in an imported folder are possibly image files. By the way, it does the same with all sidecar files that could have been created by other applications. For example, C1 tries to find programs associated with .xmp or .dxo files. Which doesn't make sense.

    Anyway, this demonstrates that the Windows associations approach in order to maintain the Open with/Edit with list is merely a dead-end. Ian said it : it's now time to fix this. For Lightroom, the oldest non-fixed bug in my bug report list is now more than 10 years old. Phase One, are you trying to beat a record ?


    I appreciate you taking the time to do a "deep dive" into the "Open With" plugin mess.

    Here is the practical outcome for Phaseone of operating like this. There is a guy on dpreview forums evaluating C1. He is trying to send a file to Topaz Sharpen AI in order to use functionality not provided by C1. He has been told to simply use "Open With" and select Topaz Sharpen AI. He replies "It's not in the right click list?" What do I tell him to do to fix this? The truth, "you need to get a Mac for that functionality?"

    Seriously, for the sake of a simple add program dialogue that even free software like Faststone can provide you instead want users to:
    1) Export the file to a folder
    2) Open Topaz Sharpen and navigate to the export folder
    3) Save the file from Topaz Sharpen to the folder where your original image is
    4) Re synch the catalogue (if you are using catalogues) in order to see the file in C1

    Or use LR, ON1, DXO-PL3 etc, etc.

    If you provide the users with friction "For no good reason" don't be surprised if they chose software that implements basic functionality.

    I think we all agree that there is a simple and straightforward solution to this issue, provide an "add program" dialogue. The interesting question is why, when the solution is simple, Phaseone will not do this?

    My support request was acknowledged 2 days ago but no response so far. I will update on its progress.

    Ian
    0
  • Samoreen
    Samoreen wrote:
    OK. I'm too curious so I spent some time trying to understand how C1 (or its plugin) determines which programs should appear in the Open with/Edit with list. Interesting results...


    More details about what C1 is doing to build the Edit with/Open with list... and even more reasons to complain. I went deeper into my debugging session and I have now a more accurate idea of what's happening when C1 starts.

    1. Each time C1 starts it enters a loop accessing each imported folder and subfolder.

    2. For each folder and subfolder, it looks at all the type of all files present in the folder whatever these files are.

    3. For each found file type, it looks at this registry key : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\KindMap. This key points to a map giving the correspondence between a given filename extension and a human readable file type description.

    4. If the corresponding type description is picture OR if the filename extension is not found in the map, C1 goes to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.eee\UserChoice (eee being the filename extension) and tries to determine what application takes care by default of this file type. It doesn't seem to be very smart at this because it only seems to be able to solve the simplest cases.

    5. If an application is found, it is added to the list.

    6. Goto step #2.

    This is absolutely insane and can only give unpredictable results.

    But wait, there's more about it. On my system, I measured how much time it takes when launching C1 for the first time in a Windows session until the main menu actually reacts to a mouse click. It's about 15 seconds. From these 15 seconds I measured that 10 are used by the loop described above (results may vary on other systems).

    This means that if C1 used a standard external editor manager, it would start much faster because an external editor manager wouldn't impact the startup time at all.

    So, not only those users needing to access external editors should complain about the terrible implementation of this non working feature. Every user should.
    0
  • Ian Leslie
    Yikes that does suck. Nice detective work. Are you going to report your findings to C1 along side your request to do a better job with "Edit With"?

    Not the same Ian as above,

    Ian

    PS. I am not very pleased with the new support case management system for C1. I really hope they make improvements to that at some point.
    0
  • Samoreen
    IanL wrote:
    Yikes that does suck. Nice detective work. Are you going to report your findings to C1 along side your request to do a better job with "Edit With"?


    Certainly. But as I reported elsewhere, I have a lot of pending requests and bug reports since version 9 and I'm not confident that a new request will be handled in a more effective way than these. The C1 team appears to belong to the "we know what's good for you" kind. Especially when considering the new case management system for C1.
    0
  • Ian Leslie
    I hear ya my only point is that nothing will improve if we don't let them know what we want to see changed. I *am* getting good value out of C1 so I'm not going anywhere. I'll continue to draw attention to issues I am having through their support system.

    I am also less than impressed with the new support ticket system. I even went so far as to post a "is this how your customers usually implement your product" on the third party vendor for the support ticket system. The bad news is yeah frequently. The good news is the system can provide a user profile with a list of active cases and members of that company have promised me that they will have their account manager contact Phase one about how to do it 😊

    Yep, I'm a pain in the ass sometimes but a polite one - mostly. 😄
    0
  • IanS
    IanL wrote:
    Yikes that does suck. Nice detective work. Are you going to report your findings to C1 along side your request to do a better job with "Edit With"?

    Not the same Ian as above,

    Ian

    PS. I am not very pleased with the new support case management system for C1. I really hope they make improvements to that at some point.


    I have reported the issues highlighted in this thread to Phaseone Support as replies to my email from them acknowledging my support request.

    My support request was logged on the 8th but I have yet to receive any feedback. I have had no feedback. Previously, Phaseone support has been very responsive. I guess I will just have to wait 😊

    The original Ian 😊

    Ian
    0
  • Ian Wilson
    Moderator
    Top Commenter
    IanS wrote:

    The original Ian 😊
    Ian

    What?????

    Ian
    0
  • Ian Leslie
    IanS wrote:

    My support request was logged on the 8th but I have yet to receive any feedback. I have had no feedback. Previously, Phaseone support has been very responsive. I guess I will just have to wait 😊


    Yeah I have had total silence on my cases too - I think they are swamped with the new release and the new support system.
    0
  • Ian Leslie
    Ian3 wrote:
    IanS wrote:

    The original Ian 😊
    Ian

    What?????

    Ian


    LOL hence the '3' on your user name...
    0
  • IanS
    SFA wrote:
    You people must be seeing something different to me.

    This plug-in stuff is not something I use often but yesterday I want in search of some sort of possibly valid application on my system that was not already available for use by Open With or Edit with and did not appear in the tick list ofr available plug-ins.

    I found an old program that I don't think I have ever used and seems to date from 2011.

    I used the Window facility to associate it with a .jpg extension and that seemed to be enough to make it available as a C1 plug-in. I took and extra 15 seconds or so to associated with .tif and .tiff just in case some other applications were sensitive in that area.

    The program immediate appeared in the list of possible application available for Open With and Edit With and is also in the list of of program available for use in the Plug-In manager.

    I suspect that, had I actually used it to produce an output jpg or tiff when I first browsed to select it Windows would have created the association anyway and saved me a few seconds.

    Quite how any developer can avoid the influences of changes at the OS/System Coding tools level in the modern era and do so cost effectively I am not sure. Presumably for every revision that was later introduced they would also have to maintain and retest their code. All for something that most people using the application will probably used extremely rarely in situations that do not already work for them automatically.

    Over the past 2 or 3 decades I have regularly worked with software designed to allow data extraction from both text files and database type files.

    The vendor recognised that PDF files were become 'standard' i the industry and decided they needed to cater for those as well. They estimated it might take a couple of days to write their own code since there were published standards for how a PDF should be constructed. Just text content, not graphics.

    Months later they were still working to cater for all of the differences that were turning up in the wild either because the standards had been circumvented or because developers of major application had written their own version of a PDF print routine and not followed the standard at all. "Enhancement"s continued for some years trying to cater for all of the old drivers, sometimes more than one variant of a driver on the same 'mainframe' system, as well as the latest and greatest advances to the specification.

    Eventually they found a third party source for much the same facility an decided that they would use them as it was the third party's main business where as it was not meant to be their own main business.

    That change did not go entirely well and I suspect they quietly changed to yet another external supplier a year or so later.

    What should have been so simple simply was not at all simple. Nor really controllable.

    If, as a developer, one can foresee potential issues when external influences enforce change on your activities it makes sense to minimise the the number of risky contact points. Writing one's own manager increases rather than decreases that risk UNLESS one takes control of the entire application and writes everything but the most basic OS/file system interactions. You have to have a real need to go down into that level and in general only very wealthy companies with some extreme needs are likely to go that far and only then if they have time on their side and cash to spare for when things don't work out according to the Project Plan and budget.

    My opinions are based on this and many similar experiences over the years.


    Grant


    Hi Grant

    What about this as a possible solution:

    In the "Open With" dialogue that appears when yo right click an image within C1 you have an option to "Browse" for the .exe file of the program you want to use / associate with the "Open With" process.

    Why can't that dialogue, that already exists, be used to ass the program to the "Open With" plugin list? Seems minimal effort, there would be a need for a check to see if the program is already in the list but this should have minimal impact as once having added the program to the list you are going to use the drop down list rather than the "Browse" option.

    Would appear to be minimal programming effort as the "Browse" facility already exists, and actually very simple to implement?

    Ian
    0
  • Samoreen
    IanS wrote:
    Why can't that dialogue, that already exists, be used to add the program to the "Open With" plugin list?


    There's an obvious reason, though. There's no such list. As I described above, C1 doesn't maintain any list of programs that should be added to the Edit with.../Open with... menu. It recomputes everything upon each startup. Just read again my post.

    Before I started to trace what C1 (or the Openwith plugin) is doing, I looked for some configuration file or registry key to which the user's choice would be stored. This doesn't exist or it is very well hidden. If it existed, C1 wouldn't loop again each time it starts, looking for applications that could potentially appear in the Edit with/Open with menu.

    This is why I said "insane" about this code. If we had an external editor manager, all the necessary information would be stored in a configuration file or in the registry once and for all (until the user changes its choices). The list would contain only the external editors specified by the user and for each external application, the export settings would be known in advance.
    0

Post is closed for comments.