Re: [dev] Old bugs related to hyperlinks with bookmark.
On 06/16/2010 09:21 PM, Knut Olav Bøhmer wrote:
As long as the url points to a ".doc" file, my interceptor is not called no
matter if there is a bookmark there or not. It does not matter if ctrl-click
is required or not. There is just NO dispatch interception going on for
".doc" files.
But I get all sorts of other dispatch querys like ".uno:GoUp" or ".uno:Quit"
and "file://" but not as long as it is a .doc file whether the file exists
or not.
Regards
I assume that the code that calls the hyperlink dispatch uses the wrong
way. In code using sfx2 (as e.g. Writer) we have two ways to dispatch,
the "normal" one and an "internal" one that can't be intercepted.
Something like that is necessary, e.g. to handle dispatch events after
possible interceptions ("slave" dispatchers). That sounds interesting
enough to have a look. :-)
In case you are interested: the "normal" dispatch is triggered by
"Execute" calls at an instance of class SfxBindings, while the
"internal" one uses "Execute" calls at an instance of class SfxDispatcher.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16 June 2010 19:39, Mathias Bauer wrote: > Hi Knut Olav, > > > On 16.06.2010 17:57, Knut Olav Bøhmer wrote: > > Is there a (easy) way to tell OOo that we want to handle specific url's >> internally? It could also sometimes be useful to say that we do not want >> to >> handle odt urls internally also (maybe).. But the most important thing is >> to >> get the #bookmarks to work. >> > > For the bookmark case I would fix that in the place I have shown. > > I just discovered that we already have code there that handles the case > where the URL only consists of a jump mark. I will have a closer look and > report my findings in the issue. We can follow-up there. Great! Maybe it would be possible to tell "the system" how to handle url's with > bookmarks? > No, that doesn't work. A "#" is just a letter in a file name, so the URL > "file://foo/bar/text.doc#mark" does not point to the same file as > "file://foo/bar/text.doc". Jump marks in file URLs must be handled > internally. OOo can do that in the same way as a browser can do it for http > URLs. > > > So the .doc did not arrive at my >> dispatcher, because "the system" had taken it. >> > > If the jump to the bookmark would be a result of a click on a hyperlink, > your dispatch interceptor should have seen the dispatch. But the command > isn't the URL, it would the command ".uno:OpenURL" or so, where the file > name (including the jump mark) would be one of its dispatch arguments. Can > you confirm that? As long as the url points to a ".doc" file, my interceptor is not called no matter if there is a bookmark there or not. It does not matter if ctrl-click is required or not. There is just NO dispatch interception going on for ".doc" files. But I get all sorts of other dispatch querys like ".uno:GoUp" or ".uno:Quit" and "file://" but not as long as it is a .doc file whether the file exists or not. Regards -- Knut Olav Bøhmer
Re: [dev] Old bugs related to hyperlinks with bookmark.
Hi Knut Olav, On 16.06.2010 17:57, Knut Olav Bøhmer wrote: Is there a (easy) way to tell OOo that we want to handle specific url's internally? It could also sometimes be useful to say that we do not want to handle odt urls internally also (maybe).. But the most important thing is to get the #bookmarks to work. For the bookmark case I would fix that in the place I have shown. I just discovered that we already have code there that handles the case where the URL only consists of a jump mark. I will have a closer look and report my findings in the issue. We can follow-up there. Maybe it would be possible to tell "the system" how to handle url's with bookmarks? No, that doesn't work. A "#" is just a letter in a file name, so the URL "file://foo/bar/text.doc#mark" does not point to the same file as "file://foo/bar/text.doc". Jump marks in file URLs must be handled internally. OOo can do that in the same way as a browser can do it for http URLs. So the .doc did not arrive at my dispatcher, because "the system" had taken it. If the jump to the bookmark would be a result of a click on a hyperlink, your dispatch interceptor should have seen the dispatch. But the command isn't the URL, it would the command ".uno:OpenURL" or so, where the file name (including the jump mark) would be one of its dispatch arguments. Can you confirm that? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16 June 2010 17:24, Mathias Bauer wrote:
> On 16.06.2010 15:24, Knut Olav Břhmer wrote:
>
>> Hi,
>>
>> There are some old bug related to hyperlinks with bookmark: hyperlinks to
>> .doc files with bookmarks does not work.
>>
>> I think the following bugs are related to each other. And the bug has been
>> there for at least 6 years.
>>
>> http://qa.openoffice.org/issues/show_bug.cgi?id=26957
>> http://qa.openoffice.org/issues/show_bug.cgi?id=109752
>> http://qa.openoffice.org/issues/show_bug.cgi?id=109752
>> http://qa.openoffice.org/issues/show_bug.cgi?id=109752
>> http://qa.openoffice.org/issues/show_bug.cgi?id=19413
>>
>
> Any reason why one the issues is listed three times?
>
Sorry, maybe I copied and pasted from wrong tab. My head was spinning after
many hours of reading things I didn't understand...
> Besides that, these issues are totally unrelated and it doesn't make sense
> to construct a general hyperlink problem that just doesn't exist. Moreover,
> the Calc issue was reported just a few weeks ago. It seems that nobody just
> is aware of it (no QA or dev engineer was involved until now).
>
I wasn't able to reproduce issue 19413, perhaps we should close it.
>
> Then there is issue 26957. It seems that the bug is triggered by the fact
> that the URL to open is handed over to the system, not handled by OOo
> internally. That can't work as "#" in file URLs are not what they are in
> e.g. http URLs. The only solution would be *not* to let the system handle
> the URL (and that's the reason why it works in Word).
>
> Here's the code in sfx2/source/appl/appopen.cxx that decides whether a URL
> shall be handled internally or not:
>
> aTypeName = xTypeDetection->queryTypeByURL( aURL.Main );
>> SfxFilterMatcher& rMatcher = SFX_APP()->GetFilterMatcher();
>> const SfxFilter* pFilter = rMatcher.GetFilter4EA( aTypeName );
>> if ( !pFilter || !( pFilter->IsOwnFormat() ))
>> {
>>
>
>
Thank you! This is the kind of stuff I'd like to learn more about.
> Changing that is a matter of minutes, but the side effect could be larger
> than expected. Allowing to handle all URLs internally that OOo can open
> (detected by pFilter != 0 in the code above) is not wanted, as many other
> formats like e.g jpg, png etc. surely should preferably handled by the
> system and the application registered there.
>
> Another idea: check for "#" in the URL, and in case there is one, handle
> the URL internally.
Is there a (easy) way to tell OOo that we want to handle specific url's
internally? It could also sometimes be useful to say that we do not want to
handle odt urls internally also (maybe).. But the most important thing is to
get the #bookmarks to work.
Maybe it would be possible to tell "the system" how to handle url's with
bookmarks?
>
> In the queryDispatch method the plan was to check for
>> if ((aURL.Complete.startsWith("file://") )&&
>> (aURL.Complete.matches(".*doc#.*") )) {
>> and then use loadComponentFromURL. But .doc hyperlinks never arrived here.
>>
>
> You can't intercept loadComponentFromURL calls with a dispatch interceptor,
> your only can intercept - sic! - dispatch calls
Yes, and that's also why I can use loadComponentFromURL inside a dispatch
interceptor without getting in to trouble. So the .doc did not arrive at my
dispatcher, because "the system" had taken it.
It would be nice if it was possible to intercept things that is handed to
the system also.
Than you so much for answering.
--
Knut Olav Bøhmer
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16.06.2010 15:24, Knut Olav Bøhmer wrote:
Hi,
There are some old bug related to hyperlinks with bookmark: hyperlinks to
.doc files with bookmarks does not work.
I think the following bugs are related to each other. And the bug has been
there for at least 6 years.
http://qa.openoffice.org/issues/show_bug.cgi?id=26957
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=19413
Any reason why one the issues is listed three times?
Besides that, these issues are totally unrelated and it doesn't make
sense to construct a general hyperlink problem that just doesn't exist.
Moreover, the Calc issue was reported just a few weeks ago. It seems
that nobody just is aware of it (no QA or dev engineer was involved
until now).
I wasn't able to reproduce issue 19413, perhaps we should close it.
Then there is issue 26957. It seems that the bug is triggered by the
fact that the URL to open is handed over to the system, not handled by
OOo internally. That can't work as "#" in file URLs are not what they
are in e.g. http URLs. The only solution would be *not* to let the
system handle the URL (and that's the reason why it works in Word).
Here's the code in sfx2/source/appl/appopen.cxx that decides whether a
URL shall be handled internally or not:
aTypeName = xTypeDetection->queryTypeByURL( aURL.Main );
SfxFilterMatcher& rMatcher = SFX_APP()->GetFilterMatcher();
const SfxFilter* pFilter = rMatcher.GetFilter4EA( aTypeName );
if ( !pFilter || !( pFilter->IsOwnFormat() ))
{
Changing that is a matter of minutes, but the side effect could be
larger than expected. Allowing to handle all URLs internally that OOo
can open (detected by pFilter != 0 in the code above) is not wanted, as
many other formats like e.g jpg, png etc. surely should preferably
handled by the system and the application registered there.
Another idea: check for "#" in the URL, and in case there is one, handle
the URL internally.
In the queryDispatch method the plan was to check for
if ((aURL.Complete.startsWith("file://") )&&
(aURL.Complete.matches(".*doc#.*") )) {
and then use loadComponentFromURL. But .doc hyperlinks never arrived here.
You can't intercept loadComponentFromURL calls with a dispatch
interceptor, your only can intercept - sic! - dispatch calls.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
