Local service based terminal window hierarchy control system and method

Abstract

The application discloses a terminal window level control system based on local service, which comprises a webpage service module, a control service module and a terminal module. The terminal module loads and runs a service station webpage program of the webpage service module through an HTTP protocol, and initiates an API interface calling request to the control service module. The control service module generates a window level control instruction based on the request, and the terminal module executes the window level control instruction to realize window control service. The application decouples the window top logic from the main application program, adopts an independent HTTP service for management, and realizes a flexible, reliable and easy-maintained window level scheme.

Description

Technical Field

[0001] This application relates to the field of system window display priority technology, specifically to a terminal window hierarchy control system and method based on local services. Background Technology

[0002] In scenarios where terminal devices provide specific services to users, such as government service stations and self-service terminals, in order to ensure system security and the continuity of user operations, it is usually necessary to ensure that the service program window is always displayed in the foreground to prevent users from accidentally or maliciously accessing the underlying operating system, thereby avoiding security risks such as system configuration tampering and sensitive data leakage.

[0003] Therefore, there is an urgent need for a system that can ensure that the program window is always on top during normal service to prevent users from switching to the system desktop or other applications, while also allowing authorized maintenance personnel to temporarily remove the top restriction when necessary for system maintenance, troubleshooting and other operations. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this application provides a terminal window hierarchy control system based on local services. By decoupling the window-on-top logic from the main application and managing it using an independent HTTP service, a flexible, reliable, and easy-to-maintain window hierarchy scheme is achieved.

[0005] In a first aspect, a terminal window hierarchy control system based on local services is provided, comprising: at least one terminal module, the terminal module including a terminal program, the terminal module being used to load and run the service station web page program corresponding to the terminal program via HTTP protocol, and to initiate an API interface call request to the control service module; The web page service module is used to provide the web page program for the service station; The control service module runs on the network port of the local host. The control service module is used to generate window-level control instructions based on the API interface call request and send the window-level control instructions to the terminal module. The terminal module is further configured to receive the window hierarchy control instructions and execute the window hierarchy control instructions to implement window control services.

[0006] Based on the above implementation scheme, this application completely separates the window-on-top control logic from the main application. That is, the window control service of this application runs independently of the main application and is designed as an independent FastAPI HTTP service. This decoupling design brings the following advantages: remote control is achieved through an HTTP API, supporting dynamic adjustment of the on-top strategy. Modifying the on-top strategy does not require recompiling and deploying the main application; only the Python script needs to be updated, significantly reducing maintenance costs. The main application can use any development language (C#, Java, Electron, etc.) to call the on-top service through the standard HTTP protocol, achieving decoupling of the technology stack. When the main program encounters an exception or crashes, the FastAPI service can still run independently, facilitating the automatic restart of the main program and restoration of the on-top state by the monitoring thread, ensuring high system availability. Furthermore, the FastAPI service can be ported to platforms such as Linux, achieving cross-platform window management.

[0007] In conjunction with the first aspect, in some embodiments of the first aspect, the window control service includes one or more of the following: window search and handle acquisition, window pinning, window unpinning, taskbar display, taskbar hiding, real-time window status monitoring, automatic window startup, automatic window recovery, and log recording.

[0008] In conjunction with the first aspect, in some embodiments of the first aspect, executing the window hierarchy control instructions to implement window control services includes: the terminal module setting up an independent monitoring thread to achieve real-time monitoring of window status; and the terminal module implementing window control services based on the window status. The window state is represented by multiple state flags, including one or more of is_top_enabled, is_closed_by_api, and isNeedTop. is_top_enabled indicates whether the target window exists; is_closed_by_api indicates whether the window was actively closed via API; and isNeedTop indicates whether the window needs to be automatically pinned to the top when it is closed and reopened after being depinned.

[0009] In conjunction with the first aspect, in some embodiments of the first aspect, the terminal module implements window control services based on the window state, including: when is_closed_by_api indicates that the window is actively closed by the API, no automatic restart operation is performed; when is_closed_by_api indicates that the window is not actively closed by the API, the terminal module executes the automatic restart program of the terminal program and keeps the window on top.

[0010] In conjunction with the first aspect, in some embodiments of the first aspect, executing the window hierarchy control instruction to implement window control service includes: the execution module executing the window unpinning control according to the window hierarchy control instruction and the operation and maintenance control instruction, wherein the operation and maintenance control instruction is triggered by performing a first operation and a password verification operation on the service station web page program.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the window-on-top control is achieved by calling the Windows API's SetWindowPos function to set the window hierarchy order.

[0012] In conjunction with the first aspect, in some embodiments of the first aspect, the window control service further includes system startup, wherein the system startup performs initialization operations through the setupConfig function, wherein the initialization operations include window search and handle acquisition, window pinning control, taskbar hiding control, and starting a monitoring thread.

[0013] In conjunction with the first aspect, in some embodiments of the first aspect, executing the window hierarchy control instructions to realize window control services includes linking the window pinning control, the taskbar display, and the taskbar hiding in the window control services, wherein the taskbar is hidden when the window is pinned to the top, and the taskbar is displayed when the window is unpinned to the top.

[0014] In conjunction with the first aspect, in some embodiments of the first aspect, the logging includes recording one or more of the following: timestamp, operation type, execution result, and exception stack information of the window control service.

[0015] Secondly, a terminal window hierarchy control method based on local services is provided, comprising: loading and running a service station web page program corresponding to the terminal program via the HTTP protocol; initiating an API interface call request to a server, wherein the server runs on a network port of the local host; receiving window hierarchy control instructions from the server, wherein the window hierarchy control instructions are generated according to the API interface call request; and executing the window hierarchy control instructions to implement window control services.

[0016] Thirdly, an electronic device is provided, comprising: a memory for storing a computer program; and a processor for executing the computer program to run a terminal window hierarchy control system as described in any one of the first aspects or to implement the terminal window hierarchy control method described in the second aspect. Attached Figure Description

[0017] Figure 1A schematic diagram of the core functional modules of a local service-based terminal window hierarchy control system provided in this application.

[0018] Figure 2 This application provides an architecture diagram of a terminal window hierarchy control system based on local services. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of one embodiment of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0020] Traditional service terminal programs are typically desktop applications developed using languages ​​such as C# and C++, and they embed a web browser component to display the service page of the service terminal program.

