KR20010109085A - Method and system for displaying window sub-components from different windowing environments as a single window grouping - Google Patents

Abstract

There is a need in the industry to use more than one Windows environment on a single computer system. This necessity stems from the economics of reusing features and different window environments with different effects. A problem with prior art multi-window environments is that they are not user friendly, inefficient, and bothersome. The efficient multiple window environment mechanism disclosed herein is clear to the user.

Description

TECHNICAL AND SYSTEM FOR DISPLAYING WINDOW SUB-COMPONENTS FROM DIFFERENT WINDOWING ENVIRONMENTS AS A SINGLE WINDOW GROUPING}

The present invention relates to a data processing system, and more particularly to a graphical user interface.

Since the middle of the 20th century, the use and popularity of computer systems have gradually increased. This trend has been stimulated by many different advances in computer system technology, but certain fundamental forms of computer system value have not changed. Clearly, one of the most basic criteria of computer system value is the ease of use of computers, past and in the future. Easy use of computers means popular, and popular means commercial success. Therefore, computer system suppliers continue to make their computer systems easier to use.

Early computer systems were very difficult to use. It mainly meant that some selected engineers and scientists were worth it. The introduction of personal computers in the 1970s and developments known as graphical user interfaces (or GUIs for short) have significantly increased the popularity and universal use of computer systems. A GUI is one of the computer system display formats that enables a computer system user to interact with the computer system by specifying individual display of other computer system items such as program displays (windows), item lists (menus), files, and commands. Form. It can be said that different types of graphical user interfaces provide different benefits and advantages, while providing a windowing environment directly with any type of GUI. The window environment is the standard way in which windows, menus, and other computer system items are handled and displayed.

Beyond the obvious benefits offered to computer system users by the graphical user interface, the GUI also benefits computer system developers, who do not know how their computer programs do what they do instead of how they provide them. You can focus your attention. This benefit is provided through a set of mechanisms or services (sometimes called interfaces) that computer system developers use to enable their programs to interact with a user. Since each developer is given the same interface, all programs written using the same window environment tend to interact with the user in a similar manner.

However, a recent trend in the computer systems industry is to use multiple window environments in a single computer system. The motivation behind this trend is to provide the user with the benefits and benefits of one or more window environments. This approach is good for the user, but it causes problems for developers. We initially said that one benefit of the Windows environment is that it is a standard way of providing computer system resources to users. It should be understood that "standard" means the standard for all programs developed using the same Windows environment. More simply, different windowing environments provide different interfaces for providing and handling computer system resources in the sense that a program written to one set of interfaces does not work with an interface provided by a different windowing environment. This incompatibility greatly reduces the benefits that are key to the multiple window environment trend. Developers could not easily develop programs that use one or more Windows environments without sacrificing the benefits gained from displaying and handling windows, menus, and other computer system items in a standard manner.

The present invention is a mechanism for displaying window subcomponents from different window environments as a single window group. The invention is well practiced as two or more child windows from different window environments that are constantly displayed as child windows within a single dialog box (i.e., parent window).

1 is a block diagram of a computer system used to implement a preferred embodiment of the present invention.

2 is a block diagram illustrating some of the functions provided by the window environment of a preferred embodiment of the present invention.

FIG. 3 is a block diagram used to illustrate the interrelationship of parent windows, child windows, and child window stubs in a preferred embodiment of the present invention. FIG.

4 is a flow chart showing the steps used in the preferred embodiment for performing initialization of a window of the preferred embodiment of the present invention.

5A, 5B and 5C are flow charts showing the steps used in the preferred embodiment for performing the operating behavior of the window of the preferred embodiment of the present invention.

6A and 6B show screen shots of an example dialog box.

7A and 7B are flowcharts showing the steps used in the preferred embodiment for carrying out the shutdown process of the preferred embodiment of the present invention.

The features of the present invention will be described in more detail in the text with reference to the accompanying drawings.

