Patent Document

TECHNICAL FIELD 
   The system and methods described herein relate to extensible editors and, more particularly, the described implementations relate to selection services in an extensible editor. 
   BACKGROUND 
   The process of editing electronic documents generally consists of processing events and key combinations received by an editor. From events and key combinations, an editing space is created. The editing space consists of a document state plus a view state (visual feedback). The view state includes a selection state (what is selected, what is shown as feedback), scroll position, etc. The event interacts with the current state, and an editing model is applied to manipulate feedback or to manipulate the document based on the feedback. 
   Extensible editors typically provide a set of document manipulation services that can enable macros to perform advanced tasks on the content of a document. With an extensible editor, developers can couple extensions that define or re-define a manner in which the editor responds to events or key combinations and provides visual feedback to a user. For example, if a developer wishes to create a new look to a selection process or a highlighting process in an extensible editor, the developer can create an extension that receives input regarding cursor position, cursor movement, mouse actions etc. The developer can design the extension to use this input to create visual feedback that differs from a default selection service or highlight service of the editor. However, familiar behavior of the editor (such as clicking a “bold” button) is still retained by the editor. In addition, an extension can also expose virtually any kind of functionality through its own interfaces. 
   Extensible editors are designed so that one or more extensions can be coupled with the editor. This is accomplished by implementing a set of interfaces to which the extensions must conform. The interfaces are utilized by the extensions to access a host of basic functions so that the extensions themselves are not required to implement such basic functions. The extensions instead utilize the basic functions to perform tasks that supplement or override functions performed by the editor. 
   Extensible editors are desirable for their ability to include customer extensions to provide a rich editing experience. A significant part of an editing experience involves the selection model provided by the editor. A user may wish to develop a custom extension that includes a selection process that provides a unique look and feel to the user&#39;s editor, that provides selection feedback based on the selected data, and so on. 
   When utilizing extensions in an extensible editor, however, a conflict problem can arise if multiple extensions are used simultaneously that act upon the occurrence of the same event or key combination. If a first extension reacts to an event in one way, but a second extension receives the event after the first extension has acted on it, the second extension may also act on the event and, as a result, override the action of the first extension. This problem can occur even when using only one extension, if the extension acts on an event or key combination but does not prevent the (default) editor from subsequently acting on the same event. 
   SUMMARY 
   An extensible editor for editing electronic documents and/or content is described herein. The extensible editor provides a selection services component that allows extensions to interface with a selection model of the editor and provide a custom selection process to the editor. The editor can thereby implement the customer selection process without knowing details of how the selection process is implemented in the extension. The extensible editor (“editor”) includes three sets of interfaces for extension integration. 
   The first set of interfaces is part of a designer extensibility mechanism. The designer extensibility mechanism is used to couple an extension (also called a “designer”) to utilize the event routing model. The designer extensibility mechanism provides the ability to connect an editor extension that can modify editing behavior. An attached designer receives events and key combinations in a predefined order and uses the set of interfaces to create custom editing extensions. 
   The designer extensibility mechanism includes an edit designer interface that has four methods: translate accelerator, pre-handle event, post-handle event and post-event notify. The methods act as callback routines whenever an event occurs in the editing environment of the editor. When an event comes into the editor, the four methods intercept the event at different points of the editor&#39;s event handling process. The editor invokes the methods sequentially. If multiple designers are utilized, the editor invokes the current method on each designer sequentially, in the order in which the designers were registered with the editor. 
   If a designer acts on an event and wants to prevent any subsequent designer (or the editor) from acting on the event, the designer “consumes” the event by returning an appropriate signal to the editor. The designer returns a different signal when subsequent processing is to continue on an event. 
   If an event is a key combination (Ctr-A, Alt-P, etc.) it first passes through the “translate accelerator” method. This is done in the order that the designers were added to the editor. If a key combination is entered, then the designer acts upon the event and “consumes” the event so that subsequent designers or the default editor cannot subsequently act upon the event. 
   The post-editor event notify method is an exception to the rule that consumed events are not passed on to subsequent designers or the editor for further processing. This method is always called on all designers, regardless of whether, or when, an event is consumed. This allows each designer to clean up any internal states that may be anticipating an event that is consumed before reaching the designer. 
   The second set of interfaces is include in a selection services component of the editor. The selection services component provides designers with the ability to manage logical selections that are used by commands and other extensions, i.e., the ability to modify the logical selection state of the editor. As a result, all editing commands and services will be able to interact with a custom selection model without having detailed knowledge of the designer that is implementing the selection. 
   The third set of interfaces is included in a highlight rendering services component. The highlight rendering component allows a user to modify the rendered character attributes of text without modifying the document content. This facility is critical for providing a mechanism for providing user feedback without affecting persistence, undo, etc. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     A more complete understanding of exemplary methods and arrangements of the preset invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein: 
       FIG. 1  is an exemplary computer system on which the present invention may be implemented. 
       FIG. 2  is a block diagram of a computer having an extensible editor and several extensions coupled with the editor stored in memory. 
       FIG. 3  is a block diagram of an editor including a designer interface. 
       FIG. 4  is a block diagram of an event routing model utilized in an extensible editor. 
       FIG. 5  is a flow diagram of an event routing model for use in an extensible editor. 
       FIG. 6  is a blocked diagram of an editor including a selection services interface. 
       FIG. 7  is a block diagram of an editor including a highlighting services interface. 
   

   DETAILED DESCRIPTION 
   The invention is illustrated in the drawings as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, to be executed by a computing device, such as a personal computer or a hand-held computer or electronic device. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
   Exemplary Computer Environment 
   The various components and functionality described herein are implemented with a number of individual computers.  FIG. 1  shows components of typical example of such a computer, referred by to reference numeral  100 . The components shown in  FIG. 1  are only examples, and are not intended to suggest any limitation as to the scope of the functionality of the invention; the invention is not necessarily dependent on the features shown in  FIG. 1 . 
   Generally, various different general purpose or special purpose computing system configurations can be used. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention includes, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. 
   The functionality of the computers is embodied in many cases by computer-executable instructions, such as program modules, that are executed by the computers. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Tasks might also be performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media. 
   The instructions and/or program modules are stored at different times in the various computer-readable media that are either part of the computer or that can be read by the computer. Programs are typically distributed, for example, on floppy disks, CD-ROMs, DVD or some form of communication media such as a modulated signal. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer&#39;s primary electronic memory. The invention described herein includes these and other various types of computer-readable media when such media contain instructions programs, and/or modules for implementing the steps described below in conjunction with a microprocessor or other data processors. The invention also includes the computer itself when programmed according to the methods and techniques described below. 
   For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer. 
   With reference to  FIG. 1 , the components of computer  100  may include, but are not limited to, a processing unit  120 , a system memory  130 , and a system bus  121  that couples various system components including the system memory to the processing unit  120 . The system bus  121  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISAA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as the Mezzanine bus. 
   Computer  100  typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computer  100  and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. “Computer storage media” includes both volatile and nonvolatile, removable and nno-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer  110 . Combinations of any of the above should also be included within the scope of computer readable media. 
   The system memory  130  includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM)  131  and random access memory (RAM)  132 . A basic input/output system  133  (BIOS), containing the basic routines that help to transfer information between elements within computer  100 , such as during start-up, is typically stored in ROM  131 . RAM  132  typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit  120 . By way of example, and not limitation,  FIG. 1  illustrates operating system  134 , application programs  135 , other program modules  136 , and program data  137 . 
   The computer  100  may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,  FIG. 1  illustrates a hard disk drive  141  that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive  151  that reads from or writes to a removable, nonvolatile magnetic disk  152 , and an optical disk drive  155  that reads from or writes to a removable, nonvolatile optical disk  156  such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive  141  is typically connected to the system bus  121  through an non-removable memory interface such as interface  140 , and magnetic disk drive  151  and optical disk drive  155  are typically connected to the system bus  121  by a removable memory interface such as interface  150 . 
   The drives and their associated computer storage media discussed above and illustrated in  FIG. 1  provide storage of computer-readable instructions, data structures, program modules, and other data for computer  100 . In  FIG. 1 , for example, hard disk drive  141  is illustrated as storing operating system  144 , application programs  145 , other program modules  146 , and program data  147 . Note that these components can either be the same as ore different from operating system  134 , application programs  135 , other program modules  136 , and program data  137 . Operating system  144 , application program  145 , other program modules  146 , and program data  147  are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer  100  through input devices such as a keyboard  162  and pointing device  161 , commonly referred to as a mouse, trackball, or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit  120  through a user input interface  160  that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB). A monitor  191  or other type of display device is also connected to the system bus  121  via an interface, such as a video interface  190 . In addition to the monitor, computers may also include other peripheral output devices such as speakers  197  and printer  196 , which may be connected through an output peripheral interface  195 . 
   The computer may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer  180 . The remote computer  180  may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer  100 , although only a memory storage device  181  has been illustrated in  FIG. 1 . The logical connections depicted in  FIG. 1  include a local area network (LAN)  171  and a wide area network (WAN)  173 , but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. 
   When used in a LAN networking environment, the computer  100  is connected to the LAN  171  through a network interface or adapter  170 . When used in a WAN networking environment, the computer  100  typically includes a modem  172  or other means for establishing communications over the WAN  173 , such as the Internet. The modem  172  which may be internal or external, may be connected to the system bus  121  via the user input interface  160 , or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer  100 , or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,  FIG. 1  illustrates remote application programs  185  as residing on memory device  181 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. 
     FIG. 2  is a block diagram of a computer  200  having a processor  202  and memory  204 . An extensible editor  206  stored in the memory  204  includes an event routing controller  208 , a designer extensibility mechanism  210 , a selection services component  212 , and a highlight rendering services component  214 . Three designers  216 ,  218 ,  220  are also stored in the memory  204 . Each of the designers  216 - 220  communicates with the editor  206  via the designer extensibility mechanism  210 . Each designer  216 - 220 , as shown, also communicates with the selection services component  212  and the highlight rendering component  214 . It is noted, however, that a designer  216 - 220  may communicate with only the selection services component  212  or the highlight rendering component  214  or with neither. However, as will become clear in the following discussion, each designer  216 - 220  must attach to the editor  206  through the designer extensibility mechanism  210 . 
   A designer is an editor extension that is used to extend the functionality of the editor  206  and to customize the behavior of the editor  206 . While an “extension” is a generic term for a designer, the term “designer” is utilized in several products of the MICROSOFT CORP., such as INTERNET EXPLORER 5.5, MSHTML (the HTML parsing and rendering engine of INTERNET EXPLORER that displays a document with editable content), the WebBrowser (ActiveX) control, etc. For purposes of the present discussion, terms specific to one or more of such products will be used. For example, in the present discussion, editor extensions will be referred to as designers. A reference to such a specific term (e.g., designer) is intended to include reference to the more generic term (e.g., extension). 
   The designers  216 - 220  work by intercepting events and commands occurring in, or received by, the editor  206 . When one or more of the designers  216 - 220  intercepts an event (or command), the designer can change how the editor  206  handles the event. Generally, a designer is written to either supplement or override the editor&#39;s behavior. Several designers may be attached to the editor  206  at once, thereby dynamically enabling multiple levels of custom functionality. 
   Designers offer a very powerful tool for customizing the editor  206 . Virtually any part of the editor&#39;s behavior can be changed. For example, designers may be used to add spell checking capability to the editor  206 , to add table editing functionality, to add annotation or revision-tracking capability, and so on. It is noted that, although only three designers  216 - 220  are shown in conjunction with the editor  206 , any number of designers may be connected to the editor  206 . 
   The designer extensibility mechanism  210 , the selection services component  212 , and the highlight rendering services  214  of the editor  206  shown in  FIG. 2  provide specific functionality to the editor  206 . Each of the modules and the functionality it provides will be discussed separately, in detail, below. 
   Designer Extensibility Mechanism 
     FIG. 3  is a block diagram of an editor  300  similar to the editor  206  shown in  FIG. 2 . The editor  300  includes a default event handler  301 , an event routing controller  302  and a designer registry  303 . The editor also includes an edit designer interface  304  that has several methods through which one or more designers (not shown) communicate with the editor  300 . Each designer that is coupled with the editor  300  communicates with the editor  300  through the edit designer interface  304 . Any coupled designer may then communicate with any other interfaces that are a part of the editor  300 . 
   When a designer is added to the editor  300 , the designer is registered in the designer registry  303 . The event routing controller  302  accesses the designer registry  303  to determine the designers that are coupled to the editor  300 . As will be discussed in greater detail below, the event routing controller  302  utilizes the designer registry  303  when routing events to attached designers. 
   The methods of the edit designer interface  304  are a translate accelerator method  306  (TranslateAccelerator), a pre-handle event method  308  (PreHandleEvent), a post-handle event method  310  (PostHandleEvent), and a post-editor event notify method  312  (PostEditorEventNotify). Each method  306 - 312  has two parameters, an event identifier  314  and an event object interface  316 . In one implementation, the event identifier  314  is a value included in HTMLELEMENTEVENTS2 is mshtmdid.h, and the event object interface  316  is anIHTMLEventObj, which enables a designer to obtain more extended information about the event. 
   The methods  306 - 312  act as callback routines whenever an event occurs in the editing environment. In other words, whenever an event occurs that is detected by the editor  300 , each of the methods  306 - 312  is called, in a particular sequence, by the editor  300  to process the event. Processing the event may entail providing an external response to the event, responding internally to the event, not responding to the event, consuming the event and/or passing the event for further processing (i.e., not consuming the event). 
   The event routing controller  302  determines when a particular method will be called. If multiple designers are registered with the editor  300  in the designer registry  303 , the event routing controller  302  invokes the current method on each designer sequentially, in the order in which the designers were registered with the editor  300 . Further explanation of the event routing technique will be explained below with continuing reference to the elements and reference numerals of  FIG. 3 . 
     FIG. 4  is a block diagram of an event routing model utilized in an extensible editor. In addition to the editor  300  shown in  FIG. 3 ,  FIG. 4  includes a first extension, Designer A  320 , and a second extension, Designer B  330 . Although only two designers  320 ,  330  are shown, it should be understood that virtually any number of designers may be added to the editor  300 . The functionality of the routing mechanism when using more than two designers is similar to the description of the routing mechanism using the two designers  320 ,  330 . 
   The editor  300  is designed to receive notification of an event  400 . If the event  400  is a key combination input by a user, then the event routing controller  302  routes the event to the translate accelerator method  306 . The event  400  is made available to a translation accelerator  306   a  in Designer A  320 . The translation accelerator  306   a  of Designer A  320  may or may not provide a response to the event  400 . If a response is provided to the event  400  by Designer A  320 , then Designer A  320  may consume the event  400  to prevent Designer B  330  from overriding the response to the event  400  by Designer A  320 . To “consume” an event, a designer returns a value (S_OK) to the editor indicating that no further processing should be done on the event. If Designer A  320  does not respond to the event  400 , then the event  400  will be made available to a translation accelerator  306   b  of Designer B  330 . To indicate that an event should continue to be processed, a designer returns a different value to the editor (S_FALSE). Designer B  330  may then respond or not respond to the event  400  in the same way as described for Designer A  320 . This process continues with any other designers that may be attached to the editor  300 . 
   After each designer  320 ,  330  has had the opportunity to react to the event  400  (unless one of the designers  320 ,  330  has already consumed the event), control of the event  400  is returned to the event routing controller  302  of the editor  300 . It is noted that the editor  300  may include its own translate accelerator that is designed to translate the key combination. This translate accelerator could be a part of the default event handler  301 . In the preferred implementation, the default event handler  301  will receive the key combination (event  400 ) if not already consumed by one of the designers  320 ,  330 . The default event handler  301  may or may not be configured to provide a response to the particular key combination. If it is configured to respond to a particular key combination, then an appropriate response is made; if not, then no response will be made to the key combination. 
   It is significant that if Designer B  330  is configured to act on a particular key combination, Designer B  330  may never receive that key combination if Designer A  320  consumes the combination. Therefore, while the implementations described herein significantly improve conflict avoidance in extensible editors, when developing a new designer, careful consideration must be given to the key combinations and events that will trigger actions by a designer. Also, multiple designers can be strategically registered with the editor  300  to avoid this situation. 
   If the event  400  is not a key combination, then the event routing controller makes the event  400  available to the designers  320 ,  330  via the pre-handle event method  308 . Designer A  320  first has the opportunity to respond to the event  400 . If Designer A  320  is configured to respond to the event  400 , then it provides an appropriate response. After providing a response, Designer A  320  may either consume the event  400  or pass it along. 
   If, for example, Designer A  320  is an “auto correct” designer and Designer B  330  is a grammar checking designer, an event (entry of a word into the document) would be routed first though the auto correct designer to determine if the word should be corrected. After the word is checked (whether or not it is corrected), the grammar checking designer still requires notice of the event to perform its function. Therefore, Designer A  320  would act on the event but still make it available to Designer B  330   
   If the event  400  is not consumed by Designer A  320 , then the event  400  is made available to Designer B  330 . Designer B  330  has the same options of reacting to the event  400  as described above for Designer A  320 . This is true for each subsequent designer attached to the editor  300 . 
   After each designer has the opportunity to respond to the event  400  a first time, the event is passed to the default event handler  301  (assuming that the event  400  has not been previously consumed by a designer). The default event handler  301  then provides the default behavior of the editor  300  in response to the event  400 . It is noted that if no designers are attached to the editor  300 , then the editor  300  will simply provide the default editing behavior via the default event handler  301 . 
   After the default event handler  301  has acted on the event  400 , the designers  320 ,  330  are provided another opportunity to respond to the event  400 . The event  400  is made available to the designers  320 ,  330  through the post-handle event method  310 . The post-handle event processing is similar to the pre-handle event processing, occurring in the sequence in which the designers  320 ,  330  were registered with the editor  300 . 
   By way of example, suppose that a developer wants to implement an “auto correct” designer that listens to key strokes. The designer, in this case, should receive an event after a typed character is inserted into the document (i.e., PostHandleEvent) rather than before the character is inserted. Receiving the event after the default editor has inserted the character allows the designer to inspect the document with the correct content, allow undo of auto-correct behavior, etc. 
   After the post-handle event processing is concluded, the event  400  is processed by the default handler  301 . 
   The post-editor event notify method  312  is called after the editor  300  has finished its post-handling of the event  400  or when a designer  320 ,  330  has consumed the event. In the case where the event  400  is consumed by a designer  320 ,  330  before a default action takes place and no post-handle event methods are called, a post-editor event notification module  312   a ,  312   b  is invoked to give the designers  320 ,  330  an opportunity to make a final response. For example, suppose a mouse down event starts a selection in a designer that implements basic text selection. If there is a mouse down event, the designer starts the selection. Now, if some other designer consumes the corresponding mouse up event, the designer still needs to know about the mouse up event so it can terminate the selection and stop responding to mouse move events. 
     FIG. 5  is a flow diagram of the preferred implementation of the event routing model described above for use in an extensible editor  300 . Continuing reference will be made to the elements and reference numerals of  FIG. 2-FIG .  4  in the description of the flow diagram. 
   At step  500 , an event  400  is received by the editor  300 . The event routing controller  302  determines if the event  400  is a key combination at step  502 . If the event is a key combination (“Yes” branch, step  502 ), then the key combination is translated at step  504  by the designers (fi they are configured to translate the particular command) or by the default event handler  301  if no designer translates the key combination and the editor  300  is configured to do so. 
   If the event is not a key combination (“No” branch, step  502 ) the editor  300  determines if a designer  320 ,  330  is attached to the editor  300  at step  508 . If there is not an attached designer (“No” branch, step  508 ), the event is processed by the default event handler  301  at step  510 . If, however, a designer  320 ,  330  is attached to the editor  300  (“Yes” branch, step  508 ), then the event  400  is made available to Designer A  320  for pre-handling at step  512 . After Designer A  320  has had the opportunity to act on the event  400 , Designer B  330  (“Yes” branch, step  514 ) has the event  400  made available for processing at step  512 . There is no other designer attache (“No” branch, step  514 ), so the event (if not previously consumed), is passed to the default event handler  301  and processed at step  516 . 
   After the event  400  is processed by the default event handler  301  of the editor  300 , the event is made available to Designer A  320  for processing at step  518 . Since there is another designer (Designer B  330 ) (“Yes” branch, step  520 ), the event  400  is made available to Designer B  330  for processing at step  518 . When there are no more designers to process the event  400  (“No” branch, step  520 ), the event is processed by the default event handler  301  at step  522 . 
   It is noted that the above discussion assumes that the event  400  is not consumed by the default event handler  301  or the designers  320 ,  330  and is processed by each method of the editor  300  and the designers  320 ,  330 . Once an event is consumed, further processing of the event terminates. 
   After the event has been through the pre-handle event method  308  and the post-handle event method  310 , the post-editor event notification method  312  is called (step  524 ). Unless consumed by the default event handler  310  or one of the designers  320 ,  330 , each designer  320 ,  330  is notified of any response to the event  400  from any other module as previously described. 
   Designer Extensibility Mechanism Interfaces 
   In addition to the edit designer interface  304  described above, the designer extensibility mechanism  210  includes an edit services interface. In MSHTML, the edit services interface is designated as IHTMLEditServices, used to add or remove edit designers and control the current selection. Although the general descriptions of the designer extensibility mechanism can be applied and implemented in any extensible editor and extensions therefor, for discussion purposes, the described implementation will refer to MICROSOFT MSHTML terminology to describe interfaces exposed by a designer extensibility mechanism to allow extensions to be coupled to properly communicate with an extensible editor. Those skilled in the art will appreciate the functions enabled by the described interfaces to implement custom extensions for the extensible editor. 
   The following are detailed descriptions of the edit designer interface and the edit services interface. 
   Edit Designer Interface (IHTMLEditDesigner) 
   The edit designer interface includes the following methods: 
   Translate Accelerator 
   Description: Called by MSHTML to translate a key combination entered by a user into an appropriate command. 
   Syntax:
         HRESULT TranslateAccelerator (
           DISPID inEvtDispId,   IHTMLEventObj *pIEventObj   
               

   Parameters:
         inEvtDispId
           [in] DISPID that specifies the event.   
           pIEventObj
           [in] Pointer to an IHTMLEventObj interface that specifies the event.   
               

   Return Values:
         Returns S_OK to indicate that the event has been completely handled and that no further processing should take place, either by other edit designers or the MSHTML Editor. Returns S_FALSE to indicate that other edit designers and the MSHTML Editor should perform their processing this event.       

   PreHandleEvent 
   Description: Called by MSHTML before the MSHTML Editor processes an event, so that the designer can provide its own event handling behavior. 
   Syntax:
         HRESULT PreHandleEvent (
           DISPID inEvtDispId;   IHTMLEventObj *pIEventObj   
               

   Parameters:
         inEvtDispId
           [in] DISPID that specifies the event.   
           pIEventObj       

   [in] Pointer to an IHTMLEventObj interface that specifies the event. 
   Return Values:
         Returns S_OK to indicate that the event has been completely handled and that no further processing should take place, either by other edit designers or the MSHTML Editor. Returns S_FALSE to indicate that other edit designers and the MSHTML Editor should perform their pre-event processing.       

   PostHandleEvent 
   Description: Called by MSHTML after the MSHTML Editor processes an event, so that the designer can provide its own event handling behavior. 
   Syntax:
         HRESULT PostHandleEvent (
           DISPID inEvtDispId,   IHTMLEventObj *pIEventObj   
               

   Parameters:
         inEvtDispId
           [in] DISPID that specifies the event.   
           pIEventObj
           [in] Pointer to an IHTMLEventObj interface that specifies the event.   
               

   Return Values:
         Returns S_OK to indicate that the event has been completely handled and that no further processing should take place, either by other edit designers or the MSHTML Editor. Returns S_FALSE to indicate that other edit designers and the MSHTML Editor should perform their post-event processing.       

   PostEditorEventNotify 
   Description: Called by MSHTML after an event has been handled by the MSHTML Editor and any registered edit designers. 
   Syntax:
         HRESULT PostHandleEvent (
           DISPID inEvtDispId,   IHTMLEventObj *pIEventObj   
               

   Parameters:
         inEvtDispId
           [in] DISPID that specifies the event.   
           pIEventObj
           [in] Pointer to an IHTMLEventObj interface that specifies the event.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Edit Services Interface (IHTMLEditServices) 
   The edit designer interface includes the following methods: 
   AddDesigner 
   Description: Registers an IHTMLEditDesigner interface to receive event notification from the editor. 
   Syntax:
         HRESULT AddDesigner (
           IHTMLEditDesigner *pIDesigner   
           );       

   Parameters:
         *pIDesigner
           [in] Pointer to an IHTMLEditDesigner interface to register for event notification.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   GetSelectionServices 
   Description: Registers an IHTMLEditDesigner interface to receive event notification from the editor. 
   Syntax:
         HRESULT GetSelectionServices (
           IMarkupContainer *pIContainer   ISelectionServices **ppSelSvc   
           );       

   Parameters:
         *pIContainer
           [in] Pointer to an IMarkupContainer interface for which an ISelectionServices interface is desired.   
           **ppSelSvc
           [out] Address of a pointer to a variable that receives an ISelectionServices interface pointer for the ISelectionServices interface on the editor&#39;s selection object.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   MoveToSelectionAnchor 
   Description: Moves a markup point to the location of an anchor for the current selection. 
   Syntax:
         HRESULT MoveSelectionToAnchor (
           IMarkupPointer *pIStartAnchorr   
           );       

   Parameters:
         *pIStartAnchor
           [in] Pointer to an IMarkupPointer interface to move the location of an anchor for the selection.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   MoveToSelectionEnd 
   Description: Moves markup pointer to the end of the current selection. 
   Syntax:
         HRESULT MoveToSelectionEnd (
           IMarkupPointer *pIEndAnchor   
           );       

   Parameters:
         *pIEndAnchor
           [in] Pointer to an IMarkupPointer interface to move to the end of the current session.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   RemoveDesigner 
   Description: Unregisters a designer from the editor. 
   Syntax:
         HRESULT RemoveDesigner (
           IHTMLEditDesigner *pIDesigner   
           );       

   Parameters:
         pIDesigner
           [in] Pointer to the IHTMLEditDesigner interface to remove from the event notification queue.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Selection Services 
   Selection services provides extensions a way to modify a selection process of an extensible editor to which the designers are coupled. Although the general descriptions of the selection services can be applied and implemented in any extensible editor and extensions therefor, for discussion purposes, the described implementation will refer to MICROSOFT MSHTML terminology to describe interfaces exposed by a selection services component to allow extensions to properly communicate with an extensible editor to utilize the selection services component. Those skilled in the art will appreciate the functions enabled by the described interfaces to implement custom extensions for the extensible editor. 
     FIG. 6  is a block diagram of an extensible editor  600  that includes a designer interface  602 , an event routing mechanism  604 , and a selection services component  606 . The selection services component  606  includes several interfaces: a selection services interface  608  (ISelectionServices), a selection services listener interface  610  (ISelectionServiceListener), an element segment interface  612  (IElementSegment), a segment list interface  614  (ISegmentList), and a segment interface  616  (ISegment). These interfaces  608 - 616  will be discussed in greater detail, below. 
   The role of the selection services interfaces  608 - 616  is to provide designers or other editing extensions with the ability to modify the logical selection state. Consequently, all editing commands and services can interact with a custom selection model without having detailed knowledge of the designer that is implementing the selection. 
   For example, the “bold” command is able to implement the operation of making something bold without having any knowledge of the specifics of a given designer. The command is only aware of what part of the document is selected, and it is configured to make the selected region of the document bold. 
   Selection Service Interface (ISelectionServices) 
   The selection services interface  608  provides methods to programmatically clear, add and remove segments from a selection object. The methods include an add element segment method  618  (AddElementSegment), a get markup container method  620  (GetMarkupContainer), a get selection services listener method  622  (GetSelectionServicesListener), an add segment method  624  (AddSegment), a remove segment method  626  (RemoveSegment), and a set selection type method  628  (SetSelectionType). A detailed description of the available selection services interface  608  methods follows. 
   AddElementSegment 
   Description: The add element segment method  618  creates an IElementSegment interface for an element in a markup container and adds the segment to the editable selection. 
   Syntax:
         HRESULT AddElementSegment (
           IHTMLElement *pIElement,   IElementSegment **ppISegmentAdded   
           );       

   Parameters:
         *pIElement
           [in] Pointer to an IHTMLElement interface that specifies the element to add to the selection.   
           **ppISegmentAdded
           [out] Address of a pointer to a variable that receives an IElementSegment interface pointer for the element segment added to the selection environment.   
               

   return Values:
         Returns S_OK if successful, or an error value otherwise.       

   GetMarkupContainer 
   Description: The get markup container method  620  retrieves the markup container for the current editable selection. 
   Syntax:
         HRESULT GetMarkupContainer (
           IMarkupContainer **ppIContainer   
           );       

   Parameters:
         **ppIContainer
           [out] Address of a pointer to a variable that receives an IMarkupContainer interface pointer to the interface for the markup container that contains the current editable selection.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   GetSelectionServicesListener 
   Description: The get selection services listener  622  method retrieves an ISelectionServicesListener interface for the current editable selection so that the editor can process certain selection events. 
   Syntax:
         HRESULT GetSelectionServicesListener (
           ISelectionServicesListener **ppISelectionServicesListener   
           );       

   Parameters:
         **ppISelectionServicesListener
           [out] Address of a pointer to a variable that receives an ISelectionServicesListener interface pointer to the interface that the editor will use with the current editable selection.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   AddSegment 
   Description: The add segment method  624  creates an ISegment interface for the content between two markup pointers in a markup container, and adds the segment to the editable selection. 
   Syntax:
         HRETURN AddSegment (
           IMarkupPointer *pIStart,   IMarkupPointer *pIEnd,   ISegment **ppISegmentAdded   
           );       

   Parameters:
         *pIStart
           [in] Pointer to an IMarkupPointer interface that specifies the start point for adding the segment.   
           *pIEnd
           [in] Pointer to an IMarkupPointer interface that specifies the end point for adding the segment.   
           **ppISegmentAdded
           [out] Address of a pointer to a variable that receives an ISegment interface pointer to the interface for the added segment in the selection environment.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   RemoveSegment 
   Description: The remove segment method  626  (RemoveSegment) removes a segment from the editable selection. 
   Syntax:
         HRESULT RemoveSegment (
           ISegment *pISegment   
           );       

   Parameters:
         *pISegment
           [in] Pointer to an ISegment interface that specifies the segment to remove.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   SetSelectionType 
   Description: The set selection type method  628  (SetSelectionType) sets the selection type and clears any existing selection. 
   Syntax:
         HRESULT SetSelectionType;
           SELECTION_TYPE eType   ISelectionServicesListener *pIListener   
           );       

   Parameters:
         eType
           [in] SELECTION_TYPE enumeration that specifies the type of selection to set.   
           *pIListener
           [in] Optional. Pointer to an ISelectionServiceListener interface specifying the interface to associate with this selection. Set to NULL if unused. NOTE: Although this parameter is optional, without this parameter, the editor will not be able to restore the selection.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Element Segment Interface (IElementSegment) 
   The element segment interface  610  provides methods that control a fragment of HTML markup in the current editable selections that consists of a single element. The element segment interface  612  includes a get element method  630  (GetElement), an ‘is primary’ method  632  (IsPrimary), and a set primary method  634  (SetPrimary). To obtain an IElementSegment interface for a fragment of HTML markup representing an element, the ISelectionServices:AddElementSegment method is used. 
   The selection object uses element segments to mark fragments of HTML markup that are whole elements in particular control elements. 
   GetElement 
   Description: The get element method  612  (GetElement) retrieves the element to which this segment refers. 
   Syntax:
         HRESULT GetElement (
           IHTMLElement **ppIElement   
           );       

   Parameters:
         **ppIElement
           [out] Address of a pointer to a variable that receives an IHTMLElement interface pointer for the interface representing the element to which the segment refers.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Is Primary 
   Description; The is primary method  632  (IsPrimary) determines whether the control element represented by this segment is the primary element of a multi-element selection. The primary element of a multiple selection is typically the first one chosen by a user when a selection was made. The primary element typically has distinctive handles that indicate it is the primary element. For example, the primary element night have white handles while the other elements have black ones). 
   Syntax:
         HRESULT IsPrimary (
           BOOL *pfPrimary   
           );       

   Parameters:
         *pfPrimary
           [out] Pointer to a BOOL that receives TRUE if the element is the primary element, or FALSE otherwise.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Set Primary 
   Description: The set primary method (SetPrimary) sets or unsets a control element as a primary element in a control selection. The primary element of a multiple selection is typically the first one chosen by a user when a selection was made. The primary element typically has distinctive handles that indicate it is the primary element. For example, the primary element might have white handles while the other elements have black ones). 
   Syntax:
         HRESULT SetPrimary
           BOOL fPrimary   
           );       

   Parameters:
         fPrimary
           [in] BOOL that specifies TRUE to set the element as the primary element, or FALSE to unset it as primary.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Segment Interface (ISegment) 
   The segment interface  616  provides a method that creates containers (segments) for fragments of HTML markup in the current editable selection. These segments can include both a range of elements and element fragments. The segment interface  616  includes a get pointers method  636  (GetPointers). 
   GetPointers 
   Description: The get pointers method  636  (GetPointers) positions markup pointers at the start and end of the selection segment. 
   Syntax:
         HRESULT GetPointers (
           IMarkupPointer *pIStart,   IMarkupPointer *pIEnd   
           );       

   Parameters:
         pIStart
           [in] Pointer to an IMarkupPointer interface that specifies the markup pointer to position at the beginning of the segment.   
           pIEnd
           [in] Pointer to an IMarkupPointer interface that specifies the markup pointer to position at the end of the segment.   
               

   Return Values: 
   Returns S_OK if successful, or an error value otherwise. 
   Segment List Interface (ISegmentList) 
   The segment list interface  614  provides methods that access information about a list of the segments in the current selection. The segment list interface  614  includes a create iterator method  638  (CreateIterator), a get type method  640  (GetType), and an ‘is empty’ method  640  (IsEmpty). 
   CreateIterator 
   Description: The create iterator method  638  creates an ISegmentListIterator interface used for traversing the members of a segment list. 
   Syntax:
         HRESULT CreateIterator (
           ISegmentListIterator **ppIIter   
           );       

   Parameters:
         ppIIter
           [out] Address of a pointer to a variable that receives an ISegmentListIterator interface pointer for the newly created ISegmentListIterator.   
               

   Return Values: 
   Returns S_OK if successful, or an error value otherwise. 
   GetType 
   Description: The get type method  640  retrieves the type of the selection. 
   Syntax:
         HRESULT GetType(
           SELECTION_TYPE *peType   
           );       

   Parameters:
         peType
           [out] Pointer to a variable of type SELECTION_TYPE that receives the selection type value.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   IsEmpty 
   Description: The ‘is empty’ method  642  determines whether the segment list is empty. 
   Syntax:
         HRESULT IsEmpty (
           BOOL *pfEmpty   
           );       

   Parameters:
         pfEmpty
           [pout] Pointer to a variable of type BOOL that receives TRUE if the segment list is empty, or FALSE if it is not empty.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Selection Services Listener Interface (ISelectionServicesListener) 
   The selection services listener interface  610  provides methods that the editing component of MSHTML calls whenever certain events fire for a selection object that has a registered ISelectionServicesListener interface. This interface provides processing for undo events, for selection type changes, and whenever the mouse pointer exits the scope of an element in the editable selection. An application should supply an implementation of this interface for a selection object so that the editing component of MSHTML can respond to these events. The selection services listener interface  610  includes a being selection undo method (BeginSelectionUndo)  644 , an end selection undo method  646  (EndSelectionUndo), a get type detail method  648  (GetTypeDetail), an ‘on change type’ method  650  (OnChangeType), and an ‘on selected element exit’ method  652  (OnSelectedElementExit). To register an ISelectionServicesListener interface for a particular selection object, the ISelectionServices:::SetSelectionType method or ISelectionServices::OnChangeType method is used. 
   BeginSelectionUndo 
   Description: The begin selection undo method  644  is called by the editor  600  when an editing operation is beginning that may result in a change in selection after the editing operation. This method exists so that the designers may place their own units on an Undo queue so that a selection may be restored to its original state when the editing process was started. 
   Syntax:
         HRESULT BeginSelectionUndo (VOID);       

   Parameters:
         None.       

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   EndSelection Undo 
   Description: The end selection undo method  644  is called by the editor  600  at the end of an editing operation that may result in a change in selection after the editing operation. This method exists so that the designers may place their own units on an Undo Queue so that a selection may be restored to its original state when the editing process was started. 
   Syntax:
         HRESULT EndSelectionUndo (VOID);       

   Parameters:
         None.       

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   GetTypeDetail 
   Description: The get type detail method  648  is called by MSHTML to obtain the name of the selection type. This method allows a host application to provide the name of a selection type when implementing a custom selection mechanism. MSHTML will return a value of ‘undefined’ if the host does not implement this method. 
   Syntax:
         HRESULT GetTypeDetail (
           BSTR *pTypeDetail   
           );       

   Parameters:
         pTypeDetail
           [out] BSTR that specifies the name of the selection type.   
               

   Returns Values:
         Returns S_OK if successful, or an error value otherwise.       

   OnChangeType 
   Description: The ‘on change type’ method  650  is called by the editor  600  when the type of a selection changes. This method is used to implement custom processing that should take place when a selection is initiated or when a selection changes type. 
   Syntax: 
   HRESULT OnChangeType (
         SELECTION_TYPE eType,
           ISelectionServicesListener *pIListener   
           );       

   Parameters:
         eType
           [in] SELECTION_TYPE enumeration that specified the new selection type.   
           pIListener
           [in] Optional. Pointer to an ISelectionServicesListener interface to register with the new selection. Can be set to NULL.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   OnSelectedElementExit 
   Description: The ‘on selected element’ exit method  652  is called by the editor  600  whenever an element that intersects selection undo is removed from the document. This method exists so that the selection can be updated by the extensible editor (either removed or adjusted). 
   Syntax:
         HRESULT OnSelectedElementExit (
           IMarkupPointer *pIElementStart,   IMarkupPointer *pIElementEnd,   IMarkupPointer *pIElementContentStart,   IMarkupPointer *pIElementContentEnd   
           );       

   Parameters:
         *pIElementStart
           [in] Pointer to an IMarkupPointer interface specifying the point just before the element&#39;s opening tag.   
           *pIElementEnd
           [in] Pointer to an IMarkupPointer interface specifying the pointer just after the element&#39;s closing tag.   
           *pIElementContentStart
           [in] Pointer to an IMarkupPointer interface specifying the point just after the element&#39;s opening tag.   
           *pIElementContentEnd
           [in] Pointer to an IMarkupPointer interface specifying the point just before the element&#39;s closing tag.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   Highlight Rendering Services 
   Highlight rendering services allows a user to modify the rendered character attributes of text without modifying the document content. This facility is critical for providing a mechanism for providing user feedback without modifying the document content. This component is critical for providing a mechanism for providing user feedback without affecting persistence, undo, etc. 
     FIG. 7  is a block diagram of an extensible editor  700  that includes a designer interface  702 , an event routing mechanism  704 , and a highlight rendering services component  706 . The highlight rendering services component  706  includes two interfaces: a highlight services interface  708  (IHighlightRenderingServices), and a highlight segment interface  710  (IHighlightSegment). These interfaces  708 ,  710  will be discussed in greater detail, below. 
   Highlight Rendering Services Interface (IHighlightRenderingServices) 
   The highlight rendering services interface  708  provides method that enable a designer to control which sections of a document are highlighted on the screen and the style of highlighting. The methods include an add segment method  712  (AddSegment), move segment to pointers method  714  (MoveSegmentToPointers), and a remove segment method  716  (RemoveSegment). A detailed description of the available highlight rendering services interface  708  methods follows. 
   AddSegment 
   Description: The add segment method  712  creates a highlight segment for the markup between two display pointer and highlights it according to a specified rendering style. 
   Syntax:
             HRESULT AddSegment(   IDisplayPointer *pDispPointerStart,   IDisplayPointer *pDispPointerEnd,   IHTMLRenderStyle *pIRenderStyle,   IHighlightSegment **ppISegment       );       

   Parameters:
         pDispPointerStart
           [in] Pointer to an IDisplayPointer interface representing the start point of the segment to be highlighted.   
           pDispPointerEnd
           [in] Pointer to an IDisplayPointer Interface representing the end point of the segment to be highlighted.   
           pIRenderStyle
           [in] Pointer to an IHTMLRenderStyle interface representing the style with which to render the specified segment.   
           ppISegment
           [out] Address of a pointer to a variable that receives an IHighlightSegment interface pointer for the interface that represents the highlight segment between pDispPointerStart and pDispPointerEnd.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   MoveSegmentToPointers 
   Description: The move segments to pointers method  714  redefines a highlight segment and its style. 
   Syntax:
         HRESULT MoveSegmentToPointers (
           IHighlightSegment *pISegment,   IDisplayPointer *pDispPointerStart,   IDisplayPointer *pDispPointerEnd   
           );       

   Parameters:
         pISegment
           [in] Pointer to an IHighlightSegment interface to redefine.   
           pDispPointerStart
           p[in] Pointer to an IDisplayPointer interface for the new start point of the highlight segment.   
           pIDispPointerEnd
           [in] Pointer to an IDisplayPointer interface for a new endpoint of the highlight segment.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   RemoveSegment 
   Description: The remove segment method  716  removes a highlight segment from a collection of segments that are highlighted. 
   Syntax:
         HRESULT RemoveSegment (
           IHighlightSegment *pISegment   
           );       

   Parameters:
         pISegment
           [in] Pointer to an IHighlightSegment interface to remove.   
               

   Return Values:
         Returns S_OK if successful, or an error value otherwise.       

   IHighlight Segment Interface (IHighlightSegment) 
   The highlight segment interface  710  enables a user to control a highlighted section of a document. This interface does not provide any methods of its own beyond those available from it parent interface, ISegment. 
   Description: The highlight segment interface  710  provides type checking for the segments added or moved form the highlighted sections through the IHighlightRenderingServices interface. 
   Remarks: This interface does not provide any method of its own beyond those available from its parent interface, ISegment. 
   CONCLUSION 
   The services described above provide an applications program interface (API) for an extensible editor (MSHTML). The interfaces and the methods associated with each interface are summarized as follows: 
   IHTMLEditServices
         AddDesigner   GetSelectionServices   MoveToSelectionAnchor   MoveToSelectionEnd   RemoveDesigner       

   IHTMLEditDesigner
         TranslateAccelerator   PreHandleEvent   PostHandleEvent   PostEditorEventNotify       

   ISelectionServices
         AddElementSegment   GetMarkupContainer   GetSelectionServicesListener   AddSegment   RemoveSegment   SetSelectionType       

   ISelectionServicesListener
         BeginSelectionUndo   EndSelectionUndo   GetTypeDetail   OnChangeType   OnSelectedElementExit       

   ISegmentList
         CreateIterator   GetType   IsEmpty       

   ISegment 
   IElementSegment
         GetElement   IsPrimary   SetPrimary       

   IHighlightRenderingServices
         AddSegment   MoveSegmentToPointers   RemoveSegment       

   IHighlightSegment 
   The interfaces can be utilized by an extension that is coupled with the extensible editor to add new features to the editor, to augment existing features, or to override the editor&#39;s default behavior. Extensions can be used to modify the editor to provide customized feedback and to present a rich editing experience to a user. 
   Although details of specific implementations and embodiments are described above, such details are intended to satisfy statutory disclosure obligations rather than to limit the scope of the following claims. Thus, the invention as defined by the claims is not limited to the specific features described above. Rather, the invention is claimed in any of its forms or modifications that fall within the proper scope of the appended claims, appropriately interpreted in accordance with the doctrine of equivalents.

Technology Category: 3