Information processing device, its control method, and program

Abstract

To improve user convenience in an information processing apparatus including display means on which a plurality of windows are displayed in an overlapping manner.SOLUTION: An information processing apparatus has display means for displaying a plurality of windows including a first window for a first application and a second window for a second application to be started by the first application in an overlapping manner. The second application comprises notification means for transmitting, to the first application, a notification indicating that the second window has been displayed. The first application comprises display control means for hiding the first window in a case where the notification is received.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, a control method thereof, and a program.

Background Art

[0002] A technique for displaying a plurality of windows on a display device connected to an information processing apparatus is known. Patent Document 1 discloses a window display control technique for preventing user operations when displaying a plurality of windows on a display device.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, when a new application (hereinafter referred to as "app") is launched, the window of the app may be displayed behind other windows instead of being displayed in the frontmost position, and it may not be possible to confirm whether the app has been launched. In view of the above problems, an object is to improve user convenience in an information processing apparatus having a display means for displaying a plurality of windows overlapping each other.

Means for Solving the Problems

[0005] The present invention relates to an information processing apparatus having display means for displaying a plurality of windows, including a first window of a first application and a second window of a second application launched by the first application, wherein the second application includes notification means for sending a notification to the first application indicating that the second window has been displayed, and the first application includes display control means for hiding the first window when it receives the notification. [Effects of the Invention]

[0006] In an information processing device having a display mechanism that shows multiple overlapping windows, user convenience can be improved. [Brief explanation of the drawing]

[0007] [Figure 1] A diagram illustrating the system configuration in an embodiment of the present invention. [Figure 2] Flowchart showing the window display process in the embodiment [Figure 3] Diagram showing the window display state in the embodiment (no other windows). [Figure 4] This diagram shows an example of a screen displayed when a UWP app is accepting input. [Figure 5] Diagram showing the display state of the window in the embodiment (with other windows present) [Figure 6] Diagram showing the window display state in the embodiment (another window is active) [Figure 7] Diagram illustrating the system configuration in other embodiments. [Figure 8] Flowchart showing window display processing in other embodiments [Modes for carrying out the invention]

[0008] Preferred embodiments of the present invention will be described in detail below with reference to the attached drawings. Note that the following embodiments do not limit the scope of the present invention as defined in the claims, and not all combinations of features described in these embodiments are necessarily essential to the solution of the present invention. Hereafter, a PC will be used as an example of the information processing device in these embodiments, but a tablet terminal or the like may also be used. In this embodiment, we consider the case where a desktop application (hereinafter referred to as "desktop app") is launched from a Universal Windows Platform (hereinafter referred to as "UWP") app supported by Windows 10 (registered trademark) using the Desktop Bridge mechanism. Desktop bridging is a mechanism for launching desktop applications from UWP applications. With Desktop bridging, the desktop application to be launched is first registered in the UWP application's manifest, and then packaged in a dedicated package prepared for each UWP application. The UWP application can then launch the registered desktop application using a dedicated application programming interface (API).

[0009] Here, we will explain desktop applications. Desktop applications are traditional applications that are executed or installed using executable files (.EXE, etc.) provided by each vendor, and they have the advantage of being able to implement functions that cannot be achieved with UWP applications. Therefore, when implementing a UWP application, it is often considered to launch a desktop application from the UWP application and have the desktop application handle some of the functions. However, UWP applications are a new type of application that is installed only from a dedicated site called the Windows Store. Furthermore, they are protected by a high level of security, and are characterized by the fact that access is only permitted within the package containing the UWP application. As a result, UWP applications cannot access external desktop applications, and there is a problem that desktop applications cannot be launched in the usual way. To solve this problem, the aforementioned desktop bridge mechanism is provided. However, the desktop bridge mechanism has limitations, such as only being able to launch one desktop application at a time. Therefore, it is common to launch a launcher application (hereinafter referred to as "launcher application") as a desktop application, and then launch a desktop application with a different main function from the launcher application from the launcher application.

