Issue 63848

Just to start off: in issue 60519 I mentioned that dragging the Navigator and
Stylist windows in OOo, a file named "Views.xcu_tmp" in the "\Application
Data\OpenOffice.org2\user\registry\data\org\openoffice\Office\" folder is
created, opened, writen and read a many times per second (I noticed that with
Systernals' FileMonitor).
Moreover, while dragging these windows the CPU usage by OOo went to 80% or more,
and I could hear noticably the hard drive being accessed.

Now the redraw problem is easily solved by disabling the "Show window contents
while dragging" option in Windows. In that case though, the "Views.xcu_tmp" is
still being written while dragging, but at least I don't hear that rapid hard
drive access.

Moreover, someone (pl) wrote a fix to solve the redraw problem of issue 60519.
But nevertheless, even with his fix, if I enable the "Show window contents while
dragging" option in Windows the CPU shoots up again to 80% usage or more, with
the accompanying "scrunching" noise of the hard drive.

Of course I see no real use of the "Show window contents while dragging" option,
and I disable it without missing it a bit, and that solves my problem.

But in case the above problem is a symptom of a more serious problem that could
cause future trouble, I think this high CPU usage and hard drive noise is
something to look into.
I want to emphasize here that the "Views.xcu_tmp" file is written many times
whether the "Show... while dragging" is enabled or not, but that only when it is
enabled do the trouble mentionned above appear.

I hope I've been clear enough, and not too long in my description!

cd: We should think about to change the ViewsOption class in svtools to use the writer 
back feature of the configuration. This should solve the heavy disk use when moving a 
floating window.

*** Issue 72019 has been marked as a duplicate of this issue. ***

I'm not convinced that this is the solution. IMHO VCL should provide us with a
callback that dragging the window has come to an end. 

I think we should consider fixing this in 2.x time frame; it can be a PITA on
systems where the profile is located on a slow disk.

You're too confident in VCL's telepathic abilities then. We cannot know whether
a move event will be followed by another one or not ;-)

The idea is that we ignore all MouseMove events and only react on the
MouseButtonUp following the MouseMoves. Unfortunately IIRC we don't get
MouseButtonUp as it happens on the title bar. But VCL should be able to send a
"FinalMove" event.

That would work if there were any MouseMove events involved. But as long as the
stylist and friends are managed system windows, the only message there is is a
ConfigureEvent ("Your window has been moved" courtesy of the window manager).

Besides why this obessive writing of Views.xcu ? What was bad about writing it
when the stylist/navigator window gets closed/hidden ?

In this case you would move the window somewhere, open a new document window and
find the window at the old place. The fix for this issue was writing the
position to configuration when the window gets moved.

So are you sure that it is impossible to get or construct a "final move" event?
I wasn't aware that even VCL does not get any notification about mouse button up
or down events on the caption bar.

In this of course using asynchronous writing would be the only solution. 

The title bar belongs to the window manager. On Windows you get events there
(that's why you can e.g. drop files there), but that's only Windows.

Ah, the usual problem that we also had in case of double clicks on the title
bar. Seems that we will need to use the workaround with asynchronous writing of
ViewOptions.

Dear developers,
what is the current status of this issue? 
The problem affects not just Stylist, but Task and Slide panes in Impress, 
Pages pane in Draw, Navigator in Calc (and probably other panes) as well.

*** Issue 75745 has been marked as a duplicate of this issue. ***

*** Issue 75745 has been marked as a duplicate of this issue. ***

cd: Set target to OOo 2.3. We should find a solution for this problem soon.

Created attachment 44954 [details]
The declaration of Timer pointer and callback

Created attachment 44955 [details]
The initialization of Timer within ctor and the implementation of Timer callback function

liangweike,
thank you very much for your effort!
As far as I know you need to provide code via .diff file and file Join 
Copyright Agreement 
(http://website.openoffice.org/files/documents/28/1006/contributing.html).

WBR,
K. Palagin.

The locations of the two files:
sfx2/inc/dockwin.hxx 
sfx2/source/dialog/dockwin.cxx 

Created attachment 44961 [details]
The file contains the modification.

cd->kpalagin: We already have a JCA from liangwike (he is member of the
RedOffice team).

cd: Set Issue Type to "PATCH".

cd->liangweike: Thanks for your patch. I will add to CWS fwk66.

Added block of meta issue.

cd: Patch checked and accepted.

Thank you very much!

cd->tm: Please verify.

checked and verified in cws fwk66 -> OK !

Apparently the issue is not fixed (in 2.4m239 on WinXP) as dragging "Styles 
and Formatting" causes HDD light to be lit and CPU usage goes to 100%.

Reopening issue.
When testing it is important to make sure "Show window contents while 
dragging" is ON (default on WinXP), because if it is off then neither 
views.xcu is accessed, nor CPU is pegged.

Reset target.

the patch could not work, as it introduces a move timer but does not remove the
superfluous file accesses.

I've changed the patch and applied the same to SfxModelessDialog and
SfxFloatingWindow. So e.g. When moving the Search & Replace window across the
screen, number of file accesses go from ~3000 down to ~200.

When testing the patch, please test moving docked windows (dock within other
docked  windows, dock / undock) esp. on Unix platforms, as this was the piece of
code causing the high number of file accesses.

changed files:
framework/sfx2/inc/sfx2/basedlgs.hxx
framework/sfx2/source/dialog/basedlgs.cxx
framework/sfx2/source/dialog/dockwin.cxx

Created attachment 50587 [details]
diff for all changed files

cd->andreschnabel: Thanks for you patch. I checked it and you are right that we
missed modeless dialogs and resize operations. Fortunately code freeze is just a
week away and I can add your patch to a CWS targeted for OOo 2.4.

cd->of: Please verify.

@ tm: Please reverify in fwk82.

verified in CWS by using filemon on WinXP

,

*** Issue 62256 has been marked as a duplicate of this issue. ***

*** Issue 78902 has been marked as a duplicate of this issue. ***

closed ok in 2.4 and 3.0 releases