1 is a block diagram of a computer system of a preferred embodiment of the present invention. Computer system 100 is an improved IBM personal computer 300PL. However, the invention is not limited to either form or type of computer system. The present invention is not limited to a computer system having all the components shown in FIG. 1 or an arrangement of specific components. For example, the invention may be practiced in many network-centric environments, such as those used as network computers or hand held devices. Therefore, the word system is used here to generally refer to a device having sufficient attributes to practice the invention.

As shown, the computer system 100 may include a main or central processing unit (CPU) 105 connected to the network adapter 110, the display adapter 110, the auxiliary storage adapter 125, and the main memory 135. Include. The components of such a system are interconnected using a system bus 130.

The CPU 105 is a 550 MHz Pentium processor manufactured by Intel Corporation. However, it is to be understood that the present invention is not limited to any type of processor, and that the present invention may be practiced using any other type of processor, such as a coprocessor or coprocessor.

Auxiliary storage adapter 125 is used to connect mass storage devices (such as hard disk drives) to computer system 100. Display adapter 120 is used to directly connect a display device to computer system 100. Network adapter 110 is used to connect computer system 100 to another computer system.

As shown, the main memory 135 includes an operating system 140, a window environment 150, a window environment 160, and a window environment 170. In addition, FIG. 1 illustrates an application program 155 and an application program subfunction 165. A user of computer system 100 interacts with these programs using a keyboard and / or pointing device (not shown).

Application 155 and application subfunctions 165 and 175 are associated with window environment 150 and application subfunctions 165 and 175 should be observed as being associated with window environment 160 and 170. . As described in the Background of the Invention above, the preferred embodiment window environment is used to display and manipulate windows, menus, and other system items in a consistent manner. The reader of this specification should understand that this particular environment has advantages and disadvantages, respectively, which are the reasons why multiple window environments are used in a single computer system.

Operating system 140 of the preferred embodiment is known in the industry as Windows 95 (trade name) marketed and licensed by Microsoft. Windows 95 incorporates its own windowing environment in which the windowing environment 150 is shown as part of the operating system 140. Because of its relevance to the operating system of the preferred embodiment, the window environment 150 is called a native windowing environment. In a preferred embodiment, the Windows environment 160 is provided by a runtime environment known in the industry as a Java Runtime Environment (trade name) marketed and licensed by Sun Microsystems.

Computer system 100 allows its programs to act as if they are accessing a single mass storage entity (ie, instead of accessing multiple small storage entities such as main memory 135 and HDD). A known virtual addressing mechanism is used. Therefore, certain mechanisms and configurations are shown to reside in main memory 135 and those skilled in the art will recognize that such programs do not need to be completely included in main memory 135 at the same time. For example, operating system 140 resides in main memory 135 while running on CPU 105, but will reside on an attached HDD for another time (the term memory used herein generally refers to storage devices). Refers to storage that affects the entire virtual address space of a computer system, regardless of the particular physical device it comprises).

As a preliminary prerequisite, those skilled in the art will appreciate that the mechanisms of the present invention may be distributed as various forms of program products while the present invention is described in view of fully functional computer systems. The present invention applies equally regardless of the particular type of signal storage medium used to actually perform the dispersion. Examples of signal storage media are as follows. Examples are recordable forms of media such as floppy disks, hard disk drives, CD-ROMs and transmission media such as digital and analog communication links.

2 is a block diagram illustrating some of the functions provided by the window environment of the preferred embodiment. These functions are shown as related to the window environment 150, and these general same features can be found in other window environments of the preferred embodiment. It should also be understood that the illustrated functions represent only a short list of those provided by the window environment and / or general window environment of the preferred embodiment. These functions become standard interfaces that allow program developers to behave their programs similarly to other programs written using the same interface. For example, developer A can create a check box using a standard interface provided by a given window environment. Later, developer B can use the same interface to create different check boxes, and both check boxes will generally share the same appearance and behavior.

