[dev] Old bugs related to hyperlinks with bookmark.
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
I could try to fix the bug myself, and I would very much like that, but I
don't have the knowledge.
So if someone could guide me and point me in the right direction, I would be
very happy.
I find it strange that this bugs are not fixed as hyperlinks are quite an
essential feature of electronic documents.
I have tried to make a workaround for this problem by making a
DispatchProviderInterceptor that handles opening of hyperlinks. In this
effort I found another bug (probably a bug). Hyperlinks to .doc files is
not possible to intercept.
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.
So now my plan is to make a macro that loops through the document, and
rewrites every hyperlink with bookmark, like this
file:///file.doc#bookmark , to something like
file:///file.odt#[doc]bookmark, and manipulate the url, so that it opens the
correct file. I have already made a small experiment that works. If someone
wants the final workaround, you can email me. There are several issues with
doing it this way: the document gets dirty and want's to be saved when you
quit. And when you save, the hyperlinks have to be rewritten back to
.doc#bookmark (I plan to handle that too.).
I wonder why .doc hyperlinks can not be intercepted. I would consider it a
good idea if what you'd write in the hyperlink field would be arbitrary, so
that new functionality could be written to hyperlinks by intercepting the
dispatch.
So, could anyone help me?
--
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
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16 June 2010 17:24, Mathias Bauer nospamfor...@gmx.de 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.
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 19:39, Mathias Bauer nospamfor...@gmx.de 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.
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
