Apache OpenOffice (AOO) Bugzilla – Issue 94891
Extensions : contextual help does not work anymore
Last modified: 2008-12-08 12:25:54 UTC
I updated from 2.4.1 to OOO300m9. In 2.4.1 there was an extension with contextual help. In OOO300m9 the extension still works, the help may be displayed from the index pane, but the contextual help does not work. In OOO300m9 I installed another extension, same problem.
Created attachment 57130 [details] Extension created to test help system in 3.0
The above attachment creates a simple extension. Use it with english UI. After OOo restart you can see a new node in the help tree : "How to write a help". On a new Writer document you see a new toolbar "Test of the help". Click on the "heart" button, it starts a dialog from Basic library basTest4. The contextual help is defined in this dialog but when you hit F1 the help page is not found.
Confirmed with OOo3 RC4, on Kubuntu 8.04: contextual help, working in OOo 2.4.1, does not work anymore! Showstopper? The only workaround I found is assigning to the dialogs or buttons HelpURL: "vnd.sun.star.script:odt2pml.ConvertASCII.sbAsciiWizard?language=Basic&location=application" (from the compiled help page), instead of a defined one, like: "org.Rup.Xamqon.odt2pml.O1". But that works only for help pages that are directly linked to some subroutine. Others have no more contextual help...
@ jsk: Please have a look.
Confirmed, but this is no stopper for 3.0. Assigning to AB who made the extensible help framework. Setting target 3.0.1 (is a regression).
After having a closer look, I found that this is no bug. The extension is wrong, it does not meet the corresponding specification. As described in http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Help_Content in paragraph "Context sensitive help and extended tool tips" a Command URL has to be used to bind Toolbar items or controls to their corresponding help pages. The problem is that "org.Rup.Xamqon.odt2pml.O1" is no URL at all as it does not meet the scheme "<protocol>:<anything>". Unfortunately in 2.4 this wasn't tested and so also non URLs were accepted. But this was a bug corrupting other functionality, especially the context sensitive help inside the Basic IDE (pressing F1 while the cursor is placed on a keyword/command opens the corresponding help). To fix this (see http://www.openoffice.org/issues/show_bug.cgi?id=90162) only Help URLs really meeting the URL scheme are considered to be links to help pages while everything else is used to perform a search. The workaround works because there a valid URL is used. So, to solve this problem the extension has to be fixed. -> INVALID
Reopened As this problem doesn't seem to be exotic (other extension seem to have similar problems) I had another look and now prefer to accept at least strings containing . as help URL although they are not really URLs. The fix of i90162 still works.
FIXED, -> cws ab64
I think it is more a problem of ambiguous documentation. http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/ Help_Content "It's important to choose a unique Command URL, e.g. by following a similar scheme like for the extension identifier or to refer to a service implementing the functionality." The scheme for the extension identifier does not request the use of colon character.
ab->bmarcelly: Similar, not the same as a URL is required... But you are right, this isn't very clear. But it's fixed now anyway... :-)
ab->jsk: Please verify
The test extension now brings me to a page called "Writing a help page, introduction". Verified.
Looks good in m12. Closing