[0010] As mentioned above, generally, when the display areas of an existing window and a newly displayed window overlap, the operating system (hereinafter referred to as "OS") controls the display so that the newly displayed window is displayed on top of the existing window. However, when using the desktop bridge mechanism, windows displayed via a desktop application launched by a UWP application may be displayed in an active state or an inactive state due to OS constraints. If a window displayed via a desktop application is displayed in an inactive state, the window that will perform the subsequent processing will be displayed below a window that is no longer needed for subsequent processing, which reduces user convenience. Therefore, in this embodiment, when a UWP application that displays a window launches a desktop application using the desktop bridge mechanism, and the desktop application displays a new window, the unnecessary UWP application window is changed to a hidden state. Also, if the UWP application window is changed to a hidden state while other inactive windows exist on the display device, the topmost window among the inactive windows becomes the active window. In this case, if the desktop application is launched in an inactive state, the desktop application window may be displayed below the newly active window. The UWP app then receives a notification from the desktop app indicating that the desktop app's window has finished displaying. Upon confirming receipt of the notification, the UWP app changes its window to a hidden state. This ensures that even if the desktop app's window is displayed in an inactive state, it will appear below the UWP app's window. Subsequently, when the UWP app's window is hidden, the desktop app's window will be displayed in front of all other windows. This embodiment will be described in detail below. The following describes in detail, with reference to the drawings, embodiments for carrying out the present invention. However, the components described in this embodiment are merely illustrative and are not intended to limit the scope of this invention to them alone.

[0011] <Embodiment 1> System Configuration The system configuration in this embodiment will be explained using Figure 1. The PC 101 has a CPU 102, ROM 103, RAM 106, external storage device 107, display device 108, and input interface 109. ROM103 stores UWP app 104, desktop app 105 launched from UWP app 104 via the desktop bridge, and other apps (such as Explorer and browser). Furthermore, UWP app 104 and desktop app 105 are bundled within the same UWP package, and only desktop app 105 can be launched from UWP app 104 via the desktop bridge. The external storage device 107 stores the OS and various other data. The CPU 102 reads the UWP app 104 and desktop app 105 from the ROM 103 into the RAM 106 and executes them, thereby running the processing programmed for each application. At the same time, the UWP app 104 and desktop app 105 each display their respective graphical user interfaces (hereinafter referred to as "GUI") as windows on the display device 108. On the display device 108, window control is handled by the OS. When displayed in an active state, it is shown in front of all windows displayed on the display device 108. On the other hand, when displayed in an inactive state, it is shown one window behind the active window, i.e., in front of all inactive windows. Also, when a UWP app 104 launches a desktop app 105, the displayed window may be launched in an active state or an inactive state. Furthermore, if the OS determines that the current active window is being operated by the user, the newly displayed window will be launched in an inactive state. The input interface 109 is an interface that accepts input from the user and enables the input of various data and instructions for actions.

[0012] Incidentally, the PC101 generally supports multitasking and can run multiple applications simultaneously. In an information processing system, launched applications are managed by the OS in units called processes. Furthermore, applications with a GUI can display their GUI on a display device such as a monitor. In this case, the GUI of each application is managed by the OS in units called windows. Generally, when multiple applications with GUIs are run simultaneously, multiple windows are displayed on the display device at the same time. In such systems, an overlap format is generally adopted, where windows are displayed on top of each other. In the overlap format, the window state in which a window is displayed at the forefront of all windows and is ready to accept user input is called the active state, and the window in the active state is called the active window. On the other hand, windows other than the active window are called inactive windows. To make an inactive window active, for example, the user can click on the inactive window with the mouse. Also, a window launched in the inactive state has the characteristic of being displayed one position behind the active window, that is, at the forefront of all inactive windows. In a system that adopts an overlap format, there is the convenience that while checking one window, another window can be operated. On the other hand, there is also a problem that a newly displayed window is displayed above an existing window, which hinders user operations.