[0021] To ensure a service page is always on top, some traditional scenarios directly call operating system APIs (such as Windows' SetWindowPos function) to implement the window-on-top functionality, integrating the top-top control logic within the program. However, this approach results in high coupling between the top-top control logic and the business logic, requiring a complete recompilation and deployment of the entire application to modify the top-top strategy. Furthermore, the top-top control function fails when the main program encounters an exception or crashes, making independent monitoring and recovery mechanisms impossible. In addition, it is difficult to achieve a unified top-top control solution across platforms and languages.

[0022] In other scenarios, system-level group policies or registry configurations are used to restrict user access to system functions such as Task Manager and the desktop by modifying Windows group policies or the registry, indirectly achieving the effect of "locking" programs. However, this method is relatively complex to configure, requires professional system administration knowledge, lacks flexibility, cannot dynamically adjust the top status according to actual needs, and is highly intrusive to the system, potentially affecting the operation of other normal applications. In addition, when maintenance personnel remove the restrictions, they need to restart the system or log out the user, which is cumbersome and affects service continuity.

[0023] In other scenarios, there are third-party window management tools that use third-party window management software (such as AutoHotkey scripts, window pinning tools, etc.) to adjust the window hierarchy of the target program. However, this approach relies on external tools, increasing the complexity of system deployment and maintenance. The stability and security of third-party tools are difficult to guarantee; they lack integration capabilities with business systems and cannot control the pinning state through business logic (such as password verification); and it is difficult to achieve automatic restart and pinning restoration functions after the window is closed.

[0024] In addition, some scenarios employ a full-screen mode locking solution, setting the service program to full-screen mode and disabling system shortcuts such as Alt+Tab and the Win key to prevent users from switching windows. However, this method offers a poor user experience, completely blocking system interaction capabilities. Maintenance personnel need to use physical buttons or external devices to unlock the program, which is inconvenient; it also has poor support for multi-monitor environments and lacks flexible control over the display and hiding of the taskbar.

[0025] In summary, existing technical solutions have significant shortcomings in terms of flexibility, maintainability, security, and business integration capabilities, making it difficult to meet the actual needs of modern public service terminals for hierarchical window management. Therefore, there is an urgent need for a technical solution that can reliably keep the service program window at the top, facilitate flexible control by authorized personnel, and possess good scalability and maintainability.

[0026] Based on the above problems, this application discloses a terminal program window priority display system, which provides a flexible, efficient, reliable and easy-to-maintain solution for window hierarchy management of public service terminals through innovative architecture design and intelligent monitoring mechanism.

[0027] For ease of understanding, the key terms involved in this application are explained below.

[0028] API (Application Programming Interface) FastAPI is a Python web framework for building APIs, based on standard Python type hints.

[0029] Python Web refers to the technology system for web development using the Python language, including the development and deployment of web applications, websites, API services, etc.

[0030] A RESTful API is a Web API designed in accordance with the REST (Representational State Transfer) architectural style. It can be understood as an interface that uses URLs to locate resources and HTTP methods to describe operations.

[0031] See Figure 1 As shown in the figure, this application discloses a terminal window hierarchy control system based on local services, including: At least one terminal module, the terminal module including a terminal program, the terminal module being used to load and run the service station web program corresponding to the terminal program via the HTTP protocol, and to initiate an API interface call request to the control service module; The web page service module is used to provide the web page program for the service station; The control service module runs on the network port of the local host. The control service module is used to generate window-level control instructions based on the API interface call request and send the window-level control instructions to the terminal module. The terminal module is further configured to receive the window hierarchy control instructions and execute the window hierarchy control instructions to implement window control services.

[0032] It can be understood that the control API runs on the network port of the terminal module and provides a RESTful API interface for window hierarchy control based on the HTTP protocol. The control API implements window control services through FastAPI, which runs on the local localhost port. Alternatively, FastAPI can be understood as a control service program providing a RESTful API interface for window placement control. The terminal program in the terminal module then implements window hierarchy control by calling the API via HTTP requests. In this embodiment, implementing the window control service specifically involves adjusting the window display hierarchy of the web application on the terminal device, so that the web application window is placed on top.

[0033] The service station web application can be understood as a web application embedded in a browser within the terminal module, providing a business function interface and an operation and maintenance management portal. For example, an operation and maintenance pop-up can be triggered through a specific interaction method (e.g., continuous clicking of the top area), and after password verification, the window can be invoked to control the service control window's top-position status.

[0034] Based on the above implementation scheme, this application completely separates the window-on-top control logic from the main application. That is, the window control service of this application runs independently of the main application and is designed as an independent FastAPI HTTP service. This decoupling design brings the following advantages: remote control is achieved through an HTTP API, supporting dynamic adjustment of the on-top strategy. Modifying the on-top strategy does not require recompiling and deploying the main application; only the Python script needs to be updated, significantly reducing maintenance costs. The main application can use any development language (C#, Java, Electron, etc.) to call the on-top service through the standard HTTP protocol, achieving decoupling of the technology stack. When the main program encounters an exception or crashes, the FastAPI service can still run independently, facilitating the automatic restart of the main program and restoration of the on-top state by the monitoring thread, ensuring high system availability. Furthermore, the FastAPI service can be ported to platforms such as Linux, achieving cross-platform window management.

[0035] Deploying and maintaining this application is very simple. Specifically, deployment involves installing a Python environment and configuring the FastAPI service to start automatically on boot; no system configuration modifications or third-party tools are required. Maintenance only requires editing the Python script to modify the top-priority policy; the main program does not need to be recompiled. Upgrades are independent of the main application and can be performed by updating the FastAPI service without affecting it.

[0036] This application uses the standard HTTP API interface, which has good cross-platform potential. The FastAPI service can be ported to platforms such as Linux and macOS, requiring only the replacement of the underlying window control API. The application does not need to be modified and still calls the top service via HTTP. It can be extended to support advanced functions such as multi-window management and remote control.

[0037] For example, the window control service can be understood as a local HTTP service developed based on the Python FastAPI framework, running on localhost:8080 port of the server computer, providing a RESTful API interface for window hierarchy control, specifically providing two core API interfaces: Interface 1: POST / setLevel Function: Set the window to be on top or unmounted. Request parameter: {"isTop": true / false} Response: {"code": "0", "message": "Window successfully pinned / unpinned"} This interface accepts a boolean parameter `isTop`, which can invoke a terminal module to perform corresponding operations. It supports automatic conversion of string values ​​"true" / "false" to boolean values, improving interface compatibility.

[0038] Interface 2: POST / moni Function: Browser automation interface (accessibility feature) It is used to implement auxiliary functions such as automatic form filling, and works in conjunction with the window-on-top function.

[0039] Service Configuration: - Enable CORS cross-domain support to allow embedded web pages to call local APIs. - Listening address: 0.0.0.0:8000 (actually mapped to localhost:8080 during deployment) - An asynchronous processing mechanism is used to ensure API response speed.

[0040] In some implementations, window control services may include one or more of the following: window finding and handle acquisition, window pinning, window unpinning, taskbar display, taskbar hiding, real-time window status monitoring, automatic window startup, automatic window recovery, and system startup.

[0041] Specifically, window finding and handle acquisition can be achieved in the following way: the Windows API's EnumWindows function traverses all top-level windows, accurately locates the target window based on the window title, and obtains the window handle (Window Handle, usually abbreviated as HWND).

[0042] For example, the key code logic is as follows: - Use win32gui.EnumWindows to enumerate all visible windows. - Filtering conditions: IsWindow, IsWindowEnabled, IsWindowVisible - Supports fuzzy matching of window titles, improving the success rate of searches.

[0043] Specifically, the control over whether a window is pinned to the top or not pinned to the top can be implemented in the following ways: Call the win32gui.SetWindowPos function to set the window layer: - Top: When set to HWND_TOPMOST, the window will always appear on top of all other windows that are not on top. - Unpin to top: Setting it to HWND_NOTOPMOST restores the window to its normal hierarchy. - Using the SWP_NOMOVE | SWP_NOSIZE flags only changes the layer without affecting the window's position and size.

[0044] In one embodiment of this application, the FastAPI service provides the / setLevel interface, which receives the isTop parameter to control the window's on-top state and supports automatic conversion between boolean and string types; when performing the on-top operation, it calls the Windows API's SetWindowPos function to set the window hierarchy order.

[0045] Specifically, the display and hiding of the taskbar can be controlled in the following ways: Locate the taskbar by searching for the window class name "Shell_TrayWnd", and then call the ShowWindow function to control its display state. - Hide taskbar: SW_HIDE, to prevent users from switching windows via the taskbar. - Display taskbar: SW_SHOW, for the convenience of system administrators. Specifically, real-time monitoring of window status can be achieved in the following ways: In some embodiments, the terminal module may be configured with an independent monitoring thread to enable real-time monitoring of window status, and the terminal module may implement window control services based on the window status.

[0046] For example, a separate monitoring thread (window_monitor_task) can be used to implement real-time monitoring and automatic recovery of the window state.

[0047] The window state is represented by multiple state flags, including one or more of is_top_enabled, is_closed_by_api, and isNeedTop. is_top_enabled indicates whether the target window exists; is_closed_by_api indicates whether the window was actively closed via API; and isNeedTop indicates whether the window needs to be automatically pinned to the top when it is closed and reopened after being depinned.

[0048] The window-level monitoring thread can use multiple status flags to work together to achieve real-time monitoring and intelligent recovery of window status.

[0049] The is_top_enabled flag is used to check if the target window exists; that is, the monitoring thread checks if the target window exists by checking the is_top_enabled flag.

[0050] In some embodiments, when is_closed_by_api indicates that the window is closed actively by the API, no automatic restart operation is performed; when is_closed_by_api indicates that the window is not closed actively by the API, the terminal module executes the automatic restart procedure of the terminal program and puts the window on top.

[0051] Specifically, `is_closed_by_api` can be understood as distinguishing the reason for window closure. The monitoring thread uses the `is_closed_by_api` flag to differentiate the reason for window closure. When it detects that the user manually closed the window, it can automatically restart the program and restore the window to its top position. When it detects that the API actively closed the window, it does not perform an automatic restart. `isNeedTop` is used to implement automatic recovery after canceling the top position. Specifically, when an operations and maintenance personnel cancel the top position and close the window, the system records this state. When the window is manually reopened, the monitoring thread automatically detects and restores the top position.

[0052] In one embodiment of this application, the monitoring thread can run in daemon mode and exit with the main process to avoid generating zombie processes; the monitoring cycle is 2 seconds, which reduces system resource consumption while ensuring real-time performance.

[0053] Based on the above implementation scheme, this invention innovatively constructs a window monitoring mechanism based on the collaborative operation of multiple status flags. This mechanism can accurately distinguish the reason for window closure (e.g., manual closure by the user vs. active closure by the API) and execute corresponding recovery strategies according to different scenarios, avoiding the "one-size-fits-all" approach in traditional solutions. Based on this implementation scheme, the window status can be confirmed through the monitoring mechanism, thereby helping to ensure that the window automatically restarts and returns to the top position after abnormal closure.

[0054] The FastAPI service and monitoring thread in this application have extremely low resource consumption. The monitoring thread performs a check every 2 seconds, with an average CPU usage of <0.1%. Furthermore, it relies solely on local localhost communication and has no external network traffic.

[0055] For example, the monitoring logic is as follows: - Check if the target window exists every 2 seconds. - When is_top_enabled=True: * Window exists: Ensure the window remains on top and the taskbar remains hidden. * Window does not exist: Check if it was closed actively by the API (using the is_closed_by_api flag). - Non-API shutdown (user-manual shutdown): Immediately restart the program and pin it to the top. - API disabled: Will not restart automatically; requires manual intervention from operations personnel. - When is_top_enabled=False: * Window exists: Does not force it to stay on top, but monitors its state. * After the window is closed and reopened: Setting the isNeedTop flag will automatically restore it to the top position. Key state variables: - monitor_running: Controls the running status of the monitoring thread. - is_top_enabled: Global top-enabled switch, controlled by the API interface. - is_closed_by_api: Indicates whether the window was closed actively via API. - isNeedTop: Indicates whether the window should be automatically pinned to the top when it is closed and reopened after being depinned.

[0056] Based on the above implementation scheme, a Python daemon thread is used to continuously monitor the window state. This thread runs independently of the main application, so the monitoring function can still work normally even if the main program encounters an exception. In addition, the monitoring thread performs a check every 2 seconds, which ensures real-time performance while avoiding excessive system resource consumption.

[0057] Specifically, automatic window recovery can be achieved in the following ways: For example, a smart recovery algorithm for windows that have been abnormally closed: The monitoring thread determines the reason for window closure using the `is_closed_by_api` flag. - When the flag is false (user manually closes), the program will immediately and automatically restart and return to its current state. - When the flag is true (API actively closed), it will not restart automatically and will wait for manual intervention by operations and maintenance personnel. Based on this implementation plan, this intelligent judgment mechanism ensures that the system can guarantee security without affecting normal operation and maintenance.

[0058] For example, disable automatic restoration after pinning: The `isNeedTop` flag enables complete workflow control of "unpinning - closing the window - reopening - automatically restoring pinning". When maintenance personnel unpin the window and close it via API, the system records this state; when the window is manually reopened, the monitoring thread automatically detects and restores the pinning state without manual intervention.

[0059] Specifically, automatic window startup can be achieved in the following ways: The `execute_program` function launches the target program and keeps the window on top. - Supports wildcard matching of executable filenames (e.g., "Desheng Digital Human Client*.exe") - Wait 2 seconds after launching the program to ensure the window is fully loaded. - Automatically find new windows and set them to be on top. - Record the program path to a global variable for subsequent automatic restart.

[0060] Specifically, system startup, also known as system initialization, can be achieved in the following ways: Implement automatic startup of the FastAPI service at system boot using the following methods: - Windows: Create a startup script (start_service.bat), place it in the Startup folder, or register it as a Windows service. - Execute script: Run uvicorn to run FastAPI applications - Configured to run in the background, without displaying the console window.

[0061] In one embodiment of this application, the FastAPI service runs automatically when the system starts, and performs initialization operations through the setupConfig function, including checking the target window, setting it to be on top, hiding the taskbar, and starting the monitoring thread.

[0062] In some implementations, the window pinning control can be linked to the display / hiding of the system taskbar; the taskbar is hidden when the window is pinned and displayed when it is unpinned.

[0063] Specifically, the linkage mechanism between pinning a window to the top and showing / hiding the system taskbar is as follows: when pinning a window to the top, the taskbar is hidden to prevent users from switching windows via the taskbar; when unpinning a window to the top, the taskbar is displayed to facilitate system operation for maintenance personnel.

[0064] Based on the above implementation plan, this linkage design enhances the effectiveness of window locking while ensuring the convenience of operation and maintenance.

[0065] In some implementations, the window control service may also include logging. Based on this implementation, the logging is more comprehensive, and detailed logging facilitates troubleshooting and auditing.

[0066] For example, all critical operations are logged to the log file (logs / log_YYYYMMDD.txt): - Record timestamp, operation type, and execution result - Record exception stack information to facilitate troubleshooting. - Split log files by date for easier management.

[0067] Based on the above solutions, these logs can provide important information for troubleshooting, security auditing, and system optimization.

[0068] Based on the above window control services, system initialization can be achieved through the setupConfig function. The following initialization steps are performed during system startup: 1. Check if the target window exists; if not, start the program. 2. Set the window to be on top. 3. Hide the system taskbar 4. Start the monitoring thread (daemon thread, which exits with the main process). 5. Reset the is_closed_by_api flag to ensure the monitoring mechanism is working properly.

[0069] In some embodiments, executing the window hierarchy control instructions to implement window control services includes: the execution module executing the window unpinning control according to the window hierarchy control instructions and the operation and maintenance control instructions, wherein the operation and maintenance control instructions are triggered by performing a first operation and a password verification operation on the service station web page program.

[0070] Specifically, operation and maintenance control can be achieved in the following ways: For example, the complete steps for operations and maintenance personnel to unpin a device from the top of their chat list: 1. Click repeatedly (e.g., 5 times) at the top of the service station web application to trigger a hidden maintenance pop-up window. 2. Enter the internal operations and maintenance password for authentication. 3. Click the "Unpin" button. The frontend calls the FastAPI's / setLevel interface, passing the parameter {"isTop":false}. 4. The FastAPI service performs the following operations: - Set the global variable is_top_enabled=False - Call SetWindowPos to cancel the window being on top. - Use ShowWindow to display the taskbar - Set the is_closed_by_api=True flag - Send a WM_CLOSE message to close the window 5. If the monitoring thread detects that is_closed_by_api=True, the program will not be restarted automatically. 6. After completing system maintenance, the operations and maintenance personnel should manually start the program. 7. When the monitoring thread detects that the window has reappeared, it automatically restores the window to the top position based on the isNeedTop flag.

[0071] Based on the above implementation plan, operations and maintenance personnel can implement authorization control through password verification and API calls to prevent unauthorized operations.

[0072] Specifically, password-based hierarchical authorization control enables the implementation of hidden maintenance pop-ups on the web front end (e.g., triggered by repeated clicks on the top area). Combined with the password verification mechanism, this ensures that only authorized maintenance personnel can access the window control API. This dual protection mechanism of "hidden entry point + password verification" effectively prevents accidental or malicious operations by ordinary users.

[0073] This application adopts a three-layer security mechanism of "hidden entry point + password verification + API call": The first layer: the operation and maintenance entry point is hidden in the normal interface and can only be triggered by clicking the top area repeatedly, making it difficult for ordinary users to find; the second layer: after the operation and maintenance pop-up window pops up, an internal password needs to be entered, and only authorized personnel know the password; the third layer: only after the password verification is successful can the / setLevel interface of FastAPI be called, and the interface itself can also be configured with access control.

[0074] Based on the above implementation methods, this application innovatively designs an intelligent monitoring mechanism based on the collaborative work of multiple state flags. This mechanism can accurately distinguish the reasons for window closure and execute corresponding strategies. When a user manually closes the window: the monitoring thread immediately detects that is_closed_by_api=false, automatically restarts the program, and restores it to the top state. The entire process is completed within 3 seconds, and the user is almost unaware of it. When maintenance personnel close the window via API: the monitoring thread detects that is_closed_by_api=true, does not execute an automatic restart, and avoids conflicts with maintenance operations. When the program is manually started after maintenance is completed: the monitoring thread detects that the window has reappeared and automatically restores it to the top state based on the isNeedTop flag, without manual intervention.

[0075] This application also provides a terminal window hierarchy control method based on local services, including: S100 loads and runs the service station web page program corresponding to the terminal program via the HTTP protocol; S200, Initiate an API interface call request to the server, wherein the server runs on the network port of the local host; S300, receive window hierarchy control instructions from the server, wherein the window hierarchy control instructions are generated based on the API interface call request; S400, execute the window hierarchy control instructions to implement window control services. Figure 2 This application provides an architecture diagram of a terminal window hierarchy control system based on local services. In some embodiments, this local service-based terminal window hierarchy control system may specifically include the following steps: Start the FastAPI window control service and listen on the local port; Initialize system configuration, check target window and set it to be on top; Start a separate monitoring thread to monitor the window status in real time; When it is necessary to unpin the device, call the / setLevel interface through the web frontend, passing the parameter isTop=false; The FastAPI service executes the unpinning operation, sets the status flag, and closes the window. The monitoring thread detected the API shutdown flag and did not perform an automatic restart. The maintenance personnel should manually start the program after completing the operation; The monitoring thread detected that the window had reappeared and automatically restored it to the top position.

[0076] This application also provides an electronic device, which includes: at least one processor, at least one memory, a power supply, a communication interface, an input / output interface, and a communication bus. The memory stores a computer program, which is loaded and executed by the processor to implement the relevant steps in the terminal window hierarchy control method disclosed in any of the foregoing embodiments, or to run the terminal window hierarchy control system disclosed in any of the foregoing embodiments. Furthermore, the electronic device in this embodiment can specifically be a computer.

[0077] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the relevant steps in the terminal window hierarchy control method disclosed in any of the foregoing embodiments, or runs the terminal window hierarchy control interview system disclosed in any of the foregoing embodiments. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0078] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the system or method sections.

[0079] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0080] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0081] Although embodiments of this application have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A terminal window hierarchy control system based on local services, characterized in that, include: At least one terminal module, the terminal module including a terminal program, the terminal module being used to load and run the service station web program corresponding to the terminal program via the HTTP protocol, and to initiate an API interface call request to the control service module; The web page service module is used to provide the web page program for the service station; The control service module runs on the network port of the local host. The control service module is used to generate window-level control instructions based on the API interface call request and send the window-level control instructions to the terminal module. The terminal module is further configured to receive the window hierarchy control instructions and execute the window hierarchy control instructions to implement window control services.