3 is a block diagram used to illustrate the interrelationship between the window environment, parent window, child window, and child window stub of the preferred embodiment. For this purpose, the parent window and the child window should be considered as two windows appearing to the user to be related to each other. In a preferred embodiment, all parent windows generally provide functionality common to all child windows. For example, a parent window typically provides a basic window with a title bar and one or more buttons (eg, OK button, CANCEL button, APPLY button in the Windows environment of the Windows 95 operating system).

As shown, each parent window in FIG. 3 was created using a different window environment. In a preferred embodiment the parent windows 152, 162, 172 can be created in parallel with each other such that they can be displayed to the user one at a time in a superimposed form. In other words, even if the parent window is created using an interface of a different window environment, the parent window is similar to each other (ie, title bar) so that the parent window can be displayed on top of each other while giving the user the effect that the parent window is actually being used. , Borders, buttons) are designed.

It is to be understood that one child window is not limited to a single child window-parent window pair nor to the preferred embodiment associated with each parent window. The plurality of child windows may be generated using the same window environment. Child window 154 is associated with parent window 152, child window 164 is associated with parent window 162, and child window 174 is associated with parent window 172.

Child window stubs are the means by which access is provided to functions associated with other parent windows. For example, a developer may record a program (i.e., an application 155), and may also use sub-functions (as shown by sub-function 157) and window environment 160 using window environment 150. Assuming a subfunction is recorded, the developer creates a child window stub 156 to provide access to the parent window 162 and its child windows (child windows 166). Also provided is a child window stub 164 that is used to facilitate user return access to the parent window 152 after accessing the parent window 162. The manner in which the user operates in the preferred embodiment will be described in more detail with reference to FIGS. 5A, 5B and 5C. However, it is now said that user access to different parent windows (and their associated subfunctions) is achieved through the selection of the appropriate child window stub (also referred to herein as a selection). The user can then access the desired program or subfunction through the appropriate child window.

4 is a flow chart showing the steps used in the preferred embodiment to perform initialization of the child window of the preferred embodiment. Attention should be paid to FIG. 4 to facilitate the description of the initialization of the window of FIG. 3. Therefore, those reading this specification should read the description with respect to FIGS. 3 and 4.

The initialization process begins at block 400 when the user requires execution of a program associated with one or more parent windows. User requests typically occur when a user starts a program or function. For convenience of explanation, those reading this specification assume that the user requires the execution of a program associated with the parent window 152, i. At block 405, the parent window 152 is initialized in a manner defined by its window environment (ie, window environment 150). However, it should be noted that the initialization is divided into two parts, referred to herein as "creation" and "activation." Most of the creation steps will be described with reference to FIG. 4, and the activation steps are described in FIGS. 5 and 6 and related texts. The creation step includes determining which child windows are similarly registered with the parent window to require initialization.

As shown in FIG. 3, the child windows 154, 156, 158 are associated with the parent window 152, meaning that they need to be initialized with each other. Creation of the child window 154 is handled in the manner defined for the child window (block 152) of the window environment 150. However, child window stubs 156 and 158 are associated with other windowing environments and therefore require special handling. Child window stub 156 is made to execute by parent window 152 when parent window 152 detects its registration (block 415). Those skilled in the art will appreciate that the exact manner in which the child window stub 156 is created for execution is specific to the window environment at the time of publication. For example, child window stub 156 may be called directly by parent window 152, or child window stub 156 may be called indirectly through some other means. The child window stub 156, which accesses the necessary storage information about the parent window 162 and its child windows, proceeds to create a child window 166 (block 420). Child window 166 is the main subfunction associated with parent window 162 and is created in such a way as to be associated with parent window 162 when appropriate.

