OOPS,
looks like we really forgot this one.

@Frank: Would be nice for the accessibility project.
Peter

.

Shortcut is already present: Ctrl+Page Up/Down
Page up and down are needed for "scrolling" the doc, if the zoom 
level is higher.

Hi,

Frank is right. I have to close it as works for me.

best regards, Peter

WFM -> Closed

Hi,  
  
Great, Thanks !  
It really works as you describe with CNTRL-PageUP/Down !  
  
But nevertheless, I would like to reopen this bug, since I think this is not  
a very intuitive behaviour.  
As a user you expect KSpread to show the next page if you press PageDown.  
If I'm on a high zoom-level and see the first half of a page, everyone normally  
press the PageDown key to see the second half. That works great, but why shouldn't I  
press the PageDown key again to display the upper part of the following page.  
Instead I now have to press Control-PageDown ?!?  Why ? A normal user would  
never think about pressing Control-PageDown.  
  
Just my thoughts....  
  
Regards,  
Helge  

Sorry, of course I meant OpenOffice.org Calc, not KSpread. 

@Frank: I find Helge's suggestion quite good. The behaviour should
IMHO be:
PgUp/PgDn -> Scroll continiously through the preview
Ctrl + PgUp/PgDn -> Scroll to top of next/previous page
I guess that's also the way nearly anybody else does it. ;-)

I lowered Priority and target a little bit because the function works
in general.

Best regards, Peter

I suggest that Matthias should take a look a this. 
FL->MMP: Please decide if this sounds reasonable, because if we 
would do this as suggested by Helge, we have to change more than 
this single implementation.

started

Yes, Frank, what Helge suggested is not only reasonable, but also
intuitive and expected.

Roman

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

MMP>FL: Hi Frank,
from my point of view it is recommended to have the same set of
shortcuts in all print previews (Writer, Calc, etc.). Page up/down
should flip the pages, instead of just paning to the top and bottom of
a page in zoom mode -- as in Calc 1.1.  

FL->NN: Writer already switches pages (page sets) if the bottom of the current
page was already reached. Please change this for Calc in the same way. Page
Up/Down move the current visible document preview and if the page border is
reached/is already visible the page preview will be switched to the beginning of
the next page. (Please keep current Ctrl+Page Up/Down in addition)

according to the announcement on releases
(http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue
will be re-targeted to OOo Later.

even better if arrow keys work as well as pageup/pagedown.  i.e. arrowleft or
arrowup or pageup skips to previous page, and arrowright or arrowdown or
pagedown skips to next page.  also, home and end keys should skip to first and
last page respectively.

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

2.0 is released. Would it be possible to retarget the issue for earlier 
than "OOo later" and make Calc's scrolling behavior in Preview consistent with 
that of Writer (where PageUp/PageDn and mouse wheel scrolling work)?
Otherwise it is confusing to the user.
Thanks a lot.
WBR,
K. Palagin.

Created attachment 46628 [details]
7269.patch

Created attachment 46665 [details]
7269.patch

Ah, already wondered about the other modifications around the changed lines..
Yes, that approach seems to be viable. Did you verify in your build that it
works as intended?

Btw, some words on style:

In naming conventions, for pointers we use the prefix 'p', so instead of
SfxViewFrame* aSfxViewFrame
it should read
SfxViewFrame* pSfxViewFrame
The 'a' prefix is used for instances of objects.

For new code please use spaces (indenting to 4) instead of tabs. The old
aCurPos.Y() -= nVPage;
respectively
aCurPos.Y() += nVPage;
statements should be indented accordingly to properly align with the new if/else
code for readability.
For correct indenting please ensure that your editor displays tabs with an
indenting equivalent to 4 spaces for legacy code.

Thanks
  Eike

hi er!

  Yes,OK,I am sorry!

Because I am used to use "a" instead of the anything.
I will give up this bad habit.
Thanks for your suggestion.
I builded it in my work.and I will commit a new patch to OOo.

I hope you give me some suggestion.

Best wishes for you!

Tangquanfa

Created attachment 46684 [details]
7269.patch

Hi Tang,

The patch goes into the right direction and works for slightly zoomed-in
pages, but there are some issues with it:

1. If the page displayed fits into the preview area and no scrolling is
   possible, the PgUp/PgDn keys have no effect. In this case the
   previous/next page should be displayed.

2. If the page is zoomed-in, pressing PgUp at the top of the first page
   jumps to the bottom of that page. Similar, pressing PgDn at the
   bottom of the last page jumps to the top of that page. Instead, no
   action should be performed in both cases.

3. In a large zoom where the page is wider than the preview area, moving
   up with PgUp jumps to the bottom/right corner of the previous page
   when the page boundary is crossed. Similar, when the page is scrolled
   to the right, moving down with PgDn jumps to the top/left corner of
   the next page when the page boundary is crossed. In both cases the
   relative X offset should be kept, similar to how it is done if the
   Previous Page / Next Page buttons are clicked respectively
   Ctrl+PgUp/PgDn are pressed.

Thanks
  Eike

Created attachment 46714 [details]
7269.patch

hi er!

  Thank you very much for your advice!
  But I don't agree with the third case. Because when the user press down 
PgDn , the top/left 

corner content on the next page should be in sight of the user.So,when the user 
press down 

PgUp , the bottom/right  corner content on the previous page should be in sight 
of the user.I 

think.

I have been improved my code about the other case.

Please focus my latest patch.

I hope you give me some suggestion.

Best wishes for you!

Tangquanfa

@fl: Frank, could you please add your valuable 2 cents from the User
Experience's point of view what the user might expect when crossing the page
boundary in a zoomed-in view:

Should the horizontal position of the page been kept, thus paging vertically
through the document? Or should the view jump to the bottom-right respectively
top-left, depending on the direction the user is scrolling?

See point 3 of my comment #desc25 above.

Thanks
  Eike

FL->ER: I have discussed this with NN, TBE and FST today. We came to the
conclusion that the horizontal position must not be changed.

Created attachment 46740 [details]
7269.patch

It seems we should reconsider the target...

Great, this looks good and behaves correct.

Will have to find out whether this could still make it into OOo2.3 after feature
freeze. It's not a real feature, but a small enhancement and would require a
changes announcement anyway and as such usually counts for feature freeze.
Cc'ing 'mh' for this.

@Martin: any opinion? Do we want to pick this up for OOo2.3?

Thanks
  Eike

So what is the decision?

set target to next feature release 2.4.

I added one small change to make sure the pages of all sheets are counted, and
committed the patch on CWS "calc44" (for OOo 2.4).
Changed: prevwsh.cxx 1.37.62.1

tqfa, nn,
thank you very much!

Reassigning to QA for verification.

found fixed on cws calc44 using Solaris, Linux and Windows build

found integrated on master m239 using Linux, Solaris and Windows build

closed