2. The terminal window hierarchy control system according to claim 1, characterized in that, The window control service includes one or more of the following: window search and handle acquisition, window pinning, window unpinning, taskbar display, taskbar hiding, real-time window status monitoring, automatic window startup, automatic window recovery, and log recording.

3. The terminal window hierarchy control system according to claim 2, characterized in that, The execution of the window hierarchy control instructions to implement window control services includes: The terminal module is equipped with an independent monitoring thread to achieve real-time monitoring of the window status. The terminal module provides window control services based on the window status. The window state is represented by multiple state flags, including one or more of is_top_enabled, is_closed_by_api, and isNeedTop. The is_top_enabled parameter is used to indicate whether the target window exists. The is_closed_by_api term is used to indicate whether the window was actively closed via API. The isNeedTop flag is used to indicate whether the window should be automatically pinned to the top when it is closed and reopened after being depinned.

4. The terminal window hierarchy control system according to claim 3, characterized in that, The terminal module implements window control services based on the window state, including: When is_closed_by_api indicates that the window was closed actively by the API, no automatic restart operation is performed; when is_closed_by_api indicates that the window was not closed actively by the API, the terminal module executes the automatic restart procedure of the terminal program and puts the window on top.

5. The terminal window hierarchy control system according to claim 3, characterized in that, The execution of the window hierarchy control instructions to implement window control services includes: The execution module executes the window un-top control based on the window hierarchy control instructions and operation and maintenance control instructions. The operation and maintenance control command is triggered by performing a first operation on the service station web application and a password verification operation.

6. The terminal window hierarchy control system according to claim 2, characterized in that, The window-on-top control is achieved by calling the Windows API's SetWindowPos function to set the window hierarchy order.

7. The terminal window hierarchy control system according to claim 2, characterized in that, The window control service also includes system startup, which performs initialization operations through the setupConfig function. The initialization operations include window search and handle acquisition, window pinning control, taskbar hiding control, and starting the monitoring thread.

8. The terminal window hierarchy control system according to claim 2, characterized in that, The window hierarchy control instructions are executed to implement window control services. include, The window control service links the window to top, the taskbar to show, and the taskbar to hide. Specifically, the taskbar is hidden when the window is pinned to top, and the taskbar is shown when the window is unpinned.

9. The terminal window hierarchy control system according to claim 2, characterized in that, The log recording includes recording one or more of the following: timestamp, operation type, execution result, and exception stack information of the window control service.

10. A terminal window hierarchy control method based on local services, characterized in that, include: The service station web page program corresponding to the terminal program is loaded and run via the HTTP protocol; Initiate an API call request to the server, wherein the server is running on the network port of the local host; Receive window hierarchy control instructions from the server, wherein the window hierarchy control instructions are generated based on the API interface call request; Execute the window hierarchy control instructions to implement window control services.

Images