On 2/5/2014 21:56, Stefan Küng wrote:
> On 05.02.2014 14:33, Cosmin Pirvu wrote:
>> On 2/5/2014 13:53, Simon Large wrote:
>>> On 5 February 2014 12:19, Cosmin Pirvu <cosmin.pirvu_at_asitrack.com
>>> <mailto:cosmin.pirvu_at_asitrack.com>> wrote:
>>> Hi guys,
>>> I'm trying to integrate a custom issue tracker with tortoisesvn. My
>>> bugtraq:url looks something like this:
>>> According to the documentation, the bugtraq:url can be any properly
>>> enconded URI that contains %BUGID%:
>>> Seems to work so far. But when I click the issue link in the log
>>> nothing happens. Any ideas?
>>> Don't you need to set up a protocol handler for this? If there is an
>>> http: prefix then the link gets opened in a web browser but how would
>>> the system know what to do with a file:// prefix? If you create a
>>> Windows shortcut with that URI and double click it, what happens?
>> I was actually hoping for a response from a developer or someone who
>> knows the code (how the system works). The shortcut example is not good
>> because Windows assumes it's an Internet Shortcut and treats it as an URL.
>> Basically, when writing code URI management is done in two ways: a smart
>> way and a bad way.
>> In the smart way you filter the "file://" protocol and treat it
>> separately because it can point to any type of file. In the bad way you
>> assume all URIs are URLs (web pages) and the "file://" stuff doesn't
>> work unless you're lucky.
>> So perhaps a better question would be: Does bugtraq:url support
>> "file://" for files which are not web pages?
> First of all, the smart way is to treat file:// urls the very same as
> other url types and let the system handle the differences.
> And maybe that's why it doesn't work for you: the OS treats those
> file:// urls differently because of security concerns. You have to set
> the security settings accordingly.
> Also, what are the exact properties and values you've set and what
> exactly happens or does not happen?
ShellExecute on Windows launches this URI as expected:
I figured that maybe, if I was lucky, a developer handled the case when
the "file:///" path has parameters for the launched file. Simply extract
the parameters from the URI and pass them along to ShellExecute.
So it's not a problem of security or settings. The "file://" protocol is
simply handled as an URL and passed along to the OS as is.
Anyway, it was worth a shot. I will try to find a workaround.
Thank you for the replies and your time. They helped me move on.
All the best,
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-02-06 00:06:08 CET