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
[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