[0013] Consider a case where a first application with a GUI (hereinafter referred to as the "launch application") launches a second application with another GUI (hereinafter referred to as the "processing application") and subsequent processing is performed by the processing application. Generally, the window of the newly launched application becomes the active window. Therefore, when the display areas of an existing window and a newly displayed window overlap, the OS controls so that the newly displayed window is displayed above the existing window. Therefore, there is a possibility that the window of the launch application is hidden by the window of the processing application, but since the launch application becomes unnecessary in subsequent processing, no problem occurs. On the other hand, consider a case where a UWP application supported by Windows 10 is used as the launch application and a desktop application is launched as the processing application. Depending on OS restrictions, the window displayed by the desktop application launched by the UWP application may be displayed in an active state or a non-active state. First, consider the case where the window of the desktop application is launched in a non-active state and is displayed below the window of the UWP application. In this case, the window of the desktop application for performing subsequent processing is displayed below the window of the UWP application, which becomes unnecessary in subsequent processing, resulting in a decrease in user convenience. Also, if the window of the desktop application is completely hidden by the window of the UWP application, the user may not notice the launch of the desktop application. In addition, it is difficult for the window control technology described in the OS or Patent Document 1 to flexibly change the control method according to the specifications of each application, such as when the launch application launches the processing application and subsequent processing is performed by the processing application. The present invention discloses a technology for solving this problem.

[0014] The process of a UWP app launching a desktop app. 1. If no other windows exist Next, using FIGS. 2 to 4, the process when the UWP app 104 starts the desktop app 105 in an environment where there are no windows other than the UWP app 104 and the desktop app 105 on the display device 108 of the present embodiment will be described. In the present embodiment, it is assumed that the UWP app 104 has a function of managing a printer, and the desktop app 105 has a function of registering a printer. That is, the UWP app 104 starts the desktop app 105 to register a printer. Note that the function of the UWP app 104 is not limited to the function of managing a printer, and it may have a function of starting the desktop app 105 by using a desktop bridge. Similarly, the function of the desktop app 105 is not limited to the function of registering a printer. a. Processing of UWP app FIG. 2 is a flowchart showing an example of the process in the present embodiment. FIG. 3 is a schematic diagram of the display state of the display device 108 in the present embodiment, and FIG. 3(a) shows a state where no window is displayed on the display device 108 before the start of the process of FIG. 2. FIG. 4 is an example of the display state of the UWP app 104 in the present embodiment. In S201, based on the fact that the UWP app 104 has been started and executed by the user using the input interface 109 of the PC 101, the process of the flowchart in FIG. 2 starts. For example, the UWP app 104 listed in the start menu is started when selected by the user. In the subsequent S202, the UWP app 104 displays the window of the UWP app 104 on the display device 108. At this time, the display device 108 is in a state where only the window 301 of the UWP app 104 as shown in FIG. 3(b) is displayed. In the subsequent S203, the UWP app 104 displays window 301 and then enters an input-receiving state. Figure 4(a) shows an example of the content displayed by window 301 of the UWP app 104 when it is in an input-receiving state. Window 301 of the UWP app 104 has a [Register] button 401 and a "Close" button 402. Note that window 301 of the UWP app 104 may have buttons other than the [Register] button 401 and the [Close] button 402. When the user presses the [Register] button 401, the UWP app 104 receives the input in S203. In S204, UWP app 104 checks if the received input is information indicating a command to launch a desktop app. Next, in S205, the UWP app 104 determines whether or not to launch the desktop app. If the UWP app 104 determines that it is a command to launch the desktop app (Yes in S205), it proceeds to S206. At S206, the UWP app 104 enters a state where it is in the process of launching a desktop application, and displays a processing screen in window 301. Figure 4(b) shows an example of the processing screen displayed in window 301 (a processing screen with a progress ring). While the processing screen is displayed, the UWP app 104 is unable to accept input from the [Close] button 402. Next, on S207, UWP app 104 launches desktop app 105 using the desktop bridge mechanism. Then, UWP app 104 returns processing to S203 and returns to the input-receiving state.

