Apache OpenOffice (AOO) Bugzilla – Issue 93453
no context sensitive help at all in database forms
Last modified: 2009-04-13 01:51:29 UTC
- open the attached database document - open the contained form for editing ("Edit" in its context menu) - double-click the control in the form to open its property browser - focus any input control in the property browser - press F1 => the help viewer opens => the current component in the Help window is "OpenOffice.org Writer" (it should probably be Base instead) => the help text is empty The expected result is that the help for the focused property is displayed. This help topic is there, as you can see when you search for the propertie's name, but it's just not displayed. This is not only a problem with the property browser, but seemingly with *all* help in a database form. For instance, another manifestation is - Help / What's This? => the mouse cursor changes in an arrow with question mark - hover over an arbitrary item in an arbitrary toolbar of the database form => no help text appears If you do the same in a text document, the quick help texts appear as expected. My conclusion/assumption is that there's some code in the help framework, which decides which Help module to use dependent on the application module, and that this code is unable to cope with the com.sun.star.sdb.FormDesign module.
Created attachment 56212 [details] document to reproduce the bug case
not having any help in forms is Bad (TM), I'd say we should fix this for the next release => 3.1
set the environment variable HELP_DEBUG and then press Shift+F1 to inspect what happens: --> you've defined the context "swform" which is not known to the Help. So no help at all.
fs->ufi: so is this something which can be fixed in the help files (perhaps by adding something like a rule "swform is a sub context of sdatabase"?), or do we need to fix this (i.e. add this rule) programmatically?
fpe > fs: Historically, there was a context per application (swriter, scalc, schart, smath, simpress, sdraw, sbasic). This also determines how the help is structured. We cannot simply add new contexts without having to take a close look at the way the help contexts are assigned or the situation with sub-contexts and/or overlapping contexts gets messy. The very minimum is to let us know that there will be a new context before you create it. In this case I guess a change to main_transform can do the trick but it will be a hack ultimately folding the swform context back to sdatabase. What is the policy for creating new contexts in the applications?
> In this case I guess a change to main_transform can do the trick but it will be a hack ultimately folding the swform context back to sdatabase. Thinking about this, I am afraid, this won't do. For extended tips and context sensitivity to work, every context needs its own set of help files. It's a pseudo-application, so to speak. A similar situation exists for schart. So adding the swform context would require to identify all help files for that context and modify the makefiles to create the corresponding help files when the help is built. Why do we need an extra context for database forms? What are contexts used for? Reassigning to myself.
Technically, "swform" is the short name of the *module* "Database Forms implemented by Writer" (And, btw. there is also a module "Database reports implemented by Writer", short-named "swreport"; a module "XML Form Documents", short-named "swxform"; and a module "Database Reports implemented by the Sun Report Builder", short-named "dbreport" :-\). A module is the ensemble of all documents of the same type. All such documents share the same UI configuration (toolbars, menus, accelerators), unless of course overruled by the configuration stored in a particular document. More precise, if you want a class of documents to have a separate UI configuration (as is the case for database forms and database reports, even when they're technically Writer documents), then you *need* to create an own module for them. Having said all that, I am not sure whether or not the issue is properly assigned to you. I could imagine a solution in the code, right before the Help-URL is assembled. We could examine the help context, and in case of "swform", "swreport", and "dbreport", we could just use the help context "sdatabase". Altertnatively (and to judge this proposal, I cc AS here), I could imagine to extend the definition of a module: At the moment, this definition includes the mentioned short name, but there is not really (I think) a reason why this short name must also be used as a help context name. Perhaps we could separate those two aspects of a module.
>We could examine the help context, and in case of "swform", "swreport", and "dbreport", we could just use the help context "sdatabase". For now, this seems to be the way to go. Sending this to Peter.
pb: fixed in cws fwk98. Files changed: /sfx2/source/appl/sfxhelp.cxx 264035
pb -> tk: please verify. Thx.
Looks better now, verified along with issue 96418
Verified in master version dev 3.1
Fixed on OOo310m9, can be closed