Child window stub 156 then retrieves the necessary creation information for child window 166 (block 430). Creation information includes child window definitions (ie, tab titles, sizes) and commit and cancel handlers. The tab title is used to identify specific tabs (eg, see tab 605 and tab 610 of FIG. 6A) for each child window of the parent window. The size is important because the parent windows must be (1) all the same size and (2) large enough to house the largest child window. Commit and cancel handlers are shown in FIG. 7 and described in the related text.

Process block 440 is to show that the processing of blocks 415-430 must be repeated to create the configuration associated with the child window stub 158. It should also be noted that the processing of blocks 415-430 only occurs for each additional window environment (ie, each child window). Thus, if parent window 162 is configured to provide two sub-functions instead of one, parent window 152 has two child window stubs that provide the necessary access, but processing of blocks 415-430 is a windowing environment. Need not be repeated for 160.

Once all windows have been initialized, the parent window 152 and child window 154 are activated and displayed to the user (processing block 450). The user can then select and execute the subfunction associated with the child window 154 (ie, subfunction 157).

5A, 5B and 5C are flow charts showing the steps used in the preferred embodiment for performing the operational behavior of the child window of the preferred embodiment. As with FIG. 4, FIGS. 5A, 5B and 5C are shown in relation to FIG. 3. Therefore, those reading this specification should read the detailed description with reference to FIGS. 3, 5A, 5B and 5C.

Here it is assumed that the user wants to activate the subfunction 165. To do this, the user selects a child window stub 156 (block 500 in FIG. 5). Child window stub 156 responds by determining whether parent window 162 has been created (block 502). If the parent window has not been created, the child window stub 156 creates the parent window 162 at processing block 504 and the parent window itself and its parent window 162 to create the child window stubs 164 and 168. Pass information about synchronization (ie, child windows 154 and 158). Child window stub 156 then determines whether the child window associated with the selected subfunction has been activated beforehand (processing block 506). If activation is needed, child window stub 156 activates child window 166 (block 508) before instructing parent window 162 to display itself and child window 166 (block 508). To proceed. The child window stub 156 then instructs the parent window 152 to hide the parent window itself (note the design choice for displaying the next parent window before instructing the previous parent window to hide itself). This technique aims to reduce the user's perceptible screen flashing / flicker in any environment, and it is important to note that the interface used to indicate a window to show and hide is unique in the included window environment. It is known to those skilled in the art and further detailed description thereof will be omitted. Parent window 162 and child window 166 are then displayed to the user (block 514).

The user can then execute the subfunction 165. The hiding of parent window 152 and the showing of child window 162 occur very quickly so that two different parent windows are used and not aware that two parent windows are created and created using different window environments.

When the user completes a conversation with the subfunction 165 in the child window 166, the user may decide to execute the subfunction 157 or the subfunction 175. Assuming sub-function 157 has been selected, the user can access the sub-function 157, as described above, with a window stub that provides access backpath to parent window 152 (i.e., through child window 154). 164). Parent window 162 detects selection of child window stub 164 and informs child window stub 156 of user behavior 519. Child window stub 156 then instructs parent window 152 to display itself and child window 154 (block 520), instructs parent window 162, and hides itself (block 524). Parent window 152 and child window 154 are displayed to the user (block 526).

Returning back to FIG. 5C, instead of selecting subfunction 165, if the user wants to access subfunction 175, the user has parent access to subfunction 175 (ie, through child window 178). Provide an access path to window 172. Parent window 162 detects that child window stub 168 is selected and notifies child window stub 156 that causes parent window 152 to display child window stub 158.

Upon activation, child window stub 158 determines whether parent window 172 is created (block 528). If not, child window stub 158 creates parent window 172 (block 530) and causes child window stubs 174 and 176 to be created. Child window stub 158 then determines whether child window 178 is active (block 532) and activates child window 178 if it is not active (block 544). Child window stub 158 instructs parent window 172 to display itself and child window 178 (block 540). The child window stub 156 then instructs the parent window 162 to hide itself. Parent window 172 and child window 178 are displayed to the user (block 514). Next, the user can execute the sub function 175.

