sarahr at genesearch.com.au
Tue Dec 18 17:05:01 EST 2001
I haven't tried this in Rev but I did a similar thing in HyperCard. There is
probably an easier way to do this in Rev and I think your scrolling group
sounds like a good method, but here is what I learnt along the way:
First find out (by trial & error) how many pixels fit on a page. I ended up
with a stack size of 480 x 680 which fit comfortably on an A4 page. This
meant that once we all upgraded from 640 x 480 monitors, the scrolling
routines weren't necessary any more, but you may want more pixels or better
Then I used the following scripts:
-- The one sets the size of the window to fit in the screen,
-- allowing for the menubar
-- and hides the scroll window that HC automatically pops up
-- if the card is bigger than the window
put item 4 of the screenRect into maxHeight
set the height of the card window to maxHeight - 48
set the left of the card window to 8
hide window "Scroll"
-- This one checks where the mouse is. If it is at the bottom of the
-- "page", the window scrolls to the top and if the mouse is above,
-- it scrolls down to the bottom.
-- There is a 50 pixel buffer to stop constant flickering up & down
hide window "Scroll" -- just in case it re-appears
if item 2 of the mouseLoc > (the height of the card window - 50) then
set the scroll of the card window to the bottomRight of the card window
else if item 2 of the mouseLoc < (680 - the height of the card window +
set the scroll of the card window to 0,0
I know that the use of idle is not recommended in Rev but these are
HyperCard scripts so there was no alternative.
When the page was ready, I hid a few unwanted buttons and used "Print Card"
to get the whole thing on a single page. It worked really well. The card did
not have to be completely visible in the window for it all to print.
Hope this gives you some ideas.
> Hi. I would like to implement a word-processing-like interface for one of my
> stacks. Since a printable page is bigger than most monitors, I have been
> looking for a way to scroll an entire card or at least give the illusion of
> doing so to mimic the standard word processing interface. Simply putting the
> text in a scrollable field is not an option because the documents have a
> header and pages are divided into two columns (the text must be stored in
> multiple fields). Moveover, when the user is done editing the document, he
> should be able to print it. The two options I have considered are: (1)
> Putting the fields into a scrollable group. This seems as though it should
> work well except when printing. Is there a way to print the entire area of a
> scrollable group in one shot, as opposed to just the currently visible area?
> I also considered (2) Scripting a scroll bar to control the location of all
> fields in the card to give the illusion of a scrolling document. When
> printing, the scrollbar could be hidden and the card size could be expanded
> to contain all the fields (expanded to the former "scrollable" area), and
> the entire document would then in theory be printed. My questions are: 1) Is
> there a way to make method (1) work with printing, as I think this would be
> bar far the easier route to take, and if not 2) Does method (2) sound like a
> viable alternative? Anybody have a better idea? Thanks in advance for any
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the Use-livecode