[ wxwindows-Bugs-1344868 ] OnSize event resets wxHtmlWindow's scroll position

[SourceForge.net]

Bugs item #1344868, was opened at 2005-11-01 13:31
Message generated for change (Comment added) made by neis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1344868&group_id=9863

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTML
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Julien Enche (trapamoosch)
Assigned to: Nobody/Anonymous (nobody)
Summary: OnSize event resets wxHtmlWindow's scroll position

Initial Comment:
Hi everybody,

I use a wxHtmlWindow in one of my app and I've seen a
strange behavior. 
For example, I create some html content and show it in
a html window.
I reduce the size of the window until scrollbars appear
and scroll the window with them.
If I change the size of the window, the scroll position
comes back to its initial state which is, I think, an
unwanted behavior.

This can be prevented by modifying
wxHtmlWindow::CreateLayout function like shown in the
joined file.

Anyway, doing this also prevents wxHtmlWindow to come
back to its initial state when calling SetPage/LoadPage
functions.

----------------------------------------------------------------------

>Comment By: Stefan Neis (neis)
Date: 2008-03-17 18:18

Message:
Logged In: YES 
user_id=32202
Originator: NO

> the same scrolled position is *not* the same location in the 
> document anymore. A real fix would be to restore "logical" 
> position in the layout.
> That is not as simple, but patches would be welcome.

Just a spontanuous idea, but if you care for an easy hack, positioning to
  new_scroll_pos = ((double)old_scroll_pos / old_height)*new_height;
should (IMHO) give reasonable results while still being quite simple. At
the very least, I'd expect it to give a good starting point for searching
for the correct logical position.

Unfortunately, I'm too busy otherwise (and don't currently have a need for
a solution to that cosmetic problem, sorry) to actually try out this idea
and submit a patch if it works reasonably ...

----------------------------------------------------------------------

Comment By: Vaclav Slavik (vaclavslavik)
Date: 2008-03-10 08:03

Message:
Logged In: YES 
user_id=80834
Originator: NO

Please read this on how to submit patches:
http://www.wxwidgets.org/docs/technote/patches.htm

Having said that, this change is not helpful. If the size of a window
changes, it invalidates scroll position: the same scrolled position is
*not* the same location in the document anymore. A real fix would be to
restore "logical" position in the layout (e.g. what is the topmost
wxHtmlCell leaf) on size change. That is not as simple, but patches would
be welcome.

> would be nice during resizes - perhaps set sizers 

Look at the code -- it doesn't use sizers (unsurprisingly, because it
doesn't use controls for HTML content, either).

----------------------------------------------------------------------

Comment By: Jeff Tupper (jtupper)
Date: 2008-03-09 22:30

Message:
Logged In: YES 
user_id=1639384
Originator: NO

This seems like a step in the right direction. I've also noticed this
problem. A more sophisticated notion of what the wxHtmlWindow is showing
would be nice during resizes - perhaps set sizers in an attempt to keep the
same word on the top line? (Rather than simply reset to the very top as
wxHtmlWindow currently seems to do.)

----------------------------------------------------------------------

Comment By: Joao Luís Marques Pinto (jpinto)
Date: 2005-11-20 18:15

Message:
Logged In: YES 
user_id=21121

I have submited the bug report #1362245 which maybe related
to this.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1344868&group_id=9863