6A and 6B are screen diagrams of dialog boxes constructed using the mechanism of the preferred embodiment. This screen drawing shows how parent windows, child windows, and child window stubs are shown to the user. Those reading this specification should understand that the purpose of this embodiment is to show that electrical and statistical subfunctions are recorded using different window environments. As shown in Fig. 6A, the example relates to information about a fictional baseball player named Joe V. Good. As mentioned above, the parent window provides many basic components to show to the user. Here, the parent window 600 provides a basic window, window border, title bar, view button, and cancel button. The child window 605 is in an active state showing the electrical subfunction. Statistical child window 610 is inactive and child window stubs are represented only by selections. When the user selects the selection item 610, the parent window 600 is automatically hidden and the parent window 650 along the child window 655 is shown at that location. Again this transition happens very quickly, meaning that the user does not realize that two different parent windows are used or that two different sets of windows and sub-functions are created using different window environments.

7A and 7B are flowcharts showing the steps used in the preferred embodiment for executing the blocking process of the window of the preferred embodiment. The blocking occurs when the user makes a choice to generate a closed event. A close event is selected by a user in a dialog box (e.g., "OK" or "view" as shown in FIGS. 6A and 6B) or a cancel button (e.g., see the "Cancel button" in FIGS. 6A and 6B). The term " commit " and " cancel " are used herein and other user actions that proceed or are avoided are within the spirit and scope of the present invention.

7A illustrates the steps used to perform blocking processing of a parent window and a child window / stub when a close event is received by the native window environment. As used in this patent, a close event is any event that causes a blocking process to occur. In another way, a closed event is an event in which an application is notified that execution must be terminated. Such notification may be initiated by the operating system or the user. An example of a user initiated close event occurs when the user selects a well known " OK " or " CANCEL " button. Programmatically close events are received directly by the native window environment (ie, window environment 150 in the preferred embodiment) or indirectly from another window environment (ie, window environment 160, 170 in the preferred embodiment). It should be understood that it can be.

The close event is detected at block 700 by the parent window 152. Those skilled in the art will appreciate that data justification is required in the selection of an OK button, sometimes called a commit selection, before blocking the application. Data justification techniques are well understood and are not important for the benefit and benefit of the present invention. Therefore, this description is not described here.

For each registered child window stub, the parent window 152 will load the associated child window stub in line (block 720). The child window stub determines whether its associated parent window (ie, parent window 162 or window 172 in this case) exists (block 740). If the parent window does not exist, the child window stub knows that no blocking process is needed, meaning that parent window 152 can continue to check for more window stubs. If the parent window exists, the child window stub notifies the parent window of the occurrence of the close event (block 745). Control then returns to the parent window checking for more child window stubs (block 725). Once the parent window traverses all of its child windows, it then removes itself and all of its child windows from the display screen (block 727) and terminates execution (block 730). The step of removing the child window may vary according to a specific window environment and contents at the time of publication. In a Microsoft Windows ™ environment, for example, each child window is informed of the block and is instructed, and each child window gives the child window an opportunity to save data and explicitly free memory and other resources. On the other hand, in a Java ™ environment, data can also be saved, but references to child windows are simply released, which is solved by the release of resources for the upcoming garbage collection cycle.

