US007827483B2
`
`(12) Ulllted States Patent
`Unbedacht et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,827,483 B2
`Nov. 2, 2010
`
`(54 REAL TIME PREVIEW
`
`(75
`
`iitibeidachotl, (grem,
`Inventors: gevin
`.
`oo war ,
`rem,
`ruce
`Eric D. Johnson, Lindon, UT (US)
`
`;
`
`(73 Assignee: Corel Corporation, Ottawa (CA)
`
`( *
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent ls extended Or adjusted under
`U.S.C. 154(b) by 1010 days.
`
`(21 Appl.No.: 10/752,048
`
`(22
`
`(65
`
`Filed:
`
`Jan. 6, 2004
`
`Prior Publication Data
`Us 2004/0139401 A1
`Jul. 15, 2004
`
`5,479,601 A *
`5,481,710 A *
`5,524,190 A
`5,528,742 A *
`
`........... .. 345/326
`12/1995 Matheny et al.
`.... .. 719/320
`1/1996 Keane et al.
`
`............ 395/146
`6/1996 Schaeffer etal.
`6/1996 Moore et al.
`.............. .. 715/205
`
`(Continued)
`
`EP
`
`0 656 580 A2 *
`
`6/1995
`
`............... .. 345/326
`
`OTHER PUBLICATIONS
`IBM Technical Disclosure, “Pause Preview: ATechnique for Improv-
`ing the Interactivity of Direct Manipulation,” vol. 34, Issue No. 7A,
`
`Related U.S. Application Data
`
`Dec: la 1991'*
`
`(63) Continuation of application No. 09/141,832, filed on
`Aug. 28, 1998, now Pat. No. 6,731,309.
`
`(Continued)
`.
`Primary Examiner—Tadeese Hailu
`
`(74) Attofney, Agent, or Firm—The Law Ofiice ofMichael E.
`Kondoudls
`
`(57)
`
`ABSTRACT
`
`t
`t
`Computer software applications presently allow the User to
`preview the impact of some commands on active documents
`via a small preview window. However, such preview windows
`are not representative of how the command will impact the
`entire document. The invention provides a method and sys-
`tem of effieiently and effectively previewing the impact of
`User eemmands en the entire deeument b exeeutin User
`.
`.
`.
`y
`g
`commands as they are identified. Leaving the menu open,.the
`Userisabletoidentifysuccessivecommandsuntilthedesired
`resultis reached. Embodiments are described for execution of
`general commands, text editing commands, relocations of
`margins or guidelines, and relocations of graphic objects.
`
`14 Claims, 6 Drawing Sheets
`
`(51)
`
`Int_ C1_
`(2006.01)
`G06F 3/048
`(52) U.S. Cl.
`..................... .. 715/256; 715/269; 715/255;
`715/221
`(58) Field of Classification Search ............... .. 715/243,
`715/256, 269, 254, 270, 221, 255
`See application file for Complete Search history.
`_
`References Clted
`U.S. PATENT DOCUMENTS
`
`(56)
`
`......... .. 715/529
`8/1984 Lawrence et al.
`4,464,730 A *
`4/1985 Maddock . . . . . . . . . . . .
`. . . .. 715/531
`4,513,391 A *
`4/1988 Barker et al..
`707/100
`4,739,477 A *
`6/1992 Kerr et a1.
`719/328
`5,121,497 A *
`.
`5,157,753 A * 10/1992 peters e131,
`345/340
`5,226,117 A
`7/1993 Miklos . . . . . . . .
`. . . .. 395/157
`5,243,697 A *
`9/ 1993 H0ebefet31~
`715/340
`5’287’443 A
`2/1994 Mafneda et 31' "
`395/146
`5,398,313 A *
`3/1995 Kojimaetal.
`717/2
`5,450,586 A *
`9/1995 Kuzara et al.
`..... ..
`717/4
`5,469,540 A
`11/1995 Powers, III et al.
`....... .. 395/158
`
`
`
`
`1
`9“\ E
`
` ms ussn
`
`emaazowe
`SELECTED oaiscn
`
`
`V55
`“\
` muw cum»: or ea/assesOBJECT IN NEW
`
`
`D1REc'n
`DNAL
`LOCAYION In RESPONSETo
`—>
`commmus, DELEYING oumuss IN ow LOCATIONS
`«:12
`D
`REMOVE cm 001):
`mom uacwam
`mssm NEW cons
`1
`11.
`\ INTO DOCUMENT
`ms
`1
`
`
`\ ovum Dcx:L.MEm
`msmvwmocw
`
`vss
`
`‘W
`
`HA5we use;
`P/mam
`up
`
`ms ms uszn
`
`emxaazn DBJECRELEASEDTHET‘!
`
`Mn
`
`PUSH NEW con
`E
`ONTO uN|>oSTACK
`
`1
`
`MS 1001
`
`MS 1001
`
`1
`
`

`
`US 7,827,483 B2
`Page 2
`
`2/2000 Finkelstein etal.
`6,025,841 A *
`5/2000 Ta
`.
`6061059 A *
`9/2000 G,Zif,f,§‘ei1,1.
`N
`6:118:444 A ,,
`715/866
`9/2000 Sells ............ ..
`6,124,855 A *
`.. 719/320
`6,167,455 A * 12/2000 Friedman eta1..
`N 707/531
`6,185,591 131*
`2/2001 Bakeret 31.
`.. 715/517
`6,324,554 131*
`11/2001 Watanabe etal.
`715/762
`6,480,206 132* 11/2002 Prinzing ....... ..
`.. 715/715
`.
`6,606,101 131*
`8/2003 Malamudetal.
`2005/0071786 A1*
`3/2005 Marianietal.
`............ .. 715/967
`
`
`
`....... .. 715/803
`..
`N
`
`OTHER PUBLICATIONS
`
`A .1b.1.
`An
`t.
`C
`.
`. Et
`Et
`F“‘1’)“‘1‘§eS1998Vf"’ “ty 9
`P: en?’
`353515Ad ErPI‘,’1r1a‘°“h
`9 '
`*
`.
`0” ”””‘? '
`F”
`° 9 “ °‘°? 91”’
`IBM Techmcal D1sc10sure, Outhne Format PreV1ew Vol. No. 25,
`.
`,p.
`0.
`,
`ay ,
`.
`ISSWNO 12
`N 6486 M 1 1983,,
`Adobe S0fiWm,PreSSRe1eaSe’ pubhshedmg. 26, 1998.
`
`f
`
`* cited by examiner
`
`U.S. PATENT DOCUMENTS
`5,546,527 A *
`8/1996 Fitzpatricketal.
`5,579,466 A * 11/1996 Habib et=11~
`5,586,242 A * 12/1996 McQueen et a1,
`5,598,522 A *
`I/1997 Inatomi
`....... ..
`5,604,853 A *
`2/1997 Nagashima ~
`5,638,504 A *
`6/1997 S006 et 31,
`~~
`5,652,901 A *
`7/1997 S1aydeneta1~
`5,668,964 A *
`9/1997 He1Se1eta1~
`5,680,629 A * 10/1997 Slayden etal.
`5,694,610 A * 12/1997 Habib etal.
`
`........ .. 345/348
`~715/210
`345/467
`715/821
`715/540
`~ 707/530
`~ 715/209
`~ 345/350
`.707/527
`.............. .. 345/347
`
`
`
`............ .. 395/352
`2/1998 Gardienetal.
`5,715,417 A
`6/1998 McGurrineta1.
`.
`. 715/841
`5,760,776 A *
`7/1998 Nakajimaetal.
`......... .. 345/157
`5,781,179 A *
`_
`9/1998 Van DeVanter
`.......... .. 717/107
`5,805,889 A *
`5,828,376 A * 10/1998 S011mene etal.
`.......... .. 715/821
`5,903,905 A *
`5/1999 Andersen etal.
`.......... .. 707/526
`5,990,906 A * 11/1999 Hudson et a1.
`........... .. 345/ 666
`
`2
`
`

`
`U.S. Patent
`
`Nov. 2, 2010
`
`Sheet 1 of6
`
`US 7,827,483 B2
`
`
`
`START
`
`FIGURE 1a
`
`
`
`
`
`
`HAS A COMMAND
`BEEN
`IDENTI Fl ED?
`
`EXECUTE SUBROUTINE CORRESPONDING TO
`IDENTIFIED COMMAND
`
`PUSH CODE CORRESPONDING TO V
`IDENTIFIED COMMAND ONTO UNDO STACK
`
`
`
`
`
`16
`
` UPDATE DOCUMENT
`'\ DISPLAY WINDOW
`
`
`
`
`
`
`NO
`
`UPDATE DOCUMENT
`DISPLAY WINDOW
`
`HAS A
`
`
`
`COMMAND BEEN
`ENTERED?
`
`5:g3:I:;::¢s“:::GIIEL
`STATE
`
`3
`
`

`
`U.S. Patent
`
`Nov. 2, 2010
`
`Sheet 2 of6
`
`US 7,827,483 B2
`
`FIGURE 1b
`
`24"\
`
`
`
`
`HAS A COMMAND
`BEEN
`IDENTIFIED?
`
`26 —\
`
`YES
`
`EXECUTE SUBROUTINE CORRESPONDING TO
`IDENTIFIED COMMAND INTO DOCUMENT
`
`28’\ UPDATE DOCUMENT
`
`DISPLAY WINDOW
`
`
`
`IDENTIFY A
`NEW
`
`COMMAND?
`
`
`36
`
`"\
`RETURN DOCUMENT
`TO ORIGINAL STATE
`
`
`
`NO
`
`NO
`
`
`CONFIRM
`COMMAND?
`
`
`
`
`
`UPDATE DOCUMENT
`DISPLAY WINDOW
`
`
`
`PUSH CODE CORRESPONDING
`TO IDENTIFIED COMMAND ONTO
`UNDO STACK
`
`4
`
`

`
`U.S. Patent
`
`Nov. 2, 2010
`
`Sheet 3 of6
`
`US 7,827,483 B2
`
`FIGURE 2
`
`NO
`
`ExEcuTE COMMAND
`NOR|\/|A|_[_Y
`
`40
`
`
`CURSOR HOVERING
`OVER A MENU OR
`TOOLBAR OPTION?
`
`
`
`
`
`
`
`
`IDENTIFIED OPTION
`
`REAL TIME PREVIEW
`ENABLED?
`
`YES
`
`YES
`
`46 ”\ 48—\
`
` IS A
`YES
`
`REMOVE MATCHING
`MATCHING CODE IN
`
`CODE
`THE DOCUMENT’?
`
`
`
`INSERT CODE CORRESPONDING TO
`IDENTIFIED OPTION INTO DOCUMENT
`
`52
`
`‘\ UPDATE DOCUMENT
`DISPLAY WINDOW
`
`HAS IDENTIFIED OPTION
`BEEN CONFIRMED?
`
`NO
`
`NO CLOSE MENU OR
`TOOLBAR OPTION
`
`
`
`
`
`56 j
`
`YES
`
`PUSH CODE CORRESPONDING
`TO IDENTIFIED OPTION ONTO
`UNDO STACK
`
`62 '\
`
`YES
`
`REMOVE CODE CORRESPONDING
`TO IDENTIFIED OPTION I-“ROM
`DOCUMENT
`
`
`
`58 :: RETURN MATCHING J
`
`\ °LOT3§O"f§§g OR <
`
`CODE TO DOCUMENT
`
`I
`
`64
`
`DONE
`
`66
`UPDATE DOCUMENT J
`DISPLAY WINDOW
`
`5
`
`

`
`U.S. Patent
`
`Nov. 2, 2010
`
`Sheet 4 of6
`
`US 7,827,483 B2
`
`- FIGURE 3a
`
`START
`
`68'\
`
`
`
`
`HAS USER GRABBED
`
`A MARGIN OR GUIDELINE
`IN A FIRST LOCATION?
`
`YES
`
`
`
`
`
`REMOVE CODE CORRESPONDING
`TO FIRST MARGIN OR GUIDELINE
`
`LOCATION FROM DOCUMENT
`
`YES
`
`DRAW OUTLINE OF MARGIN OR
`
`GUIDELINE IN NEW LOCATION AS MOUSE
`MOVES, DELETING ANY OLD OUTLINES
`
`
`
`
`
`
`UPDATE DOCUMENT
`DISPLAY WINDOW
`
`INSERT CODE CORRESPONDING TO
`SECOND MARGIN OR GUIDELINE
`LOCATION INTO DOCUMENT
`
` HAS THE USER
`RELEASED THE
`GUIDELINE?
`
`
`
`
`LOCATION ONTO UNDO STACK
`
`PUSH CODE CORRESPONDING TO
`MARGIN OR GUIDELINE IN SECOND
`
`DONE
`
`6
`
`

`
`U.S. Patent
`
`Nov. 2, 2010
`
`Sheet 5 of6
`
`US 7,827,483 B2
`
`FIGURE 3b
`
`START
`
`REMOVE CODE
`CORRESPONDING TO MARGIN
`OR GUIDELINE IN SECOND
`LOCATION, FROM DOCUMENT
`
`
`CI/I\‘,‘\lSC$I_5E%S%_'TE
`CHANGE?
`
`
`
`
`
` REMOVE CODE
`CORRESPONDING TO MARGIN
`
`OR GUIDELINE IN SECOND
`
`LOCATION, FROM UNDO STACK
`
`
`
`LOCATION, INTO DOCUMENT
`
`
`ADD CODE CORRESPONDING TO
`\ MARGIN OR GUIDELINE IN FIRST
`
` ¥ UPDATE DOCUMENT
`
`7
`
`

`
`U.S. Patent
`
`Nov. 2, 2010
`
`Sheet 6 of 6
`
`US 7,827,483 B2
`
`START
`
`FIGURE 4
`
`NO
`
`HAS USER
`SELECTED AN
`OBJECT?
`
`
`
`
`
`HAS USER
`GRABBED THE
`SELECTED OBJECT?
`
`
`
`
`
`
`98j
`
`YES
`
`DRAW OUTLINE OF GRABBED OBJECT IN NEW
`LOCATION IN RESPONSE TO DIRECTIONAL
`COMMANDS, DELETING OUTLINES IN OLD LOCATIONS
`
`
`
`102-\
`REMOVE OLD CODE
`FROM DOCUMENT
`
`HAS THE USER
`PAUSED?
`
`YES
`
`
`
`
`104
`
`\
`
`106
`\.
`
`INSERT NEW CODE
`INTO DOCUMENT
`
`UPDATE DOCUMENT
`DISPLAY WINDOW
`
` HAS THE USER
`RELEASED THE
`GRABBED OBJECT?
`
`YES
`
`II\0\
`
`PUSH NEW CODE
`ONTO UNDO STACK
`
`DONE
`
`8
`
`

`
`US 7,827,483 B2
`
`1
`REAL TIME PREVIEW
`
`CROSS REFERENCE TO RELATED
`APPLICATION
`
`This application is a Continuation of U.S. application Ser.
`No. 09/141,832, filedAug. 28, 1998 now U.S. Pat. No. 6,731,
`309.
`
`The present invention relates generally to the manner in
`which computer software applications execute User com-
`mands, and more specifically, to providing a preview of iden-
`tified User commands.
`
`BACKGROUND OF THE INVENTION
`
`Most computer software application programs require
`interaction with the User in which the User may select com-
`mands from a variety of options. In document and graphic
`editing programs, for example, command options are avail-
`able which alter the appearance of a User document. Gener-
`ally, the process of executing commands consists of a User
`scanning through a large list ofmenu or toolbar options, often
`in a multi-level hierarchy, to select and then execute a desired
`command. The execution of the selected command usually
`consists of striking a <Retum> key, an <Enter> key, clicking
`on an <Okay> icon, or responding positively to a query such
`as Confirm? (Y or N). The executed command then modifies
`the application document and closes the menu, and the User
`can see the impact ofthe command on the active document. If
`the User is not happy with the result, the menu options must
`be scanned again, and another command selected and
`executed. This process is slow and requires multiple key-
`strokes by the User, and may have to be repeated several times
`before the User obtains the desired result.
`
`The same problems arise in text editing programs, graphic
`editing programs, and in software in general.
`To expedite the process of command selection, there are a
`number of methods of previewing how a proposed change
`will impact a document. A technique common to text editing
`programs, is to provide a small dialogue window in a What
`you-see-is-what-you-get (WYSIWYG) format. These win-
`dows provide the User with a small sample ofhow the change
`will impact the text in the document, and are commonly used,
`for example, for font face and size. There are two common
`implementations which are set out herein.
`The first implementation is to execute the format code on a
`generic text listing, for example, the uppercase and lowercase
`letters of the alphabet, or a string such as “The quick brown
`fox jumps over the lazy dog.” Although such an implementa-
`tion presents text in the format being considered, it may not
`show the impact on the particular characters the User is using.
`As well, because the preview window only presents a small
`sample, there is no indication ofhow the change might impact
`an entire document.
`
`The second implementation is to execute the format code
`on the first 20 or so characters of the selected text being
`modified. In this case, the text being modified comes from the
`User’s actual text, so the preview window does provide the
`User with more information on how the change will affect the
`active document, but again, it is just a small sample. In the
`example of a font change, there is no indication of how the
`layout of the text in the document may be changed. Unex-
`pected changes may occur such as text wrapping unexpect-
`edly, or a graphic being pushed to an unwanted location in the
`active document. The User only finds out how the document
`is changed by executing the command, then closing the menu
`window and studying the document.
`
`2
`There are also a number of commands in text editors for
`
`which no preview is given at all. With preview limited to a
`small sample window, there is no point in providing the User
`with a preview of guideline or margin changes, for example.
`There is a need for such a preview as a User may wish to adjust
`the tab guidelines in a table so that the columns appear bal-
`anced, or change the margins so that the document does not
`exceed a certain number of pages.
`Generally margins and guidelines are modified by the User
`grabbing them with a cursor, that is, by positioning a cursor
`over the margin or guideline and holding a mouse click button
`down, then relocating the margin or guideline to a new loca-
`tion and releasing the click button on the mouse. While the
`line is being relocated, an outline or shadow of the line
`appears in the document window, but the document itself is
`not updated until the mouse click is released, so there is no
`way to determine the impact on the document until the click
`is released.
`
`Graphic editing programs are commonly used to prepare
`brochures,
`tables, schedules, flow charts, schematic dia-
`grams, and many other such documents. Again, text preview
`windows are only appropriate for changes to the font size and
`type, so no preview is available for most other commands.
`Some graphic editing programs provide the User with out-
`lines or shadows ofgraphic figures as they are being moved or
`modified, but such outlines do not reflect the actual change to
`the document. The User must execute the change to see the
`complete impact.
`Commands may be selected from toolbar menus, toolbar
`combo-boxes, toolbar grid-pickers and dialogue boxes, using
`a mouse, trackball, directional arrows, ALT keys or Function
`keys. As noted above, execution may be affected by striking a
`<Retum> key, an <Enter> key, clicking on an <Okay> icon,
`or responding positively to a query such as Confirm? (Y or N).
`There is therefore a need for a method of allowing a User to
`preview the impact of commands on an active document, or in
`general, to execute commands in an efiicient and effective
`manner.
`
`SUMMARY OF THE INVENTION
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`It is therefore an object ofthe invention to provide a method
`and system of efiiciently and effectively previewing User
`commands. The method executes User commands on the
`
`45
`
`active document as they are identified, providing the User
`with the actual impact of the command on the entire docu-
`ment in real time.
`
`50
`
`55
`
`60
`
`65
`
`Accordingly, an aspect of the invention is broadly defined
`as a method of providing real time preview of commands in a
`computer system having means for displaying commands on
`a display screen, comprising the step of responding to one of
`the commands being identified by executing computer code
`corresponding to the identified command.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`These and other features ofthe invention will become more
`apparent from the following description in which reference is
`made to the appended drawings in which:
`FIG. 1a presents a flow chart of a computer software rou-
`tine for performing real time preview of commands in an
`embodiment of the invention, with a cancellation option;
`FIG. 1b presents a flow chart of a computer software rou-
`tine for performing real time preview of commands in an
`embodiment of the invention, with a confirmation option;
`
`9
`
`

`
`US 7,827,483 B2
`
`3
`FIG. 2 presents a flow chart of a computer software routine
`for performing real time preview oftext document commands
`in an embodiment of the invention;
`FIG. 3a presents a flow chart of a computer software rou-
`tine for performing real time preview of margin or guideline
`commands in an embodiment of the invention; and
`FIG. 3b presents a flow chart of a computer software rou-
`tine for cancelling previewed margin or guideline commands
`in an embodiment of the invention; and
`FIG. 4 presents a flow chart of a computer software routine
`for performing real time preview of object movements in an
`embodiment of the invention.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS OF THE INVENTION
`
`The invention is broadly defined as a method of providing
`real time preview of commands in a con1puter system having
`means for displaying commands on a display screen, com-
`prising the step of responding to one of the commands being
`identified by executing computer code corresponding to the
`identified command. The primary distinction between this
`method and that ofthe prior art is that commands need only be
`identified by the User, and the identified command will be
`executed on the active document and the menu left open.
`Generally in the prior art, a command must be selected and
`then executed by the User, before the menu will be closed and
`the document will be updated.
`Because the invention executes the identified command on
`the entire active document when it is identified, the User is
`able to see the full impact of the command on the document.
`Because the menu has been left open, the User has the option
`of selecting a new command which will replace the identified
`command, confirming that the identified command is desired,
`or cancelling the identified command.
`Whether the menu should be left open or not depends on
`the nature of the command being issued. When selecting a
`font face for example, it is probably desirable to leave the
`menu open, while in executing a file save command, it prob-
`ably is not desirable. Such a decision may be left to the
`programmer, who may allow the User the option in a Prefer-
`ence selection. Implementation of such options would be well
`known to one skilled ir1 the art.
`
`The software subroutines required to perform the method
`of the invention do not vary greatly from those subroutines
`known in the art. The order in which those subroutines are
`
`executed is important to the invention.
`Such methods will now be described with respect to the
`general application and then with respect to several preferred
`embodiments. As well, additional options and advantageous
`implementations will also be described.
`FIG. 1a presents a flow chart of a computer software rou-
`tine for performing real time preview of commands in an
`embodiment ofthe invention, with a cancellation option. This
`routine is generally being run as part of a larger application
`program, and is integrated into that application program. The
`details necessary to implement the invention in different oper-
`ating system environments, requiring such steps as polling or
`accepting interrupt
`requests
`from a keyboard are not
`described herein. Such details would be known by one skilled
`in the art.
`
`At step 10 the software application program notes that a
`menu or toolbar option has been identified. As described
`above, available commands may be presented and selected
`from menus and toolbars which may be set up as pull down
`menus, dropdown controls, toolbar combo-boxes, toolbar
`
`4
`
`grid-pickers and dialogue boxes. Other implementations
`would also be known to one skilled in the art.
`
`These commands may be identified by the User in a num-
`ber of manners, including use of a mouse and cursor, track-
`ball, character keys,
`identifying the location of a cursor,
`mouse, arrow keys, ALT+character commands, space bar
`location, voice commands, function keys or direction arrows
`on a keyboard. The identified command may be emphasized
`using reverse video or a colour which contrasts the back-
`ground and other commands. Such implementations and the
`software routines used to handle User inputs would be known
`to one skilled in the art.
`
`In an embodiment ofthe invention, it is envisioned that real
`time preview of a command be optional, so the identified
`menu or toolbar option must be enabled by the User to allow
`real time preview. This can be done in a number of ways,
`appropriate to the application or the programmer’s prefer-
`ence. Preferably, commands for which real time preview is to
`be made available, will be selectable, either individually or in
`groups, within a User’s preference window. This would give
`the User the option of disabling the real time preview feature
`if desired, and also to change the length of time required to
`execute certain options of the real time preview invention.
`More details are given regarding the timeout options in the
`following text.
`Once a command has been identified, the application pro-
`gram executes the command at step 12. The manner in which
`this execution is realized would depend on the nature of the
`command and the application program, and would be known
`to one skilled in the art. In a word processor, for example, this
`execution would generally comprise inserting a code corre-
`sponding to the identified option into the memory medium
`storing the active document. In the case of a file save com-
`mand, common to many software applications, this would
`comprise executing the appropriate software subroutine to
`effect storage of the active file.
`After the identified command has been executed, it would
`generally be saved in an Undo Stack at step 14 so that the
`change can be undone if necessary.
`then updated or
`The document display window is
`refreshed, at step 16, if changes have been made to the win-
`dow and if updating is necessary. Sor11e programs may auto-
`matically update the window when new code is added to it in
`which case updating does not appear as a discrete step in the
`program. Other programs may not require refreshing, if the
`change in command code does not cause the window to be
`cluttered with impertinent or spurious data. Some real time
`preview commands may not change the appearance of an
`open document, so of course, they would not require the
`display window to be updated either. Again, an example of
`this would be a file save command.
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`FIG. 1a has included an optional cancellation feature at
`step 18. At this point, the command has been executed, and
`the User has been advised of the result of the command
`
`60
`
`65
`
`execution. If the User wishes to cancel the command, it may
`be cancelled at this point by entering the appropriate instruc-
`tion. Several commonly used cancellation commands are the
`<Escape>, <Backspace> or <Delete> keys. Clearly any key
`could be used, though it is best to be consistent with common
`conventions.
`
`If the User selects the cancellation command, the docu-
`ment and Undo Stack are returned to their original state at step
`20, and the document window refreshed at step 22. The iden-
`tified and executed command is simply removed from the
`Undo Stack and used to direct the program as to how the
`
`10
`
`10
`
`

`
`5
`document is to be modified to return the document to its
`
`original state. Software routines to effect such operations are
`well known in the art.
`
`6
`menu open. In this way the commands can be executed much
`more quickly and with fewer keystrokes than the methods
`known in the art.
`
`US 7,827,483 B2
`
`With regard to step 22, as described above, the window
`may not require refreshing. Whether such a command is
`issued or not will depend on the implementation.
`FIG. lb presents a flow chart of a computer software rou-
`tine for performing real time preview of commands in an
`embodiment of the invention, with a “confirmation” option,
`rather than the “cancellation” option described with respect to
`steps 18, 20 and 22 of FIG. la. Either method may be used,
`though as described following, some applications are better
`suited to one or other of these two options. As well, FIG. lb
`demonstrates in general terms how new commands may be
`identified and their impact viewed by the User without having
`to close and re-open the menu window.
`In FIG. la it was noted that because the menu has been left
`
`open, the User has the option of either selecting a new com-
`mand which will replace the current command, or cancelling
`the current command. In the embodiment of FIG. lb, the User
`has the option of either selecting a new command or confirm-
`ing the acceptability of the existing command.
`The function blocks of the FIG. lb method are very similar
`to those ofFIG. la. Initially, a command is be identified by the
`User, as per step 24. This is done in the same manner as
`described with respect to step 10 above. Once the command is
`identified,
`the corresponding application subroutine is
`executed at step 26 and may introduce corresponding code to
`the active document. This step is done iii the same manner as
`step 12 of FIG. la.
`At this point, the method changes slightly from FIG. la.
`Because this routine requires a command to be confirmed, it
`does not presuppose that the identified command was desired
`as in FIG. la. Therefore, the document display window is
`updated at step 28, but preferably the corresponding code will
`not be pushed onto the Undo Stack until step 30, at which
`point the User has confirmed that this is the desired command.
`Alternatively, the command code could be pushed onto the
`Undo Stack immediately following step 28. This would result
`in the Undo Stack containing unconfirmed commands which
`is generally not desirable. However, a User may prefer such
`an option, and it could be made available via a preferences
`selection.
`If the User identifies a new command from the same menu
`
`window before confirming the previous command, at step 32,
`it may be executed in the same loop as steps 26 and 28. In
`some cases, further functionality will be required to remove
`existing code from the active document ifit contains contrast-
`ing or contradicting information. Such codes are described as
`matching codes and will be described in greater detail with
`respect to the preferred embodiments.
`Repeating this identification process and updating the
`document will allow the User to put the active document into
`the form desired and then confirm that the executed command
`
`is desired at step 34. Confirming the identified command
`allows it to be pushed onto the Undo Stack at step 30 and the
`routine is complete.
`If the User is not satisfied with the impact of the identified
`command, the command is not confirmed at step 34, causing
`the document to be returned to the original state by executing
`an Undo operation at step 36, and updating the document
`display window at step 38. Such steps are well known in the
`art. At this point the routine is complete.
`Either of the methods described with respect to FIG. la or
`lb enable the User to see the complete impact of any com-
`mands on the active document, while leaving the current
`
`Either ofthese methods may be easily implemented by one
`skilled in the art, because generally speaking, no new soft-
`ware routines are required. The method of the invention con-
`sists generally of the same routines as known in the art, but
`executed in a different order. The task of implementing the
`invention is therefore one of re-arranging existing routines to
`execute in the new order, and verifying and modifying if
`necessary the routines to maintain the coordination of vari-
`able declarations, assignments and calls.
`This method may be applied to a large variety of imple-
`mentations. Examples described below include text editors,
`margin or guidelines, and graphic editors. It would be clear to
`one skilled in the art however, how to apply the invention to
`other software applications, such as spreadsheets and data-
`base management programs.
`The invention will now be described with respect to a text
`editor which may be incorporated into a word processing
`package, graphic editor, spreadsheet or other such software
`application.
`Generally speaking, such a routine may be implemented on
`a computer system having means for operating a document
`editing program and means for storing an active document in
`a memory medium. Such an application may also generally
`have a means for displaying menu options in a menu or
`toolbar option list. The method itself comprises responding to
`one of the menu options in the menu or toolbar option list
`being identified by inserting code corresponding to the iden-
`tified menu option into the memory medium storing the active
`document.
`
`This is in contrast to the method of the prior art described
`above,
`in which commands must first be selected,
`then
`executed, at which time the menu is closed and the document
`updated. The invention therefore requires less time and fewer
`keystrokes to be entered by the User to see the resulting
`change on the active document.
`FIG. 2 presents a flowchart of a computer software routine
`for perfonning such a real time preview of text editing com-
`mands in an embodiment of the invention. This method can
`
`typically be incorporated into a standard text editing applica-
`tion program, by altering the order of the existing software
`subroutines.
`
`At step 40, a command is identified by a cursor hovering
`over a menu or toolbar option. As described above, com-
`mands may be presented by the application program in a
`number of manners including pull down menus and dialogue
`boxes. The User may select from the menus using a mouse,
`trackball, etc. Cursors are commonly controlled with mouses
`and software drivers incorporated into operating systems.
`Some software programs identify commands by inverting the
`video. The cursor being positioned above a command is gen-
`erally described as hovering, and is used to identify com-
`mands.
`
`Preferably, the identification of the command can be con-
`tingent upon the cursor hovering over the command for a
`predetermined period of time. This would allow the User to
`scan through a list of commands without each successive
`command being identified, and hence executed. The length of
`time required for this timeout could be established by the User
`in the Preferences of the Operating System, or in the Prefer-
`ences of the particular application program. A single timeout
`could be used, or groups of commands could have different
`timeouts assigned by the User.
`Until the User identifies a command, the routine remains at
`step 40. The flow chart is shown in this manner for simplifi-
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`11
`
`11
`
`

`
`US 7,827,483 B2
`
`7
`cation. One skilled in the art would be aware of the necessary
`interrupts, operating system calls or polling required to
`implement such a step.
`Once a command has been identified, the software routine
`corresponding to the identified command is executed, and it
`checks whether the identified command is enabled for the real
`
`time preview at step 42. A straightforward implementation of
`such a feature would be to control operability of the real time
`preview in the Users Preferences, either in the application
`program or operating system preferences. These Preferences
`would then set a global boolean flag as to whether real time
`preview is enabled or not, and each related command subrou-
`tine would check whether the flag is set or not. Ifthe flag is not
`set to enable the real time preview for the identified com-
`mand, then the program would continue to execute the com-
`mand in the normal manner, shown as step 44 in FIG. 2.
`Of course, the invention does require that such an enable-
`ment check be performed, and there are also many other ways
`in which such an enablement check could be implemented.
`The given implementation has the advantage of being easily
`implemented. It only requires a single additional line of code
`to the execution subroutine of each of the pertinent com-
`mands.
`
`If the identified command is enabled for real time preview,
`the execution continues with step 46, which investigates
`whether there is a matching code already in the User docu-
`ment. A matching code is typically one which effects the same
`text block and in the same manner as the identified command,
`but yields a different appearance. Different font sizes, for
`example, would yield matching codes. If a selected block of
`text has a font size of 10, and the identified command is to
`change the font size of the same block of text to font size 12,
`then the routine will find the font size 10 matching codes,
`remove them at step 48 and insert the code for the font size 12
`into the document at step 50.
`If no matching code exists, the program continues directly
`to insert the code corresponding to the identified command at
`step 50. In general, commands which do not directly impact
`the appearance of a document will not have codes stored with
`a document, so no such matching codes will exist. File man-
`agement commands such as Save, Open and Close are
`examples of such commands.
`Also, application programs do not generally have a discrete
`mapping between commands and code to be inserted into the
`document. Rather a command will invoke a software subrou-
`
`tine that performs numerous tests and checks, and may ulti-
`mately result in code being added to the active document. "he
`operation of such subroutines themselves is not the subject of
`this invention and are not included herein for simplicity. "he
`implementation of such routine would be well known to one
`skilled in the art.
`It is not the intent of the invention to alter how codes are
`
`stored in a document. The invention may be implemented in
`existing application programs by using the existing subrou-
`tines to insert code, identify matching codes and replace
`them. Such programs ma