Issue 93453

Summary: no context sensitive help at all in database forms
Product: Base Reporter: Frank Schönheit <frank.schoenheit>
Component: codeAssignee: Unknown <non-migrated>
Status: CLOSED FIXED QA Contact: issues@dba <issues>
Severity: Trivial    
Priority: P3 CC: andreas.schluens, frank.thomas.peters, issues, npolyudova
Version: OOO300m3Keywords: usability
Target Milestone: OOo 3.1   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
document to reproduce the bug case none

Description Frank Schönheit 2008-09-04 08:26:45 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.
Comment 1 Frank Schönheit 2008-09-04 08:27:23 UTC
Created attachment 56212 [details]
document to reproduce the bug case
Comment 2 Frank Schönheit 2008-09-04 08:28:10 UTC
not having any help in forms is Bad (TM), I'd say we should fix this for the
next release => 3.1
Comment 3 Uwe Fischer 2008-09-05 10:14:24 UTC
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.
Comment 4 Frank Schönheit 2008-09-05 10:25:03 UTC
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?
Comment 5 frank.thomas.peters 2008-09-05 14:05:05 UTC
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?

Comment 6 frank.thomas.peters 2008-09-05 15:22:02 UTC
> 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.
Comment 7 Frank Schönheit 2008-09-05 22:40:22 UTC
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. 
Comment 8 frank.thomas.peters 2008-09-08 10:34:59 UTC
>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.
Comment 9 pb 2008-11-20 10:35:47 UTC
pb: fixed in cws fwk98.
Files changed:
/sfx2/source/appl/sfxhelp.cxx 264035
Comment 10 pb 2008-12-14 18:32:13 UTC
pb -> tk: please verify. Thx.
Comment 11 joerg.skottke 2008-12-17 12:03:46 UTC
Looks better now, verified along with issue 96418
Comment 12 nadejda 2009-04-10 08:52:33 UTC
Verified in master version dev 3.1
Comment 13 natalia_hitekschool 2009-04-13 01:51:29 UTC
Fixed on OOo310m9, can be closed