[0015] On the other hand, if the user presses a button other than the [Register] button 401 while S203 is in input acceptance state, the UWP app 104 determines in S205 that it is not a command to launch a desktop app. If the UWP app 104 determines that it is not a command to launch a desktop app (i.e., No in S205), it proceeds to S208. On S208, check if the UWP app 104 has pressed the [Close] button 402. In S209, the UWP app 104 determines whether the "Close" button 402 has been pressed. If the UWP app 104 determines that the "Close" button 402 has been pressed (i.e., Yes in S209), it proceeds to S212. On S212, UWP app 104 changes window 301 to hide. Then, at S213, the UWP app 104 terminates the processing of this flowchart. In this embodiment, when the processing screen is displayed at S206, the system does not accept input from the [Close] button 402. However, any input that changes the window 301 to a hidden state may be used. For example, the [Minimize] button may be used as an input to hide the window. On the other hand, if UWP app 104 receives input other than pressing the [Close] button 402 at S203, at S209, it is determined that UWP app 104 should not terminate its processing (if the result at S209 is No), and processing proceeds to S210. In the following S210, the UWP app 104 checks whether it has received a notification on the display device 108 indicating that window 302 of the desktop app 105 has been displayed. When the UWP app 104 launches the desktop app 105 using the desktop bridge mechanism, the UWP app 104 cannot obtain the process handle or window handle of the desktop app 105. As mentioned earlier, this is an OS limitation due to the high level of security protection the UWP app 104 is protected by. In other words, the UWP app 104 cannot know the launch status of the desktop app 105 or the display status of window 302. Therefore, the UWP app 104 checks whether window 302 of the desktop app 105 has been displayed on the display device 108 by receiving a notification from the desktop app 105. The method of notification will be described later in S253. In the following S211, the UWP app 104 determines whether it has received a notification that window 302 of the desktop app 105 has been displayed on the display device 108. If it determines that window 302 of the desktop app 105 has not received a notification (No in S211), the process returns to S203 and the input acceptance state is restored. On the other hand, if it determines that window 302 of the desktop app 105 has been displayed on the display device 108 (Yes in S211), the process proceeds to S212. In the following step S212, window 301 is hidden, and in S213, UWP app 104 terminates the processing of this flowchart.

[0016] b. Processing of desktop applications (Screen transition) Figure 3(c) or Figure 3(d) shows the state at the time when the UWP app 104 receives a notification from the desktop app 105 via S211, that is, the state in which the window 302 of the desktop app 105 is displayed on the display device 108. Of these, Figure 3(c) shows the case where window 302 of the desktop application 105 is displayed in an active state on top of window 301 of the UWP application 104. On the other hand, Figure 3(d) shows the case where window 302 of the desktop application 105 is displayed in an inactive state below window 301 of the UWP application 104. Furthermore, Figure 3(e) shows the state in which window 301 of the UWP app 104 has been hidden by the processing of S212, from the state in Figure 3(c) or Figure 3(d). When window 301 is hidden, window 302 is displayed at the forefront of the display device 108, regardless of whether window 302 was launched in an active state or not.