7B is used to perform shutdown processing of the parent window and child window / stub when a close event is received by a non-native window environment. Again, as mentioned, the close event may be received by the window environment directly or indirectly from another window environment. The close event is detected at block 752 by the parent window (either parent window 162 or parent window 172 in the preferred embodiment). The parent window first determines if a block flag has been set (block 7730. If the block flag is set, processing terminates at block 770 when block processing is not needed for this parent window. The block flag is set at block 775. The parent window then continues processing at block 777 to determine if the close event is an event originating from a native window stub (window stub 156 in the preferred embodiment). If no notification comes from the native window stub, notification of a close event to the native window environment is not necessary, so that the parent window proceeds to block its child window or windows and removes itself from the display screen. (Block 767) If the notification does not come from the native window stub, close it Notification of the event is provided through the raw child window stub before blocking its child window or windows (block 780) and removes itself from the display screen (block 767).

Once the parent window traverses all its child stub windows, then it removes itself and all its child windows from the display screen (block 767) and terminates execution (block 770).

The embodiments and examples described herein have been presented to best illustrate the invention and its practical application, and thus enable those skilled in the art to make use of the invention. However, one of ordinary skill in the art appreciates that the foregoing description and examples are presented for purposes of illustration. The written description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the teachings without departing from the spirit and scope of the appended claims.

The present invention makes it possible to display window subcomponents from different window environments as a single window group.

Claims (15)

A computer-implemented method for displaying a window on a display device, Displaying the first parent window and the first child window in response to a request from a user, wherein the first child window is generated by a first window environment; Displaying a second child window upon the user's request, the second child window being generated by a second window environment; Computer implemented method comprising a. The method of claim 1, wherein displaying the second child window comprises overlapping the first parent window with a second parent window prior to displaying the second child window. And wherein the computer-implemented method is generated by the second window environment. The computer implemented method of claim 1 further comprising displaying a third child window at the request of the user, wherein the third child window is generated by a third window environment. The computer-implemented method of claim 1, further comprising displaying a third child window upon request of the user, wherein the third child window is generated by a third window environment. A computer-implemented method for displaying a window on a display device, Displaying the first parent window and the first child window in response to a request from a user, wherein the first child window is generated by a first window environment; Displaying a second child window at the request of the user, wherein the second child window is generated by a second window environment, and the second child window is created by the second window environment Is displayed in a manner that avoids alerting the user- Computer implemented method comprising a. 6. The method of claim 5, wherein displaying the second child window comprises overlapping the first parent window with a second parent window before displaying the second child window. Computer generated by the second window environment. 7. The computer-implemented method of claim 6, further comprising displaying a third child window at the request of the user, wherein the third child window is generated by the second window environment. 6. The computer-implemented method of claim 5, further comprising displaying a third child window at the request of the user, wherein the third child window is generated by a third window environment. Signal storage media, A program product comprising a program stored in said signal storage medium, said program comprising: Displaying a parent window and a first child window in response to a request from a user, wherein the first child window is created by a first window environment; Displaying a second child window upon the user's request, the second child window being created by a second window environment Program product configured to run. Signal storage media and A program product comprising a program stored in said signal storage medium, said program comprising: Displaying a parent window and a first child window in response to a request from a user, wherein the first child window is created by a first window environment; Displaying a second child window at the request of the user; the second child window is generated by a second window environment, and the second child window is created by the second window environment. Is displayed in a manner that avoids alerting the user- Program products that are configured to run. Processing unit, With memory, A system comprising a program stored in said memory for execution in said processing unit, said program comprising: Displaying the first parent window and the first child window in response to a request from a user, wherein the first child window is generated by a first window environment; Displaying a second child window at the request of the user; the second child window is generated by a second window environment, and the second child window is created by the second window environment. Is displayed in a manner that avoids alerting the user- The system is configured to run. 12. The method of claim 11, wherein displaying the second child window comprises overlapping the first parent window with a second parent window before displaying the second child window. Computer generated by the second window environment. 13. The computer-implemented method of claim 12, further comprising displaying a third child window at the request of the user, wherein the third child window is generated by the second window environment. 12. The computer-implemented method of claim 11, further comprising displaying a third child window upon request of the user, wherein the third child window is generated by a third window environment. Signal storage media, A program product comprising a program stored in said signal storage medium, said program comprising: Displaying a parent window, a first child window, and a second selection item in response to a request from a user, wherein the first child window is created by a first window environment, the selection item being accessed through a second window environment Indicates possible information Program products that are configured to run.