I. BACKGROUND OF THE INVENTIONA. Technical Field[0001]
In general, the present invention relates to interacting with documents, and more particularly to undocking sections from HTML (hypertext markup language) documents.[0002]
B. Background of the Invention[0003]
The Internet has experienced tremendous growth. Through various HTML programming techniques (including tables and frames, for example), information may be presented to end users in visually appealing forms. However, one of the difficulties with these presentation techniques is that, once the table or form is coded, the end user has little ability by which to interact with the presented information. For instance, if a user is viewing an article in a frame as displayed in a browser (for example, Internet Explorer (IE) 4.0 by the Microsoft® Corporation or Netscape Navigator (NN) 4.0 by the Netscape Corporation), the user may scroll up or down the article. However, the user cannot read the article once the browser is closed. Further, the article cannot be moved apart from the window supported by the browser. The viewing interactivity experienced by the end user remains at a low level.[0004]
The ability to undock one display window from another allows a user to separate the two windows. However, current undocking solutions fail to provide an end user with freedom to navigate beyond the displayed windows. At least one Internet video-conferencing application (i.e., NetMeeting™) provides the ability to undock viewing windows. However, these “undocked” windows, while independently positionable, remain part of the parent video-conferencing application. Closing the parent video-conferencing application also closes the undocked windows.[0005]
Further, current separable windows in browsers fail to provide any sort of docking. In the current version of browsers (IE 4.0 or NN 4.0), instead of navigating to a new window with the current instance of the browser, an end user may open a new browser window and navigate it separately from the original instance of the browser. However, the user is always aware of the two separate instances of the browser. There is no ability to dock the two windows together to provide a browser window that is unified in appearance and navigation. Also, the two windows effectively remain independent of each other. In this regard, navigation of the first window does not effect the content of the second window. Current browsers do not allow incorporated content to be undocked from a main application.[0006]
In short, while providing simple textual markups and related display characteristics, HTML is limited in that it fails to provide application designers with a complex design language for applications. The current state of browsers or the HTML language itself fails to provide the needed underlying framework for these applications. While e-mail clients and NetMeeting™ incorporate a limited ability to undock windows from each other, a developer familiar only with HTML is prevented from providing even this limited functionality to a web page or an HTML document.[0007]
II. SUMMARY OF THE INVENTIONIn order to overcome the drawbacks mentioned above, the disclosed invention allows a user a greater amount of interactivity with displayed information. For example, the user may undock a desired portion from a parent window and manipulate the undocked desired portion apart from the parent window. Further, the undocked window may exist on its own after closing the parent application.[0008]
Controls, as used by the invention, may include Java-based scripts (developed by Sun Microsystems) and ActiveX® controls (developed by Microsoft® Corporation of Redmond, Wash.). ActiveX® controls are a popular and effective way of encapsulating functionality and distributing this functionality across a variety of platforms. Unlike Java applets and certain plug-ins, ActiveX® controls may be written in any number of programming languages. ActiveX® controls, based on OLE controls or OCX controls, are components (or objects) which can be inserted into a web page or other application to reuse packaged functionality that someone else programmed. For example, Microsoft's Internet Explorer 3.0 contains ActiveX® controls that allow users to enhance web pages with sophisticated formatting features and animation. ActiveX® controls are an enhancement over Java applets and certain web browser plug-ins since ActiveX® controls may also be used in applications written in any number of programming languages. Web authors may also write their own ActiveX® controls using Visual Basic 5.0 or Visual C++ and an ActiveX® control framework such as Microsoft Foundation Class Library (MFC), the ActiveX® Template Library (ATL), or the BaseClt framework. ActiveX® controls are designated within a web page by use of a standard HTML <OBJECT> tag. Typically, object tags include a set of parameters that include name value pairs, which are the persistence information of the control. The object tag includes a set of parameters that specify which control should be used and control the appearance and behavior of the control.[0009]
In one embodiment, the invention relates to a control placed on a web page that supports contained text (or images or other data) in which a displayed window containing the text may be undocked from the displayed page. The undocked window (that is, the sub-content window) may remain open after a user closes the browser. In an alternative embodiment, the undocked window may close with the parent application. Various applications of the invention relate to how an undocked window is re-docked to the web page including the handling of updates to the information contained in the window. Also, the invention may be applied to support information being ported from one application to another.[0010]
Applied to a browser platform, portions of an HTML document may be encapsulated by a script-based control according to the invention. For instance, the script-based control may be an ActiveX® Control (by the Microsoft® Corporation) similar to an IFRAME. The control then allows the user to “undock” a selected portion from a main content window (e.g., a browser window). The selected portion would then appear in a separate window that can be positioned and viewed independent of the original content window. In the browser example, the user can then navigate the browser away from the original document without affecting the undocked sub-content window. A further implementation of the invention allows the browser application to even be closed while leaving the undocked sub-content window open.[0011]
The invention includes aspects related to user interfaces for providing the user with an environment for undocking and docking sub-content windows, data structures for supporting the claims, (relating to the data structure as including different controls), system and method claims (relating to the support of the windows and coordination of events between the different windows), and computer-readable medium claims (related to a program for creating the undockable windows and for handling the windows once created).[0012]
These and other novel advantages, details, embodiments, features and objects of the present invention will be apparent to those skilled in the art from following the detailed description of the invention, the attached claims and accompanying drawings, listed herein, which are useful in explaining the invention.[0013]
III. BRIEF DESCRIPTION OF THE DRAWINGSIn the following text and drawings, wherein similar reference numerals denote similar elements throughout the several views thereof, the present invention is explained with reference to illustrative embodiments, in which:[0014]
FIG. 1 shows a schematic diagram depicting a computing environment according to embodiments of the present invention;[0015]
FIG. 2 shows the undocking of a window according to embodiments of the present invention;[0016]
FIG. 3 shows a control object creation flow diagram according to embodiments of the present invention;[0017]
FIG. 4 shows nesting container and control windows according to embodiments of the present invention;[0018]
FIG. 5 shows parallel container and control windows according to embodiments of the present invention; and,[0019]
FIGS. 6A and 6B show control object relationships according to embodiments of the present invention.[0020]
FIG. 7 shows control object relationships according to additional embodiments of the present invention.[0021]
IV. DETAILED DESCRIPTIONThe present invention is described as it would be used for Internet applications, which is one embodiment of the invention. The present invention, however, may be implemented generally within any number of computer applications including any software development tool for authoring text and computer-executable code. In the context of developing web pages, the present invention provides a tool for efficiently interacting with hypertext markup language (HTML) documents. In this context, the present invention may be authored within an authoring tool such as, for example, Visual C++, Visual InterDev and Visual J++ by Microsoft® Corporation of Redmond, Wash. The interaction with the dockable and undockable windows may occur in Internet Explorer 4.0, also by the Microsoft® Corporation.[0022]
As used herein, HTML script is intended to include the various scripting languages available for execution on browsers. The actual scripting language used when converting from the following programming environment into the HTML environment may vary based on the browsers to which the HTML code is to be eventually sent. Since the language, JavaScript is common to both Internet Explorer 4 (from Microsoft® Corporation) and Netscape Navigator 4 (from Netscape Corporation), this language may be used. Other languages (as are well known in the art) are also becoming available for use in browsers and are considered within the scope of the invention.[0023]
Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules. Generally, program modules include routines, programs, objects, scripts, 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 any number of computer system configurations including, but not limited to, 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. The present invention may also be practiced in personal computers (PCs), hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like.[0024]
A. Order of Description[0025]
In order to comprehend more readily the embodiments of the invention contained herein, the following lists the order of the contents of the detailed description:[0026]
Terms;[0027]
General Purpose Computer;[0028]
Docking and Undocking;[0029]
Objects and Object Relationships; and[0030]
Summary.[0031]
B. Terms[0032]
The following terms are used throughout the specification to relate to various concepts.[0033]
“Undock”—generally refers to the ability to separate a portion of a window into a separate window for independent movement and interaction.[0034]
“Dock”—refers to the ability to incorporate the contents of a separate window into another window or portion of a window.[0035]
C. General Purpose Computer[0036]
FIG. 1 is a schematic diagram of a computing environment in which the present invention may be implemented. The present invention may be implemented within a general purpose computing device in the form of a conventional[0037]personal computer200, including aprocessing unit210, asystem memory220, and asystem bus230 that couples various system components including the system memory to theprocessing unit210. Thesystem bus230 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. The system memory includes read only memory (ROM)240 and random access memory (RAM)250.
A basic input/output system[0038]260 (BIOS), containing the basic routines that help to transfer information between elements within thepersonal computer200, such as during start-up, is stored inROM240. Thepersonal computer200 further includes ahard disk drive270 for reading from and writing to a hard disk, not shown, amagnetic disk drive280 for reading from or writing to a removablemagnetic disk290, and anoptical disk drive291 for reading from or writing to a removableoptical disk292 such as a CD ROM or other optical media. Thehard disk drive270,magnetic disk drive280, andoptical disk drive291 are connected to thesystem bus230 by a harddisk drive interface299, a magneticdisk drive interface293, and an opticaldisk drive interface294, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for thepersonal computer200.
Although the exemplary environment described herein employs a hard disk, a removable[0039]magnetic disk290 and a removableoptical disk292, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in the exemplary operating environment.
A number of program modules may be stored on the hard disk,[0040]magnetic disk290,optical disk292,ROM240 orRAM250, including anoperating system295, one ormore application programs296,other program modules297, andprogram data298. A user may enter commands and information into thepersonal computer200 through input devices such as akeyboard201 and pointing device202. 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 theprocessing unit210 through aserial port interface206 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). Amonitor207 or other type of display device is also connected to thesystem bus230 via an interface, such as avideo adapter208. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
The[0041]personal computer200 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer209. Theremote computer209 may be another 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 thepersonal computer200, although only amemory storage device211 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN)212 and a wide area network (WAN)213. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
When used in a LAN networking environment, the[0042]personal computer200 is connected to thelocal network212 through a network interface oradapter214. When used in a WAN networking environment, thepersonal computer200 typically includes amodem215 or other means for establishing a communications over thewide area network213, such as the Internet. Themodem215, which may be internal or external, is connected to thesystem bus230 via theserial port interface206. In a networked environment, program modules depicted relative to thepersonal computer200, or portions thereof, may be stored in the remote memory storage device. 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.
D. Docking and Undocking[0043]
FIG. 2 represents one embodiment of the ability to support undockable content windows on a page. FIG. 2 shows a[0044]browser window A101 withtitle window102.Browser window A101 also includes two buttons Undock113 andDock114. When coding a page to be downloaded into a browser, the programmer incorporates the content to be displayed in an undockable sub-window. In one embodiment, the programmer can wrap the content to be displayed in HTML delimiters that specify the content may be undocked. Alternatively, the programmer may include a reference to an undocking control followed by a pointer to the location of the content. Similar to an IFRAME interface, this approach allows the programmer to easily specify that the content window is an undockable content window without having to incorporate the content itself. Alternatively,buttons113 and114 may be replaced by a script control that monitors the user's mouse input, in which a double click on the content signifies a request to undock the content window. Further, the undock and/or dock features may be under script control monitoring the elapsed time an end user spends on a page. After a predetermined elapsed time, the specified content portion may be undocked.
On the displayed page, two buttons may be shown: an[0045]undock button113 and adock button114. As their names suggest, the script underlying the buttons undocks and docks a designated dockedsub-content window116. This undocking can keep thesub-content window B116 in place over thebrowser window A101 or move it to another location (as represented by arrow117) to suggest the undocking nature of the window as represented by undockedsub-content window B115. How the undocked window is represented is a matter of scripting the specific commands to move a window to a new location.
FIG. 3 shows a flow diagram of the undocking of a content window.[0046]Browser window601 includesundock button603 anddock button602.Undockable content window604 is shown in a dotted line to represent that the undockable content may appear part of the general content displayed inbrowser window601. While described in reference to ActiveX®, it is also appreciated that the invention may be practiced in Java or in any programming language that may control the formation and creation of windows.
Alternatively, the[0047]undockable content window604 may be otherwise identified as undockable. For example,window604 may be shaded differently than the rest ofwindow601, the type face of the font used may be different, the size of the font may be different, and a border may exist around thewindow604. It is noted that these are only a few examples of the many alternative ways of representing thewindow604 to a user. Variations thereof are considered within the scope of the invention described herein.
[0048]Browser window601 relies on anHTML renderer component605 to determine how to display received HTML content.
In one example, this[0049]renderer605 is instantiated whenbrowser window601 is opened. When new information arrives atbrowser window601, thebrowser window601 determines how to display the new HTML content (or related displayable content or data including images) as, represented by theinformation exchange611. Alternatively, therenderer605 may be part of abrowser application601. Here, there may be no clear distinction between the renderer and the browser.
When a user instructs the underlying computer system (for example, a local computer, a network computer, and those as know in the art) to undock[0050]undockable content window604 frombrowser window601, an event is sent612 (or “fired” as is know in the art) to an UndockActiveX® control606. The Undock ActiveX® control then separatesbrowser window601 andundockable content window604 into two windows (thebrowser window610 and the undocked content window608) throughactions614 and615, respectively. Once undocked, the name or identity of the undockedcontent window608 may be specified automatically.
In another embodiment, the[0051]undockable content window604 remains inbrowser window610 and an instance ofundockable content window604 is instantiated as undockedcontent window608. Recursively performing this operation results in multiple child windows frombrowser window610. The names of the various child windows are named by the naming function described above.
[0052]Browser window610 remains connected to theinstance605 of the HTML renderer component as shown bypath613. A new instance of the HTML render component is instantiated as HTML rendercomponent607 to support the undockedwindow608 as shown viapath616. Alternatively, theHTML renderer607 may not be instantiated and undockedcontent window608 may be supported by theHTML renderer605.
When undocked, undocked[0053]content window608 remains in contact withbrowser window610 at least to its current content as shown viapath617. To this end, the undocked content window may fire and receive events frombrowser window610 for related events. For example, ifbrowser window601 included a home financing script or program with the result displayed inundockable content window604, when undocked, the undockedcontent window608 would still be able to receive updated calculations from the calculating script behind the displayed browser window610 (post-undocking).
In an alternative embodiment, the undocked[0054]content window608 may be severed from theparent browser window610 once undocked. In this case, updates inparent browser window610 would not be conveyed to the undockedwindow608. One advantage of not linking the undockedcontent window608 tobrowser window610 is that, when multiple copies of the undockedcontent window608 are made, each copy may be distinct. This allows a comparison between thedifferent child windows608. For example, in the calculation example given above, an end user may wish to perform the calculations using various criteria. Instead of printing out multiple copies of the results from the calculations, the end user may undock the results of the calculation every time a new calculation is made. Thus, the results of the calculations may be compared on-screen without printing out each new result.
When[0055]browser window610 is navigated to another location, the new location may not include a separable content window. In this regard, the undocked window retains the same state despitebrowser window610 navigating away. If the browser is navigated back to the original location that eventually resulted in the creation of undockedcontent window608, four alternatives may occur. These four alternatives are dependent on the script creating the undocked content window. First, the undockedcontent window608 may be updated with the content from the re-navigated to location bybrowser window610. Second, the undockedcontent window608 may retain its current state and not be updated by the new state of the re-navigated to location. Third, the undockedcontent window608 may be re-incorporated (docked) intobrowser window610 and the new content of the re-navigated to location replace the content of undockedcontent window608. Finally, fourth, the undockedcontent window608 may be re-incorporated (docked) intobrowser window610 and the content of the undockedcontent window608 replace the content of the re-navigated to location as displayed inbrowser610. Each of these four variations has its advantages as determined by the content on the navigated to page.
E. Objects and Object Relationships[0056]
Objects are used to create and control the windows described above. FIGS. 4 and 5 show various windows and the supporting objects. FIG. 4 shows[0057]browser window A101 withtitle window102. As described above, anundock button113 and adock button114 are displayed inbrowser window A101. Alternatively, the functions of these buttons may be incorporated into mouse commands or keystrokes. A number of objects are contained in browser window A. First is containablecontrol window B103. Within containablecontrol window B103 iscontainer C104. Withincontainer C104 iscontrol window D105. Control window D is what an end user sees when navigating to the page. When the end user initiates a command (for example through clicking on undock button113) to undock thecontrol window D105, both container window C and control window D are undocked as shown byarrow112.Arrow112 is bi-directional indicating that a window may be docked and undocked. Here, control window D exists as contained in container window C. The undocked versions of container window C and control window D are represented bywindows108 and109, respectively. In one embodiment, oncecontainer window C104 andcontrol window D105 are undocked frombrowser window A101, containablecontrol window B103 may remain on the page displayed in browser window A as a place holder.
Multiple undockable windows may be included on a page. When separate from each other, the undockable windows have distinct containable[0058]control windows B103. When combined, a single containablecontrol window B103 may support multiple container windows C. At least two variations on how the container windows are supported exist. First, as shown in FIG. 4, the container windows are nested in higher-level container windows. Here, container window E106 (supporting control window F107) is nested intocontainer window C104. When undocked,container window C108 includescontrol window109 and container window E110 (which includes control window F111). While not shown in FIG. 4,container window E110 may be undocked fromcontainer window C108.Container window C108 resizes to holdcontrol window D109.
FIG. 5 shows an alternative scheme for supporting container and control windows. FIG. 5 shows containable[0059]control window B303 having container window C304 (containing control window D305) and container window E306 (containing control window F307). In FIG. 5, containablecontrol window B308 stores bothcontainer window C304 andcontainer window E306 at the same level. Similar to FIG. 4 described above, undock/dock arrow312 is shown. After undocking,container window C308 includescontrol window D309. Juxtaposed tocontainer window C308 is container window E310 (containing control window F311).
The invention may be practiced by adding additional script callable methods to the IFRAME object that is present in the Internet Explorer 4.0 “Document Object Model”. The additional methods may allow the contents of the IFRAME to be undocked or docked, the creation of additional instances of sub document objects, and the ability to route events to or from the parent document and the IFRAME sub document. Also, the invention may be practiced through the use of script including Java, ActiveX® controls, and other known scripting languages. While the following relates to the implementation of the invention in an ActiveX® control, implementations in other languages as described above is considered to be within the scope of the present invention.[0060]
An ActiveX® control allows script in an HTML document to create sub-windows that can be docked or undocked by script control and, thus, by user control. As sub-windows can host any ActiveX® control, they can also independently host the HTML renderer control (also referred to as the WebBrowser ActiveX® control. Using this technique, the sub-windows can render received HTML documents.[0061]
To use a control, it needs to be instantiated. An example HTML tag section to instantiate the control is as follows:
[0062] | |
| |
| <OBJECT ID=“DockCtl” height=90 width=300 |
| CLASSID=“CLSID: 3fb6ccc7-2af2-11d2-bc63-00aa00a13c86”> |
| </OBJECT> |
| |
This also is used to identify where the “docked” location and what its size is in a main HTML document. Once instantiated, the control will create a child window of the browser application's window.[0063]
Next, script in the HTML document may prompt the control to create a sub-window. A sample statement is as follows:
[0064] | |
| |
| <script language=javascript> |
| mysub = DockCtl.HostControl(“{8856F961-340A-11D0-A9GB- |
| 00C04FD705A2}”, |
| “Caption”, “Name”, true) ; |
| </script> |
| |
Here, the control is identified as “DockCtl”. This control is asked to create a sub-window (containable control window) and host the control identified. It also specifies that the sub-window (containable control window) should have a caption of “Caption” and a name of “Name”. Further, it specifies that a new sub-window (container window) should be created and immediately docked in the control's first sub-window (containable control window). In response, the control creates the container window inside the containable control window. Finally, the system instantiates the identified control and initializes it by telling it to draw a control window inside of the newly created container window. Once the control window is created and the identified control is instantiated, an object pointer is returned to the script. This object pointer allows one to reference the instantiated control. In the following lines of script, the object pointer is named “mysub”. Now script can call methods implemented by the hosted control such as Navigate in the case of the WebBrowser control with:[0065]
mysub.Ctl.Navigate(“http://test.htm”);[0066]
This will cause the WebBrowser control (HTML renderer control) to render the specified document inside of the newly created child window. Now the main HTML document can present a user interface (e.g., a button described above) to allow the user to undock the child window. The script action that results from the user indicating that it wants the window to be undocked needs to tell the sub-window object to undock. An example code is as follows:[0067]
mysub.Undock( )[0068]
In a Windows[0069]32 implementation of the invention, acontainer window C104 in FIG. 4 is undocked by calling, for example, USER API's to switch the container window from being a child window to being a top-level window. The container window can also be re-docked by switching the window back to being a child window of the containablecontrol window B103.
Through using the nesting scheme described in FIG. 4, a number of advantages are provided. First, the control can create any number of sub-windows; with only one being docked at a time. This may be used for implementing individual instances of tear-off data such a notes or calculation results, etc. as described above. Also, the control may maintain a list of created sub-windows that can be searched by the Name specified in a HostControl list of sub-windows. This allows script in an HTML document to find the object pointer to an earlier created sub-window. This would be useful, if the HTML document only wants one version of a sub-window to exist; if the user undocks a sub-window and then navigates the browser away from the main document and later returns to the same main document, then script in the document could find the original undocked sub-window and force it to dock again, or leave it undocked without creating another sub-window.[0070]
FIGS. 6A and 6B show the objects used in an ActiveX control as an implementation of this invention.[0071]Control object401 is the main object for the ActiveX control; it provides an interface that is script callable (ITOCntrCtl), which allows containers to be created and located by name. Thecontrol object401 include the following members: m_pInprocServer402 (which holds a reference to the container server object405), m_pDockedCntr403 (which holds a reference to acontainer automation object414, if one is docked), and m_hWndCD404 (a handle to itscontainable control window417, orB103 in FIG. 4). Thecontainer server object405 is responsible for creating and maintaining a list of created container objects. It provides an interface for thecontrol object401 to create and locate container objects (ITOContainerServer).Container server object405,505 maintains a list of created container objects407,507 in g_ContainerList406 (FIG. 6A). Eachcontainer object407,507 includes three members: m_sinks410,510 (which hold references to thecontainer automation object414, so that event notifications can be sent to thecontainer automation object414 shown in FIG. 6A), m_hwnd411 (a handle to itscontainer window418, orC104 in FIG. 4), andm_pnext412,512 (which points to thenext container object407 listed inlist g_ContainerList406 shown in FIG. 6A). Eachcontainer object407,507 also contains acontainer408,508 that is the host for a hosted control, so itsmember m_punk409,509 holds a reference to the hostedcontrol object413,513. The hostedcontrol object413 owns acontrol window419, orD105 in FIG. 4, which is a child window of thecontainer window418. For eachcontainer object407 exists acontainer automation object414; it provides the script callable interface (ITOCntr) which allows containers to be docked, to be undocked, to be closed, and to fire events. Themember m_pContainer415 holds a reference to thecontainer object407, and, for the most part, it wraps the non-script callable interface (ITOContainer) with it script callable one (ITOCntr). It also has a member m_pSite that holds a reference back to thecontrol object401, if the container is currently docked.
When docked,[0072]container window418, which is the container window related tocontainer408, is considered a child window of thecontrol window417. When undocked, the container window is considered not a child window of the control window.
As shown in FIG. 6A,[0073]container window418 is in the docked state, som_pDockedCntr403 holds a reference to thecontainer automation object414,m_pSite416 holds a reference to thecontrol object401,m_pDockedCntr403 holds a reference to414, andcontainer window418 is a child window of thecontrol window417. FIG. 6B shows acontainer window504 in the undocked state. Here, there is no reference to thecontainer automation object503 from thecontrol object401,m_pSite502 does not hold a reference to thecontrol object401, andcontainer window504 is considered a top-level window.
FIG. 7 reflects alternative embodiments of the present invention. For example, FIG. 7 includes a global[0074]container server object405G. This server object contains aglobal container list406G that includes a list of the container objects and to which local container server object (for example,405L) is related.Control object401 may includem_pGlobalServer422 that holds a reference to the globalcontainer server object405G. Here,control object401 may hold references to both an in-process server and an out-of-process server. Each local container server object (for example,405L) contains a list (ContainerList406L, for example) of containers created and supported by thelocal server object405L and as further described with reference to FIG. 6A above.
One automation object may exist for every container object. For example, if one wants to display a stock ticker in an application, the container object would contain the information to be displayed and the container automation object would contain the settings on how to display the subject information. In some cases, it may be desirable to display the stock ticker in two separate applications (for example, in two separate browser windows). As the information to be displayed for the two applications is the same, one container object may be used. As the display settings may be different, two automation objects may be used. For instance, if one instance of the information is to be displayed at a fast rate and the other at a slow rate, two container automation objects[0075]414A and414B may be used. The two container automation objects414A and414B include member m_pContainer,415A,415B andmember m_psSite416A and416B, respectively. FIG. 7 shows the two container objects both in a docked state pointing to container object407A. In other circumstances, for example, when the information to be displayed in the two applications is different, a separate container object may be use for each application. It is understood that additional information contents may be used including images, databases, sounds, active or interactive sub application, etc.
In FIG. 6A, each container object pointed to the next container object in the[0076]list g_ContainerList406 throughpointer m_pnext412. In FIG. 7, each container object407A also points to a nested container object (for example the object supportingcontainer window E106 as nested incontainer window C104 of FIG. 4) usingm_psubcont420.
To implement the parallel containers as shown in FIG. 5, a similar pointer may be used that represents that the next container object is a parallel depth window, not a nested window. Here, this pointer is not shown for simplicity.[0077]
Further, in some instances, a hosted[0078]control object413 may not always point back to the object or container that referenced it. For example, the hostedcontrol object413 may require script to determine a self-automation object421 exists to allow a hosted control to determine information about itself. For instance, the hosted control object may be an application (a browser) in which the application requires additional information on how to function (what methods it can implement, etc.). The self-automation object421 implements interface ITOSelf that allows script hosted by hostedcontrol object413 to controlcontainer407A. To complete the information flow path between hostedcontrol object413, self-automation object421, and container object407A, self-automation object421 may also include a reference p_cont back to container object407A through interface ITOContainer.
As discussed above, another implementation of the invention is to add an extension of script callable methods to the IFRAME object, which provides control over an IFRAME element of HTML. While not described in detail, this alternative implementation is considered within the scope of invention and realizable by one of ordinary skill in the art based on the above disclosure.[0079]
The above-described invention may be applied to various applications. The invention may be used to create a new application inside of another application. Here, the new application would operate within the original application yet be separable from it when desired. Also, a collection of sub-applications may be combined to form a general application, for example a general desktop application including user interfaces for email, a data base program, a word processor program, a spreadsheet program, a notebook, and the like. In each application, the various components may be separable from each other as each is represented as an undockable object. For example, a user may create a tool bar containing a variety of user-specific applications. The toolbar may have relevance to a number of different applications. By using the above invention, the toolbar may be instantiated in conjunction with one application, undocked from the first application (which is then closed), then docked to a new application, here preserving any changes made to the toolbar when originally instantiated by the first application.[0080]
Further, the invention allows for greater customization of the desktop user interface as various display information may be provided in an undockable form. For example, a disk defragmentor application would include a separable status bar, which may be placed on a desktop apart from the more inclusive general defragmentor user interface.[0081]
F. Summary[0082]
A docking/undocking invention has been disclosed. The docking and undocking techniques allow a developer to encapsulate content in undockable and dockable elements (including scripts, controls, or related delimiters as an extension to the IFRAME of HTML). Further, it will be apparent to those skilled in the art that application of the present invention is not restricted to HTML as found on the Internet. It is also envisioned that the techniques of the present invention apply to any network using HTTP, including HTTPS-compliant networks, intranets and extranets. It is further envisioned that the techniques of the present invention apply in any text-authoring context where complex scripts require detailed knowledge of databases as well as related pages. For example, embodiments of the present invention contemplate the use of the disclosed undocking/docking system in conjunction with other systems including spreadsheets and other related environments.[0083]
Further, the present invention may also be implemented in a peer-to-peer computing environment or in a multi-user host system with a mainframe or a minicomputer, allowing the porting of data from one application to another. Thus, the computer network, in which the invention is implemented, should be broadly construed to include any client/server computer network from which a client can retrieve a remote document on a server (even if that document is available on the same machine or system).[0084]
In the foregoing specification, the present invention has been described with reference to specific exemplary embodiments thereof. Although the invention has been described in terms of a preferred embodiment, those skilled in the art will recognize that various modifications, embodiments or variations of the invention can be practiced within the spirit and scope of the invention as set forth in the appended claims. All are considered within the sphere, spirit, and scope of the invention. The specification and drawings are, therefore, to be regarded in an illustrated rather than restrictive sense. Accordingly, it is not intended that the invention be limited except as may be necessary in view of the appended claims.[0085]