[0017] (Desktop application flow) Next, we will explain the processing of desktop application 105, which is launched by UWP application 104 via the desktop bridge mechanism. When UWP application 104 launches desktop application 105 at S207, processing from S251 onwards begins. First, on S251, desktop app 105 is launched by UWP app 104. In the subsequent S252, the desktop application 105 displays its window 302 on the display device 108. At this time, the display state of the display device 108 will be as shown in Figure 3(c) or Figure 3(d) as described above. Next, in S253, the desktop application 105 launches the UWP application 104 via protocol launch, notifying (sending) information to the UWP application 104 that window 302 has been displayed on the display device 108. Protocol launch is a mechanism that launches a corresponding program or application according to a specified protocol, and each UWP application can define any protocol individually. A protocol refers to an agreement for communication between computers, such as the HyperText Transfer Protocol (hereinafter referred to as "HTTP") used when a server and a client communicate. Browsers such as Internet Explorer® and Microsoft Edge® are associated with the HTTP protocol, and specifying the HTTP protocol in protocol launch allows a browser to be launched. In other words, by defining individual protocols in the UWP application 104, the desktop application 105 can launch the UWP application 104 by specifying the defined protocol. In addition, it is possible to specify parameters along with the protocol in protocol launch. Therefore, by pre-defining processing in the UWP app 104 according to arbitrary parameters, the UWP app 104 can execute the defined processing triggered by a notification from the desktop app 105. That is, the desktop app 105 starts the UWP app 104 via protocol invocation in S253 by specifying the pre-defined parameters. The UWP app 104 then receives the parameters specified by the protocol invocation in S203 and determines in S211 that the window 302 of the desktop app 105 has been displayed. Subsequently, in S212, processing is executed to change the window 301 to hidden. In this embodiment, notification is made from the desktop app 105 to the UWP app 104 via protocol invocation, but this is not the only way. For example, inter-process communication between the UWP app 104 and the desktop app 105 could be established using a mechanism called a pipe, and notification could be made using this method. In the processing in S253, the desktop app 105 notifies the UWP app 104 that window 302 has been displayed, and then proceeds to S254. In S254, the desktop application 105 enters an arbitrary input-receiving state. Upon receiving input, the desktop application 105 proceeds to S255. In S255, the desktop application 105 determines whether the input information received in S254 is a command to terminate the desktop application 105. If the desktop application 105 determines that it is a command to terminate the desktop application 105 (Yes in S255), it proceeds to S256. On the other hand, if it determines that it is not a command to terminate the desktop application 105, i.e., to continue processing (No in S255), it returns to the input reception state in S254. In S256, desktop application 105 changes window 302 to hidden. Then, at S257, desktop application 105 terminates processing of this flowchart.

[0018] In this embodiment, the system is set to an arbitrary input acceptance state in S254, but it is not limited to this. For example, the desktop application 105 may automatically process without accepting arbitrary input, and then hide the window 302 and terminate the process when the processing is complete. Also, in this embodiment, if the UWP application 104 determines in S211 that the window 302 of the desktop application 105 has been displayed on the display device 108 (if the answer in S211 is Yes), it changes the window 301 to hidden in S212 and terminates the process in S213. Alternatively, the system may return to the input acceptance state in S203 after processing in S212. In this case, the UWP application 104 can be launched by protocol invocation from the desktop application 105, or the window 302 can be displayed again by user operations such as maximizing. Also, in this embodiment, the input was checked in the order of S204, S208, and S210, but it is not limited to this order and can be done in any order.

[0019] 2. If other windows exist Next, using Figures 2 and 5, we will explain the process by which the UWP app 104 launches the desktop app 105 in an environment where windows other than the UWP app 104 and the desktop app 105 exist on the display device 108 of this embodiment. (Screen transition) Figure 5 shows a schematic diagram of each timing in this embodiment in an environment where the Explorer window 501 is displayed on the display device 108 as an example of a window other than the UWP app 104 and the desktop app 105. In an environment where the Explorer window 501 exists, if the desktop app 105 window 302 is displayed inactive by the desktop bridge mechanism, there was a possibility that window 302 would be launched below window 501. Even in this case, according to this embodiment, it is possible to display the desktop app 105 window 302 at the forefront of the display device 108. Specifically, Figure 5(a) shows the state where the Explorer window 501 is displayed on the display device 108 before the start of processing from S201 onwards. Figure 5(b) shows the state in which UWP app 104 displays window 301 on S202, compared to the state in Figure 5(a). Figure 5(c) or Figure 5(d) shows the state from Figure 5(b) where the UWP app 104 launches the desktop app 105 in S207, and the desktop app 105 displays window 302 in S252. In Figure 5(c), window 302 of the desktop app 105 is displayed in an active state, and it is superimposed on window 301 of the UWP app 104. On the other hand, Figure 5(d) shows window 302 of the desktop app 105 in an inactive state, and it is hidden by window 301 of the UWP app 104. However, in Figure 5(d), even though window 302 of the desktop app 105 is launched in an inactive state, it is displayed in front of window 501 of the Explorer, which is also an inactive window. The subsequent processing in S212 changes window 301 of the UWP app 104 to hidden. In either case, as shown in Figure 5(c) or Figure 5(d), the state in which the window 302 of the desktop application 105 is displayed on top of the display device 108 can be achieved.

