Issue C1 20.0.2 and Open With plugin
Hi,
installed last evening, version 20.0.2 brings a issue with the Open With plugin which cannot initialize and is declared disabled. This issue prohibits the use of the "Open with" and "Edit with" functions.
A reinstall did not change anything.
I send a request to the support currently without response (it was not the usual).
Win 10 Home 1909.
installed last evening, version 20.0.2 brings a issue with the Open With plugin which cannot initialize and is declared disabled. This issue prohibits the use of the "Open with" and "Edit with" functions.
A reinstall did not change anything.
I send a request to the support currently without response (it was not the usual).
Win 10 Home 1909.
0
-
pgrat wrote:
Samoreen wrote:
This indicates that the plugin is trying to find firefox.exe in the folder where the OpenWith plugin is installed ? ? ? Which doesn't make sense. But the exception is catched by the code since the plugin continues to work. I also have the same error with architect.exe (PDF Architect, my PDF Editor). Absolute nonsense.
I also had that with the V12 ...[2019-04-22 11:20:14.019][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-04-22 11:20:51.875][855][ID:007, ]{PLUG } | GetSettingsAsync
[2019-04-22 11:20:52.899][024][ID:010, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 12 Sony\Plugins\OpenWith\firefox.exe
**| Ã System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| Ã BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2019-04-22 11:20:52.901][001][ID:010, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 12 Sony\Plugins\OpenWith\Iridient X-Transformer.exe
**| Ã System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| Ã BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
I note that the Firefox (and some other unlikely applications) announce themselves as candidates for opening various RAW files in the Windows file association entries in the registry. Probably because the application claims to be able to at least display them by reading the internal jpgs?
Therefore it seems reasonable that C1 would accept the apparent availability of Firefox (and the others) as application with which a user might choose to open certain types of file, illogical as that may be for photo editing purposes.
The allowed Applications option in the Preferences tab for Plug-ins seems to be place where the Windows offered applications can be filtered for the purposes of the C1 user. User can make whatever choices they want and reject them if they don't work. Or, better, not accept them in the first place.
One could also break the association ot the file in windows but with application like Firefox that are updated so frequently it is probably a good assumption that any broken associations that it feels it should make would be 'repaired' the next time it is updated.
On that basis I feel I must be missing something about this discussion.
Windows accepted the claims of file compatibility from applications and creates a library list of possibles for all applications to use.
Application uses the list and provides its users with an option to mark them as having possible interest.
Once so marked the selected programs are offered when the plug-in option is activated but user may also go searching for other applications through the library should they so wish.
Is that the functionality people desire or is there something else?
I'm looking at Win 7 - does Win 10 do things differently?
Grant0 -
SFA wrote:
I note that the Firefox (and some other unlikely applications) announce themselves as candidates for opening various RAW files in the Windows file association entries in the registry. Probably because the application claims to be able to at least display them by reading the internal jpgs?
Therefore it seems reasonable that C1 would accept the apparent availability of Firefox (and the others) as application with which a user might choose to open certain types of file, illogical as that may be for photo editing purposes.
This is exactly why the current approach is nonsense. Trying to determine which applications are an eligible candidate for external editing from C1 by reading information from the registry is just doomed to failure. For many reasons.
- The result can be totally illogical (as it is now).
- The registry contains a lot of leftovers about applications that are no longer there.
- Some application that would be valid for external editing from C1 are just not registering themselves as possible editor for such or such file type.
- The user has very little influence on the resulting list (which appear to be limited in length, by the way). One can discard application appearing in the list built by the plugin but adding application is awkward and sometimes impossible.
- There is no way to specify the export options for each application separately.
The only workable approach is to let the user specify what application should appear in the list and for each application determine the specific export parameters for that application. Period. This is how all other image processing applications work and I don't understand why the C1 development team insists on forcing us to use this ridiculous and buggy plugin.
The request for a decent external editor manager has been posted at least since version 9 and it's really time that something be done. This is not a big programming effort and if this had been planned years ago we wouldn't have these ludicrous discussions today.0 -
Samoreen wrote:
This is exactly why the current approach is nonsense. Trying to determine which applications are an eligible candidate for external editing from C1 by reading information from the registry is just doomed to failure. For many reasons.
- The result can be totally illogical (as it is now).
- The registry contains a lot of leftovers about applications that are no longer there.
- Some application that would be valid for external editing from C1 are just not registering themselves as possible editor for such or such file type.
- The user has very little influence on the resulting list (which appear to be limited in length, by the way). One can discard application appearing in the list built by the plugin but adding application is awkward and sometimes impossible.
- There is no way to specify the export options for each application separately.
The only workable approach is to let the user specify what application should appear in the list and for each application determine the specific export parameters for that application. Period. This is how all other image processing applications work and I don't understand why the C1 development team insists on forcing us to use this ridiculous and buggy plugin.
The request for a decent external editor manager has been posted at least since version 9 and it's really time that something be done. This is not a big programming effort and if this had been planned years ago we wouldn't have these ludicrous discussions today.
Totally agreed !0 -
SFA wrote:
pgrat wrote:
Samoreen wrote:
This indicates that the plugin is trying to find firefox.exe in the folder where the OpenWith plugin is installed ? ? ? Which doesn't make sense. But the exception is catched by the code since the plugin continues to work. I also have the same error with architect.exe (PDF Architect, my PDF Editor). Absolute nonsense.
I also had that with the V12 ...[2019-04-22 11:20:14.019][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-04-22 11:20:51.875][855][ID:007, ]{PLUG } | GetSettingsAsync
[2019-04-22 11:20:52.899][024][ID:010, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 12 Sony\Plugins\OpenWith\firefox.exe
**| Ã System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| Ã BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
[2019-04-22 11:20:52.901][001][ID:010, ]{PLUG } | path - System.IO.FileNotFoundException: C:\Program Files\Phase One\Capture One 12 Sony\Plugins\OpenWith\Iridient X-Transformer.exe
**| Ã System.Drawing.Icon.ExtractAssociatedIcon(String filePath, Int32 index)
**| Ã BuiltInOpenWithPlugin.BuiltInOpenWithPlugin.GetAssociatedIconFromPath(String argPath)
I note that the Firefox (and some other unlikely applications) announce themselves as candidates for opening various RAW files in the Windows file association entries in the registry. Probably because the application claims to be able to at least display them by reading the internal jpgs?
Therefore it seems reasonable that C1 would accept the apparent availability of Firefox (and the others) as application with which a user might choose to open certain types of file, illogical as that may be for photo editing purposes.
The allowed Applications option in the Preferences tab for Plug-ins seems to be place where the Windows offered applications can be filtered for the purposes of the C1 user. User can make whatever choices they want and reject them if they don't work. Or, better, not accept them in the first place.
One could also break the association ot the file in windows but with application like Firefox that are updated so frequently it is probably a good assumption that any broken associations that it feels it should make would be 'repaired' the next time it is updated.
On that basis I feel I must be missing something about this discussion.
Windows accepted the claims of file compatibility from applications and creates a library list of possibles for all applications to use.
Application uses the list and provides its users with an option to mark them as having possible interest.
Once so marked the selected programs are offered when the plug-in option is activated but user may also go searching for other applications through the library should they so wish.
Is that the functionality people desire or is there something else?
I'm looking at Win 7 - does Win 10 do things differently?
Grant
What users want is what is available in every other image editor that accesses external programs in Windows. Unlike Mac the Windows OS does not take care of this functionality. Capture One need to not shrug there shoulders about the lack of functionality of Win compared to Mac but fully support their software on Windows. They charge the same price.
Finally "What Samoreen said", he fully understands the situation.
This is exactly why the current approach is nonsense. Trying to determine which applications are an eligible candidate for external editing from C1 by reading information from the registry is just doomed to failure. For many reasons.
- The result can be totally illogical (as it is now).
- The registry contains a lot of leftovers about applications that are no longer there.
- Some application that would be valid for external editing from C1 are just not registering themselves as possible editor for such or such file type.
- The user has very little influence on the resulting list (which appear to be limited in length, by the way). One can discard application appearing in the list built by the plugin but adding application is awkward and sometimes impossible.
- There is no way to specify the export options for each application separately.
The only workable approach is to let the user specify what application should appear in the list and for each application determine the specific export parameters for that application. Period. This is how all other image processing applications work and I don't understand why the C1 development team insists on forcing us to use this ridiculous and buggy plugin.
The request for a decent external editor manager has been posted at least since version 9 and it's really time that something be done. This is not a big programming effort and if this had been planned years ago we wouldn't have these ludicrous discussions today.0 -
I have the same issue that the plugin is not working on my main PC.
On the laptop (both running windows 10 1909) it's working.
I copied already the complete configuration files from the working to the non-working PC and it did not resolve the problem.
I found the log files which support asked me to provide and have seen that the 'scanning for potential programs' routine in C1 generate errors on one PC (also some of the errors are related to FireFox) and does not generate errors on the other.
<Even after de-installing Firefox it did not work.
The error states that the routine tries to get the icon from the apps which are registered to open certain extensions and some apps return null icon and therefore the C1 extension fails and doe not proceed on next extension.
So it's a simple programming error to exclude just those apps generating errors and not let complete process fail.0 -
Franz1 wrote:
I have the same issue that the plugin is not working on my main PC.
On the laptop (both running windows 10 1909) it's working.
I copied already the complete configuration files from the working to the non-working PC and it did not resolve the problem.
I found the log files which support asked me to provide and have seen that the 'scanning for potential programs' routine in C1 generate errors on one PC (also some of the errors are related to FireFox) and does not generate errors on the other.
<Even after de-installing Firefox it did not work.
The error states that the routine tries to get the icon from the apps which are registered to open certain extensions and some apps return null icon and therefore the C1 extension fails and doe not proceed on next extension.
So it's a simple programming error to exclude just those apps generating errors and not let complete process fail.
This is a lesson in how to annoy your customers simply because you are too pig headed to institute a simple "add probram to plugins routine".
Sad really and highly unprofessional.
All we can do is keep calling them out on this and see if they will eventually do something. Probably not much hope, I mean we are only the paying customers, why take any notice of them?
Ian0 -
I have the same problem on 20.0.2. After unsuccessfully fiddling (reinstall C1 and plugin) eventually came to this post.
Downgraded to 20.0.0 and problem disapppeared. Do I risk going back up to 20.0.2???0 -
MikeW wrote:
Do I risk going back up to 20.0.2???
Others have already tried that. If the plugin didn't work the first time with 20.0.2, it will not work upon a re-installation either.0 -
Well I just confirmed that !! 😊
BAck up to 20.0.2 didn't work. Back to 20.0.0 working.
Leaving it there till a fix appears.0 -
Samoreen wrote:
- The result can be totally illogical (as it is now).
- The registry contains a lot of leftovers about applications that are no longer there.
There are 3 situations in the main.
A program has registered a file type that Capture One also supports because it can do something with them. jpgs for example. So it appears on the proffered list of "possibles" from Windows.
A tidy registry is a marginal complaint against Microsoft or - at an extreme pinch - the user's personal approach to dealing with tidying up activities. A dirty registry is hardly a negative for Capture One. Anyone not too worried about a super clean registry probably won't be too worried about keeping a self created list of acceptable applications clean either.
An application does not choose to register its abilities for working with specific files by type and so users need to add it themselves.
What part of that does the current system not cover?
I see a list of possibles.
I tick the ones I am interested in.
If I want to use something not listed (that is also not a dedicated C1 Plug-in development) I can go and find it and create association using the Preferences facility. I can also untick any once used but no longer available applications.Samoreen wrote:
- Some application that would be valid for external editing from C1 are just not registering themselves as possible editor for such or such file type.
So if the users knows they are there they can be added and ticked.
If they are not aware they have the application they are probably not looking for it anyway and not expecting to find it.Samoreen wrote:
- The user has very little influence on the resulting list (which appear to be limited in length, by the way). One can discard application appearing in the list built by the plugin but adding application is awkward and sometimes impossible.
How so? Not a situation I have experienced.
There is a search facility for known possible applications if the list is long. In the end, for presumably relatively rare additions and removals in the case of most users, what would be the difference compared to supplying a user tool that requires the user to manually add and exclude applications to get anything at all? (Which seems to be what you are proposing if you reject the Windows known file associations route.)Samoreen wrote:
- There is no way to specify the export options for each application separately.
Do you mean default preferences for Edit With? Or a list of presets that can be used to choose options for the specific Edit with? Is that sort of functionality not already available either at the point of choosing Edit with or by taking the equivalent action using an Output Recipe?
Or are you seeking the option to send some parameters to the external application for Open With that might need to overwrite its own built in application defaults for that file type?Samoreen wrote:
The only workable approach is to let the user specify what application should appear in the list and for each application determine the specific export parameters for that application. Period. This is how all other image processing applications work and I don't understand why the C1 development team insists on forcing us to use this ridiculous and buggy plugin.
I'm obviously not using the right sort of plug-in applications - or my system is simply not using what is available in the same way that others are find that their system uses what is available.
If I'm seeing what the Phase One team are seeing they are probably wondering why people are so worked up about the subject.
The last thing I would want to have to do would be to manage each and every application that I might somehow want to use as a plug-in.
If it's a special development, fair enough. Make me manage it from the installation onwards.
But if its a regular photo manipulation application that I might want to use from time to time and is readily available in the system why on earth would I want to have to manage it any more than ticking a box to say I want to have it available to me if I use Edit With or Open With.
As far as having a limit top the number of applications available ... my preferences show 16 possible applications. If I tick all of them I get 16 listed for use if I choose Edit With. Perhaps someone with a larger number of possible applications could check for larger numbers on the list?
Fundamentally I don't see anything requested here that is not already available in some way within Capture One - other than wanting all brought together into a single (possibly rather opaque) menu option to add another layer of management requiring user attention.
As I wrote earlier, perhaps the C1 team also thinks they have the ground covered without a need to add more workload for the user. Especially the less technical user for the simpler of the 'integration' tasks.
If you are all seeing lost of inconsistencies ... have you checked the user.config file for its cleanliness if it has been carried forward over possibly many versions?
Grant0 -
Logged my issue with support and got a very bland reply which led me to believe my fault description wasn't read at all.!!
As a result not even an acknowledgement that it was a known issue since I am aware other folk have also logged it.
Having worked in the Software support industry before I retired (12 years ago!!) it was not the sort of response I was expecting but sadly, have now come to expect......0 -
SFA wrote:
Samoreen wrote:
Fundamentally I don't see anything requested here that is not already available in some way within Capture One
Really ? So, please tell me how you define once and for all specific export parameters for a given external program. Just an example.
Very frankly, I don't understand why you are trying to justify an implementation that cannot honestly be justified. Unless you're acting as an evangelist (something you are doing rather often), in which case your statements are biased.0 -
Samoreen wrote:
SFA wrote:
Samoreen wrote:
Fundamentally I don't see anything requested here that is not already available in some way within Capture One
Really ? So, please tell me how you define once and for all specific export parameters for a given external program. Just an example.
Very frankly, I don't understand why you are trying to justify an implementation that cannot honestly be justified. Unless you're acting as an evangelist (something you are doing rather often), in which case your statements are biased.
What export parameters are you thinking of? For which sort of program?
Some things generic or some things that are very specific for the target application?0 -
SFA wrote:
What export parameters are you thinking of? For which sort of program?
I suspect you are not using this Edit/Open with... feature very often.
Let's take an example. When I send an image that I have processed (not yet exported) in Lightroom for further retouching in Photoshop (because I need PS features that LR doesn't have), I don't need to explicitly export that image with specific parameters and then open it in Lightroom. I just have to right-click and select "Edit in... Photoshop". The export parameters have already been set once for all in the Lightroom External Editors Manager (that obvious thing that doesn't exist in C1) where I specified that when sending a image to PS, I want it to be exported as a 16-bit TIFF file using the Prophoto color space and internally compressed using the ZIP algorithm. When editing in another app, I may want different export parameters which I'll be able to specify the same way. I could even create multiple entries for the same external program but with different export settings, depending on my needs.
In C1, although it remembers my last export settings for a given external application, the export parameters dialog is presented each time. Also, I can't have different sets of export settings for the same application. But this is not the biggest problem.
1. The main issue is the way the list of available external programs is slowly rebuilt (each time the Edit/Open with menu is opened). As explained above, this doesn't make sense.
2. Now about the relevance of that list. Let's assume that the external application I want to use with Open with... or Edit with... doesn't appear in the list built by the plugin, probably for the reasons I have explained above. Then I must resort to the Browse... command. OK. One would expect that after selecting the target external application, it would be added to the OpenWIth plugin list. Nope. One could also expect that this application could be manually added to the list in Preferences | Plugin | OpenWith. No way (or please show me). So for that application, you'll have to browse for the target .exe each time you need to use it. Strangely enough, the export settings for that application are remembered, though. Not very consistent.
3. Open with... and Edit with... have different purposes. Edit with means that you want to further process in an external program an image that has already been worked on in C1. So you generally export the photo in TIFF or JPEG format to a program working on raster images. Now, let's assume that you want to process a RAW file in another program because C1 cannot handle it properly (yes, this can happen). In that case, you will not export to a TIFF/JPEG file, you'll want to send the RAW file directly to the external application. You'll do that with Open with.... Ditto when sending a TIFF or JPEG from C1 to an external viewer.
This means that since Open with... and Edit with... have different purposes and most often different target applications, there should be a separate program list for each command in the plugin. Basically the Open with... vs. Edit with... idea is excellent (Open with... in Lightroom must be done with a script). But it is ruined by this poor implementation. In no way C1 will be able to build 2 different lists by only using information found in the registry. Only the user knows what programs should belong to which list. And he can specify this only in a dedicated, user configurable External Editors Manager.
Grant, you may try again and again, you'll never convince me (and others) that the current implementation of external editing is relevant. This feature has to be implemented the same way it is in similar programs. There's no choice.0 -
Samoreen,
Yes I have no doubt that I will never convince you and I suspect that the Capture One team will not convince you either BUT nor am I convinced about the claimed benefits (for many users) of having to define from scratch some sort of external application management program.
I'll ignore LR and PS and the rest of the Adobe family. If Adobe cannot or did not provide tight integration throughout their suite of products one would have to wonder why.
Firstly "Open" with from the Menus or via Right Click.
It's a simple instruction to open file with a different application. That application has its own parameters about what to do with such a file on opening. In general I don't really see (for any applications I can think of that might be invoked from C1 for entirely unconnected processing) the need for any parameters at all to be sent from C1.
Secondly "Edit with".
Typical parameters can be established during the "Edit With" process and appear to be "sticky" for that external target until from one use to the next.
What you seem to be asking for within that concept is an option to have different predefined parameters available for a listed external "Edit with" candidate and be able to choose between them if required rather than have to change the parameters separately at the time of use. Is that correct?
If it IS correct than the OTHER "Open with" option which is part of the Output Process Recipe seems to offer a solution. (It should perhaps be referred to as "Edit with" BUT is not quite the assumed pseudo plug-in functionality that the "Edit with" offers.
So one could have multiple Recipes for a given target "plug-in/external editor" and simply select the one required, hit the Process key and obtain "Edit with" functionality (but without the assumption, AFAIK, that on closing the external editor the resulting file will be saved back to the folder of origin.)
So far as I understand your requests to date that pretty much covers the requirement as far as already available functionality in C1 is concerned.
There might be some tweaks to be suggested and it might be that the Recipe based functionality could be included via other options - added to "Edit with" perhaps - but it does seem to exist.
For a moment forgetting about the "management of the plug-ins", am I missing something critical about the available features (irrespective of where they are to be found.)?
Moving to the main part of the subject. (and ignoring Adobe products for the reasons mentioned above)
I took a closer look at Affinity photo and what it offers for Edit With, Open With and plug-ins.
So far I have not found a reference to "Edit with" or "Open with".
Since is does not offer a DAM function I would conclude that "Open with" is an irrelevant concept for Affinity at this time.
"Edit with" looks like it would be included into the Plug-in manager to be found in the Preferences.
By default the Management window open the "Plug-Ins" folder where it expects to find Photoshop plug-ins. No surprise since Affinity is basically a Photoshop lookalike with a RAW file "Developer" module included. So somewhat akin to PS and LR but without the LR DAM facilities.
Having no PS plug-ins on my system the window in Affinity is blank.
So far as I can tell there is currently no external "Interoperability" available other than with other Affinity applications.
This probably explains why any development rationale that might seek to offer pre-identified (via Windows File Associations) applications of potential interest are not considered in any way.
I'll have to go looking for another example of best practise.
But, PS plug-in compatibility excepted, my view on a "Manager" for external applications for use with "Edit With" or "Open With" (Either version of Open with) is as follows.
If the application developer has identified the type of files that the application might be able to work with and registered that information with MS Windows I think that is more likely helpful rather than unhelpful. It means I have to do nothing other than browse a list and select which applications I may be interest to use more often than not. Easily managed.
If I install a new application which self identifies I can add it to the list in very few keyclicks - perhaps removing others that it replaces. It takes second and I'm not likely to do it often - but other might so that have even greater benefits of speed.
If I want to include an application that is NOT self identified to Windows but that I know has some compatibility and so I wish to use it, I have to go and browse to the application and select it. If it's a one-off activity I may choose to do that at run-time if I am likely to use it multiple times I can browse and then add it to my "approved" list via the Preferences > Plug-in manager. After which it will be a readily available option without having to go and find it again.
If I want choose (potentially) different but frequently used parameters each time I use it I can set up a Process Recipe (or several) and select the newly added program form the available list in the "Open with" box of the Recipe definition. Then select and run the recipe (as a batch if required) to send the file, with parameters, to the external program.
Yes, I realise that there are more closely coupled "Plug-ins" for C1 and some of those may indeed benefit for parameters that are not a normal part of a recipe being passed on but then that is why those plug-ins have their own developments and typically require some form of funding to make use of them.
To summarise;
From my perspective using Windows the ability to manage compatible applications (via Preferences) and choose which should be listed and promoted in a "select from" list is well covered and greatly assisted by not having to find and connect all of them from scratch. It is simple enough, IMO, for even the least tech inclined user to be able to feel comfortable with it in most cases using recent software.
In principle the type of features being suggested already seem to exist for typical "Edit with" applications.
They may not be collected into one central management application but they are available, generally, with a context sensitive deployment.
There may be some further suggestions for refinement of functionality and its location that could benefit users. That might also be something that is best offered with the benefit of context for use. The most obvious one might be the option to add an output recipe selection to the "Edit with" menu/right-click feature (limited to only those recipes that have an an application identified in their "Open with" field.
The addition of further parameters to the recipe might be another option although anything really specific and detailed might be better dealt with as a dedicated plug-in instead
By the way, for your point 1 - what is "slowly rebuilt" referring to. I can't think of any connection to the available application list that I have seen that I would categorise as "slowly rebuilt". I am genuinely puzzled by the observation.
If you have a usable application that does not self identify to Windows (I cannot think of one on my system though I might experiment with any application of course) then that anomaly is simple enough to rectify by using Windows file associations to make it self identify. It''s a one-off activity (usually).
I'm not sure why there is (for most people) a need to differentiate between lists for Open with and Edit with.
When I use either function I am usually clear in my mind what I intend to do (unless just undertaking some random experimentation.)
That said one might add a could add a couple of qualifying flags to the entries, I suppose, if usage was to be restricted by type of usage and application. It sounds like you may use rather a lot of external applications of one sort or another. Perhaps more than most people?
Are you perhaps applying a lot of separate plug-ins to the same image but doing it one at a time via Edit with? Or something like that?
Grant0 -
The bug must be fixed, if it occurs on several machines, I believe Franz1 nailed it.
We can not conclude though that P1 has failed in regression testing as this bug does not occur on all machines. Not on my either, btw.
A failure of senior management or alike saying is not justified, not in this aerea discussed here.
If the browse option does not remember an application and there is no way to keep it in the lust thatv is a major annoyance for some, I can understand.
Tweaking / finetuning of this topic would be most welcome.
Not my priotity though, I am glad the management had other priorities e.g. The Luminance mask over an Extended LR like External application manager.
I have other open wishes though.
Id like to encourage everyone to submit feature request to enable the company to make good decicions, decisions based on number of people requesting.
Regards
BeO0 -
Still no update to fix this ...........
0 -
Since I can't use Capture One without this plugin, I went back to the previous release.
I hope a future update will solve this problem and some others...
0 -
The same for me.... back to 20.0.0
0 -
Hi there,
the version 20.0.3 has just been released but unfortunately, the bug "open with" plugin is still present!
What was the use of reporting this bug to the support when the version 20.0.2 was released more than a month ago?
For information, the support sent me an email 20 days after my bug report to tell me that it was transmitting to the development team !! A joke !
I am still forced to stay at version 20.0.0 and no matter what new cameras are supported.
I'm starting to be really disappointed with Capture One.1 -
Just for the record.
V20.0.2 on Win 7 Pro.
No problems.
I happened to install the Affinity Photo update this morning. It was automatically found by the Plug-in manager (as expected) and both "Open with" and "Edit with" working as expected.
0 -
@SFA, you are lucky !
For me :
20.0.2 does not work,
20.0.3 does not work
only 20.0.0 works fine.
0 -
> @SFA, you are lucky !
Lucky ? Not half ! SFA is a happiness spitting machine. Never hit by a bug, always happy with whatever version of C1 he gets, always finding good excuses for P1 not doing the job... I'm envious :--)) .
1 -
> For me :
20.0.2 does not work,
20.0.3 does not work
only 20.0.0 works fine.
Same for me. It's a SHAME that they did not address this major bug ! Will they ever take it into account ?
1 -
Folks,
Most of the Log file entries quoted earlier are things I also see on my system.
They appear to be related to not finding a suitable program Icon to display next to program entry in the Plug-in manager.
Slightly ugly but not the end of the world.
If anyone feels OK about sharing their Plug-in specific Log files (via a file sharing service) I would be happy enough to compare them with mine to identify any differences that might help us (and the Phase crew) to identify potential problem areas.
Grant
-1 -
Grant
Thank you for trying to help but the problem is not as you say in your post : it is not a matter of program icon not found.
It is a problem of cast, as you can see in pgrat's log in page 1 of this thread. I reproduce hereunder the end of the log :
[2020-01-28 09:07:13.059][051][ID:001, ]{PLUG } | Discovery OK
[2020-01-28 09:07:13.060][000][ID:001, ]{PLUG } | Creating a new instance...
[2020-01-28 09:07:13.626][566][ID:001, ]{PLUG } | Exception of Type : System.Reflection.TargetInvocationException
**| Message : Une exception a été levée par la cible d'un appel.
[2020-01-28 09:07:13.626][000][ID:001, ]{PLUG } | Exception of Type : System.InvalidCastException
**| Message : Impossible d'effectuer un cast d'un objet de type 'System.String[]' en type 'System.String'.
[2020-01-28 09:07:13.626][000][ID:001, ]{PLUG } | Plugin exitingI have the same exceptions (with both V20.0.2 and V20.0.3) and it's up to Phase One to fix this problem !
1 -
> I have the same exceptions (with both V20.0.2 and V20.0.3) and it's up to Phase One to fix this problem !
Correct. As I have already stated, this a programming error. A bug.
1 -
I note that most of the people with problems seem likely to be using the French version.
Just wondering of that might be significant in any way? (Not sure about Adam52 and Mike Watson.)
Given that my log file shows no instances of any part of the error code text reported above at all I wonder if the problem is happening with some specific Windows "Associated" programs and so identifying what are and are not common to all systems that have the problem might help identify exactly where the problem occurs. Absent that knowledge it may be difficult to reproduce the problem to identify any coding weakness that has suddenly appeared between V20.0.0 and V20.0.2 - and does not seem to apply to everyone.
0 -
> Absent that knowledge it may be difficult to reproduce the problem to identify any coding weakness that has suddenly appeared between V20.0.0 and V20.0.2.
That's the role of the developers, not ours ... an amendment has been made to this subject which appears on the release note.
0 -
I have the same proble with version 20.0.2 and 20.0.3
[2020-03-02 21:56:03.747][000][ID:001, ]{APPL } | Application started, version PluginHost 1.0 - Located at: C:\Program Files\Phase One\Capture One 20.0.3\P1.C1.PluginHostProcess.exe
[2020-03-02 21:56:03.747][000][ID:001, ]{APPL } | Running on Microsoft Windows NT 6.2.9200.0
[2020-03-02 21:56:03.756][008][ID:001, ]{PLUG } | InitializationStarting
[2020-03-02 21:56:03.759][003][ID:001, ]{LOG } | Log file initialized.
[2020-03-02 21:56:03.759][000][ID:001, ]{PLUG } | Parameters: C:\Program Files\Phase One\Capture One 20.0.3\Plugins\OpenWith BuiltInOpenWithPlugin com.phaseone.openwith
[2020-03-02 21:56:03.763][003][ID:001, ]{PLUG } | Discovering...
[2020-03-02 21:56:03.764][000][ID:001, ]{PLUG } | Discovering from path: C:\Program Files\Phase One\Capture One 20.0.3\Plugins\OpenWith with entry point: BuiltInOpenWithPlugin
[2020-03-02 21:56:03.764][000][ID:001, ]{PLUG } | Dlls discovered: C:\Program Files\Phase One\Capture One 20.0.3\Plugins\OpenWith\OpenWithPlugin.dll C:\Program Files\Phase One\Capture One 20.0.3\Plugins\OpenWith\P1.C1.Localization.dll
[2020-03-02 21:56:03.779][015][ID:001, ]{PLUG } | Discovery OK
[2020-03-02 21:56:03.779][000][ID:001, ]{PLUG } | Creating a new instance...
[2020-03-02 21:56:04.157][377][ID:001, ]{PLUG } | Exception of Type : System.Reflection.TargetInvocationException
**| Message : Se produjo una excepción en el destino de la invocación.
[2020-03-02 21:56:04.157][000][ID:001, ]{PLUG } | Exception of Type : System.InvalidCastException
**| Message : No se puede convertir un objeto de tipo 'System.String[]' al tipo 'System.String'.
[2020-03-02 21:56:04.157][000][ID:001, ]{PLUG } | Plugin exiting1
Post is closed for comments.
Comments
81 comments