Issue 25684 - position the FmFormShell dynamicall on the SfxDispatcher's stack
Summary: position the FmFormShell dynamicall on the SfxDispatcher's stack
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: 680m26
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0
Assignee: groucho266
QA Contact: issues@graphics
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2004-02-19 13:55 UTC by Frank Schönheit
Modified: 2008-05-16 03:33 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
exemplary patch for SW (5.99 KB, patch)
2004-02-19 13:58 UTC, Frank Schönheit
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2004-02-19 13:55:55 UTC
In the course of issue 24387, there is the need for the FmFormShell to be
responsible for certain slots, such as "Bold" etc.

Normally, your application handles these slots themself, however, in the
following situations, it needs to be handled by the form shell:
- if the focus is in a form control,
- if the focus is *outside the document*, but the last document element which
had the
  focus was a form controls

The first requirement is obvious, the latter results from the following user
behaviour:
- focus a form control
- use the keyboard to travel to, say, the toolbar
- chose the "Bold" icon therein
=> should apply to the form control, *not* to the document

As a result, the following needs to be implemented in your application:
- if a form control is focused, the FmFormShell has to be put on the top of the
SfxDispatcher stack
- if a form control loses the focus, nothing should happen
- if the main document window gets the focus, the FmFormShell should be
  placed *below* all other special shells of the application.

There's an exemplarily implementation for this for the Writer application - I am
going to attach the patch. The basic idea is that
- the form shell offers setting a handler for control activation - every time
it's called,
  the application needs to ensure that the FmFormShell is on the top of the stack
- the main document window passes the GetFocus event to some instance, which
  can decide whether the dispatcher stack needs to b rebuilt, so that the
FmFormShell
  is not on the top anymore


If possible at all, the implementations should please happen in the CWS
frmcontrols03, which is currently being resynced to SRC680m26. I'll add a note
to this issue when the resync is done.

Thanks in advance :)
Comment 1 Frank Schönheit 2004-02-19 13:58:52 UTC
Created attachment 13289 [details]
exemplary patch for SW
Comment 2 Frank Schönheit 2004-02-25 16:15:29 UTC
frmcontrols03 has been resynced to SRC680m26, and rebuilt completely.
Comment 3 Frank Schönheit 2004-03-02 13:01:51 UTC
oops - wrong owner
Comment 4 groucho266 2004-03-02 15:12:07 UTC
Accepted.
Comment 5 groucho266 2004-03-05 17:51:52 UTC
The new class FormShellManager (located in sd/source/ui/{inc,view}) registers as
listener both at the application window and the form shell.  When the former is
focused it moves the form shell to the bottom of the stack by calling the new
ObjectBarManager::MoveToBottom() method.  Otherwise, when the focus shell
notifies its activation the ObjectBarManager::MoveToTop() method is called to
move the form shell to the top of the stacked shells and take prcedence over the
others in answering slot calls.

An FormShellManager object is created by the DrawViewShell class, the only class
in SD that creates FmFormShell objects.   I am not sure whether this is the best
place.   May change when integrating this fix to CWS impress2.
Comment 6 Frank Schönheit 2004-04-06 13:51:35 UTC
works in CWS frmcontrols03
Comment 7 ace_dent 2008-05-16 03:33:41 UTC
This Issue is 'Verified' and not updated in 1yr+, so Closing.
A Closed Issue is a Happy Issue (TM).

Regards,
Andrew
 
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~