[0020] 3. When another window becomes active Next, using Figures 2, 3, and 6, we will explain what happens when a window other than UWP app 104 or desktop app 105 becomes active, such as Explorer, while UWP app 104 is launching desktop app 105. Specifically, in S203 of Figure 2, after the user presses the [Register] button 401, it takes time for the desktop application 105 to start, and before the desktop application 105 starts, the Explorer window 501 becomes active due to user operation on the input interface 109. This case will be explained below. In this case, since the user is interacting with window 501, it is desirable that window 501 remain active even if the desktop application 105 subsequently displays window 302. Figure 6(a) shows the state in Figure 3(b) after the Explorer window 501 becomes active. In this state, when the desktop application 105 displays window 302 in S252, the OS determines that the Explorer window 501 is being operated on, and as shown in Figure 6(b), window 302 is displayed hidden behind window 501. Subsequently, in the S212 process, the UWP application 104 hides window 301. However, this does not affect the order in which windows 302 and 501 are located, and as shown in Figure 6(c), the Explorer window 501, which the user is currently operating on, remains active. Therefore, it can be launched without interfering with the user's operation. In this embodiment, we have used the example of the case where the Explorer window 501 is made active in the environment shown in Figure 3(b), but we are not limited to this. For example, while the UWP app 104 is taking time to start the desktop app 105, the input interface 109 may display a new Explorer window 501. Also, in this embodiment, we have given Explorer as an example of an app that displays windows other than the UWP app 104 and the desktop app 105, but we are not limited to this, and any other app that can display windows may be used. Furthermore, in this embodiment, we have given an environment in which only one Explorer window 501 exists as a window other than the UWP app 104 and the desktop app 105, but we are not limited to this, and an environment in which multiple windows exist may also be used. In the above-described embodiment, the UWP app 104 on PC 101 launches the desktop app 105 using the desktop bridge mechanism. In this case, regardless of whether the window 301 of the desktop app 105 is launched in an active state or not, the window 301 can be displayed in the foreground in an active state.

[0021] <Embodiment 2> Embodiment 1 described an example where only one desktop application is launched, due to the limitation that only one desktop application can be launched in the desktop bridge mechanism. Embodiment 2 describes an example where a launcher application is launched as a desktop application via the desktop bridge, and a desktop application with a different main function from the launcher application is launched from the launcher application.

[0022] The system configuration in Embodiment 2 will be explained using Figure 7. As shown in Figure 7, the ROM 103 of the PC 101 in this embodiment stores a launcher application 701 instead of the desktop application 105 in the system configuration of Embodiment 1 shown in Figure 1. In addition, the ROM 103 stores an external application 702 outside of the UWP package, which includes the UWP application 104 and the launcher application 701. The launcher application 701 is a desktop application launched from the UWP application 104 using the desktop bridge mechanism, and the external application 702 is an application launched from the launcher application 701. Therefore, in this embodiment, the UWP application 104 launches the launcher application 701, and the launched launcher application 701 launches the external application 702. Here, the external application 702 is not limited to a desktop application, and may be a UWP application, for example.

[0023] Next, using Figures 3, 5, and 8, we will explain the process when the UWP app 104 launches the launcher app 701, and the launcher app 701 launches the external app 702. Note that S801~S803, S806, S812, S813, and S852~S856 are the same as S201~S203, S206, S212, S213, and S252~S256 respectively, so their explanations will be omitted. Also, S804, S805, and S807 are the same as the processes in S204, S205, and S207, but with the desktop app 105 replaced by the launcher app 701. Furthermore, S810, S811, S851, and S857 are the same as the processes in S210, S211, S251, and S257, but with the desktop app 105 replaced by the external app 702. Furthermore, in the following discussion, the window 302 of the desktop application 105 in Figures 3 and 5 will be treated as being replaced with the window of the external application 702.

[0024] This document explains the process of launcher app 701, which is launched by UWP app 104 via the desktop bridge mechanism. UWP app 104 launches launcher app 701 on S807, which initiates processing from S831 onwards. On S831, launcher app 701 is launched by UWP app 104. In S832, launcher app 701 launches external app 702. At S833, the launcher application 701 terminates processing. At this time, the display state of the display device 108 will be as shown in Figure 3(c), Figure 3(d), Figure 5(c), or Figure 5(d). Then, the external application 702 launched in S832 performs the processing from S851 onwards, and the UWP application performs the processing from S803 onwards. As a result, the window 302 of the external application 702 is displayed as the active window at the forefront, as shown in Figure 3(e) or Figure 4(e). In this embodiment, the external application 702 notifies the UWP application 104 in S853 that it has displayed window 302, but the launcher application 701 may also notify the UWP application 104. In this case, if the external application 702 is a desktop application, the launcher application can obtain the window handle and understand the window display status of the external application 702. On the other hand, even if the external application 702 is a UWP application, it is possible to establish inter-process communication between the launcher application 701 and the external application 702 using a mechanism such as a pipe, and receive whether the window 302 of the external application 702 has been displayed. In this embodiment, the launcher application 701 is configured without a GUI, but it is not limited to this. Furthermore, while the configuration is limited to only one external application 702 launched from the launcher application 701, this is not limited to that. When multiple windows of the launcher application 701 or the external application 702 are displayed, the UWP application 104 can be notified that the display of all windows is complete, allowing the desired window to be brought to the foreground.

[0025] As described above, according to this embodiment, even when the UWP app 104 on PC 101 launches the launcher app 701 using the desktop bridge mechanism, the same effects as in Embodiment 1 can be obtained. Furthermore, in Embodiment 2, regardless of whether the window of the external app 702 is launched in an active state or not, it becomes possible to display the window of the external app 702 in the foreground in an active state.

[0026] (Other embodiments) The embodiments described above can also be realized by performing the following process: supplying software (programs) that realize the functions of the embodiments described above to a system or device via a network or various storage media, and having the computer (CPU, MPU, etc.) of that system or device read and execute the program. The program may be executed on a single computer or executed in conjunction with multiple computers. Furthermore, it is not necessary to realize all of the above processes in software; some or all of the processes may be realized in hardware such as ASICs. Also, the CPU is not limited to one CPU that performs all the processing; multiple CPUs may perform the processing in coordination as appropriate. Furthermore, the functionality of the aforementioned embodiment is not only realized by the execution of program code read by the computer. It also includes cases where the operating system running on the computer performs some or all of the actual processing based on the instructions of that program code, and the functionality of the aforementioned embodiment is realized through that processing. This embodiment includes the following configurations, methods, and programs. (Composition 1) An information processing apparatus having display means for displaying a plurality of windows, including a first window of a first application and a second window of a second application launched by the first application, The second application includes a notification means for sending a notification to the first application indicating that the second window has been displayed, The first application, upon receiving the notification, includes display control means for hiding the first window. An information processing device characterized by comprising: (Configuration 2) The information processing device according to claim 1, characterized in that the first application is a Universal Windows Platform (UWP) application. (Composition 3) The information processing device according to claim 2, characterized in that the first application launches the second application via a desktop bridge. (Composition 4) The information processing apparatus according to claim 3, characterized in that the second application is a desktop application. (Composition 5) The information processing apparatus according to claim 4, characterized in that the desktop application is a launcher application. (Composition 6) The information processing device according to claim 3, characterized in that the second application is a Universal Windows Platform (UWP) application. (Composition 7) The display control means controls the first window so that it cannot be closed while the first application is running the second application. The information processing apparatus according to claim 1. (Composition 8) The information processing device according to claim 1, characterized in that the notification indicating that the second window has been displayed is parameter information for when the second application protocol-starts the first application. (Composition 9) The information processing device according to claim 1, characterized in that a notification indicating that the second window has been displayed is sent to the first application by inter-process communication between the second application and the first application. (Composition 10) An information processing apparatus having display means for displaying a plurality of windows, including the first window of a first application, the second window of a second application launched by the first application, and the third window of a third application launched by the second application, wherein The third application includes notification means for sending a notification to the first application indicating that the third window has been displayed, The first application, upon receiving the notification, includes display control means for hiding the first window. An information processing device characterized by comprising: (Method 1) A control method for an information processing device having display means for displaying a plurality of windows, including a first window of a first application and a second window of a second application launched by the first application, The second application has a notification step of sending a notification to the first application indicating that the second window has been displayed. The first application, upon receiving the notification, performs a display control step of hiding the first window. A control method characterized by having the following features. (Program 1) A program for causing a computer to function as each means of the information processing apparatus described in claim 1. (Method 2) A control method for an information processing device having display means for displaying a plurality of windows, including the first window of a first application, the second window of a second application launched by the first application, and the third window of a third application launched by the second application, wherein the display means displays a plurality of windows on top of each other. The third application includes a notification step of sending a notification to the first application indicating that the third window has been displayed, The first application, upon receiving the notification, performs a display control step of hiding the first window. A control method characterized by having the following features. (Program 2) A program for causing a computer to function as each means of the information processing apparatus described in claim 10. [Explanation of Symbols]

[0027] 102 CPU 103 ROM 104 UWP apps 105 Desktop Apps

Claims

1. An information processing apparatus having display means for displaying a plurality of windows, including a first window of a first application and a second window of a second application launched by the first application, The second application includes notification means for sending a notification to the first application indicating that the second window has been displayed, The first application includes a display control means that hides the first window when it receives the notification. An information processing device characterized by comprising:

2. The information processing apparatus according to claim 1, characterized in that the first application is a Universal Windows Platform (UWP) application.

3. The information processing apparatus according to claim 2, characterized in that the first application launches the second application via a desktop bridge.

4. The information processing apparatus according to claim 3, characterized in that the second application is a desktop application.

5. The information processing apparatus according to claim 4, characterized in that the desktop application is a launcher application.

6. The information processing apparatus according to claim 3, characterized in that the second application is a Universal Windows Platform (UWP) application.

7. The display control means controls the first window so that it cannot be closed while the first application is running the second application. The information processing apparatus according to feature 1.

8. The information processing device according to claim 1, characterized in that the notification indicating that the second window has been displayed is parameter information for when the second application protocol-starts the first application.

9. The information processing apparatus according to claim 1, characterized in that a notification indicating that the second window has been displayed is transmitted to the first application by inter-process communication between the second application and the first application.

10. An information processing apparatus having display means for displaying a plurality of windows on top of each other, including a first window of a first application, a second window of a second application launched by the first application, and a third window of a third application launched by the second application, The third application includes notification means for sending a notification to the first application indicating that the third window has been displayed, The first application includes a display control means that hides the first window when it receives the notification. An information processing device characterized by comprising:

11. A control method for an information processing apparatus having display means for displaying a plurality of windows, including a first window of a first application and a second window of a second application launched by the first application, The second application has a notification step of sending a notification to the first application indicating that the second window has been displayed. The first application, upon receiving the notification, performs a display control step of hiding the first window. A control method characterized by having the following features.

12. A program for causing a computer to function as each means of the information processing apparatus described in claim 1.

13. A control method for an information processing apparatus having display means for displaying a plurality of windows, including a first window of a first application, a second window of a second application launched by the first application, and a third window of a third application launched by the second application, wherein the display means displays a plurality of windows on top of each other. The third application includes a notification step of sending a notification to the first application indicating that the third window has been displayed, The first application, upon receiving the notification, performs a display control step of hiding the first window. A control method characterized by having the following features.

14. A program for causing a computer to function as each means of the information processing apparatus described in claim 10.

Images