Method and device for collaborative work of industrial configuration software based on browser multi-window architecture

Abstract

This application relates to a method and apparatus for collaborative operation of industrial configuration software based on a browser multi-window architecture. The method includes: creating a main window and establishing an independent operation record field for it; creating a child window in response to dragging a tab in the main window, appending an identifier parameter to the Uniform Resource Locator (URL); identifying its own mode when the child window loads, dynamically hiding redundant interfaces and establishing an independent operation record field; registering the child window with the main window's state synchronization bus; and broadcasting a state update message via the bus when the main window detects a global state change event, which the child window then automatically refreshes upon receiving. This application's embodiments solve the problems of cross-contamination of operation records and wasted screen space in multi-window collaboration by using differentiated rendering between main and slave windows and isolation of operation records, achieving non-interference of editing history and real-time synchronization of window states.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a collaborative working method and apparatus for industrial configuration software based on a browser multi-window architecture. Background Technology

[0002] With the development of the Industrial Internet, traditional desktop client configuration software is gradually migrating to web-based platforms. Web-based configuration software, due to its installation-free, cross-platform, and easy-to-access characteristics, has become an industry trend. In the configuration process of complex industrial engineering projects, engineers often need to simultaneously reference and edit the logic of multiple control stations, or process multiple function pages (such as function blocks, ladder diagrams, and structured text) in parallel within a single control station. Therefore, efficient multi-window collaborative working capabilities have become an important indicator of the advancement of configuration software.

[0003] Currently, industrial configuration software primarily employs three technical approaches to handling multi-window tasks. The first is the desktop Multiple Document Interface (MDI) mode, where all program units can only be switched within the main window via tabs; child windows cannot be dragged out of the main frame for independent display. The second is the desktop Single Document Interface (SDI) or hybrid mode, supporting each editor as an independent window that can be freely dragged and detached, but each independent window loads a complete menu bar and toolbar. The third is the web-native multi-tab mode, relying on the browser's built-in `window.open` method to open new tabs, with each tab fully loading the entire configuration application.

[0004] However, the aforementioned existing technical solutions share the following common drawbacks: First, operation logs interfere with each other. Multiple windows or views share the same global undo / redo stack. When an engineer modifies a proportional-integral-derivative (PID) parameter in window A and deletes a variable in window B, when performing an undo operation in window A, the deletion operation in window B may be incorrectly rolled back, causing logical confusion and potential engineering problems.

[0005] Second, debugging and monitoring are confused. Debugging operations such as "force write" and "force assign" affect the entire project scope, and debugging behavior directly pollutes the production monitoring screen, posing a serious security risk.

[0006] Third, the functional layout is redundant, resulting in low screen space utilization. Each independent window contains a complete menu bar and toolbar, which seriously wastes screen display area and compresses the available space in the core editing area.

[0007] Fourth, the logic for cross-window search and navigation is missing. Existing technology only supports searching within the current editor or window, and cannot perform cross-window searches. Users must manually search through each window, which is extremely inefficient.

[0008] Fifth, window status synchronization is lagging. When performing global operations such as switching between online and offline modes or saving a project in the main window, other open windows cannot perceive the status change in real time. Users must manually activate each child window to see the latest status, resulting in a fragmented experience and making it easy to misjudge operations.

[0009] Sixth, there is a lack of granular window resource management. Current technology does not limit the number of windows, allowing users to open an unlimited number of windows, leading to soaring memory usage, decreased browser performance, and even crashes.

[0010] Therefore, there is an urgent need for a solution that can address the technical challenges of existing industrial configuration software in multi-window collaborative operations, such as cross-contamination of operation records, confusion between debugging and monitoring, wasted screen space, missing cross-window lookup, delayed status synchronization, and loss of control over window resources. Summary of the Invention

[0011] Based on this, it is necessary to provide a collaborative working method, device, computer equipment, computer-readable storage medium, and computer program product for industrial configuration software based on a browser multi-window architecture, which can achieve non-interference of editing history in a multi-window environment, window-level isolation of debugging behavior, maximization of the core editing area, intelligent navigation with global reach in a single search, real-time linkage of master and slave window states, and fine-grained management of window resources.

[0012] In a first aspect, this application provides a collaborative working method for industrial configuration software based on a browser multi-window architecture, the method comprising: In response to the user's login to the configuration software in the browser, a main window instance is created, a unique identifier for the main window is generated, a complete user interface including the header toolbar, left control station tree, tab bar and content area is loaded, and an independent operation record field is created for the main window; In response to a user dragging a tab in the main window outside the tab bar, a child window is created, and parameters including the window type identifier, parent window identifier, and tab identifier are appended to the child window's Uniform Resource Locator URL. When the child window is loaded, it identifies itself as a child window mode based on the window type identifier, dynamically hides the header toolbar and the left control station tree, and creates an independent operation record field for the child window. The child window registers with the status synchronization bus of the main window when it is created; When the main window detects a global state change event, it broadcasts a state update message to all registered child windows via the state synchronization bus. Upon receiving the message, the child windows automatically refresh their interfaces.

[0013] In one embodiment, creating a separate operation record field for the main window includes: Create separate undo and redo stack instances for the main window, each bound to a window identifier; When the main window performs an editing operation, the corresponding operation is encapsulated as a command object and pushed onto the top of the undo stack corresponding to the current window, and the redo stack corresponding to the current window is cleared. When a user performs an undo operation in the main window, the command object is popped from the top of the undo stack corresponding to the current window and the undo logic is executed. The undoed command object is then pushed onto the top of the redo stack corresponding to the current window. When a user performs a redo operation in the main window, the command object is popped from the top of the redo stack corresponding to the current window and the redo logic is executed. The redoed command object is then pushed onto the top of the undo stack corresponding to the current window. The operation log field of the main window is completely independent, and the undo and redo operations only apply to the operation log field of the current window itself.

[0014] In one embodiment, creating an independent operation record field for the child window includes: Create separate undo and redo stack instances for each child window, each bound to a window identifier; When a user performs an editing operation in any child window, the corresponding operation is encapsulated as a command object and pushed onto the top of the undo stack of the current window, and the redo stack of the current window is cleared. When a user performs an undo operation in any child window, the command object is popped from the top of the undo stack corresponding to the current window and the undo logic is executed. The undoed command object is then pushed onto the top of the redo stack corresponding to the current window. When a user performs a redo operation in any child window, the command object is popped from the top of the redo stack corresponding to the current window and the redo logic is executed. The redone command object is pushed onto the top of the undo stack corresponding to the current window. Each sub-window's operation record field is completely independent, and undo and redo operations only apply to the operation record field of the current window itself.

[0015] In one embodiment, the method further includes: In response to a user's lookup reference operation triggered on a target variable in the source window, after obtaining the identification information of the target variable, a lookup request is sent to the server. The source window may include the main window or any child window. The server performs a global search in the project configuration, covering all program organization units and variable tables in the current project. The matching results are then organized into a search reference tree structure that includes window identifiers, tab identifiers, variable names, position indexes, and reference types before being returned to the front end. The front end groups and aggregates the matching results according to the window identifier and tab identifier, and generates a tree view in the source window to display all referenced results; In response to the user's selection of a reference result in the tree view, extract the target window identifier, target tab identifier, and variable index; Activate the target window according to the target window identifier; Activate or create the target tab based on the target tab identifier, and perform precise line-level positioning and highlighting in the target tab based on the variable index and editor type.

[0016] In one embodiment, the global state change event includes: an online / offline state switching event, a project save event, a template library update event, and a control station switching event; After receiving the status update message, the child window performs a corresponding interface refresh operation according to the event type. The interface refresh operation includes at least one of the following: updating the toolbar status icon of the main window, updating the window title or refreshing the content area display of the child window, updating the display color of elements in the editor, refreshing variable monitoring values, or reloading tab content.

[0017] In one embodiment, the method further includes: When a child window that is not inactive is activated by the user, the child window actively requests the latest status data from the status synchronization bus, and the bus returns the current status data. After confirming that the status is consistent through the sub-window, the interface rendering is completed.

[0018] In one embodiment, prior to the step of creating a child window in response to a user dragging a tab in the main window outside the tab bar, the method further includes: The number of currently active child windows is obtained through the master and slave window manager and compared with a preset upper limit value; If the number of active child windows has reached the preset limit, return a prompt message to the user and terminate the child window creation process; If the number of currently active child windows has not reached the preset limit, a unique identifier for the child window is generated, creation permission is returned to the main window, and the child window creation operation continues.

[0019] In one embodiment, the method further includes: Assign an independent debug session data layer to the main window and each child window; When a user performs a forced write or forced assignment debugging operation in the main window, the debugging operation only applies to the debugging session data layer specific to the current window and does not affect the real data view of other windows. When a user switches the online or offline status of the control station, only the debug session data layer of the current window changes state, while the debug session data layers of other windows remain unchanged.

[0020] In one embodiment, the method further includes: When a child window is detected to be closed, only the debug session, operation stack memory, and session data layer of the child window are cleaned up. When the main window is detected to be closed, first obtain a list of all associated child windows under the main window, then clean up the debug session, operation stack memory and session data layer of each child window in turn, and remove them from the session list. After all associated child windows have been cleaned up, clean up the debug session, operation stack memory, session data layer and underlying database connection resources of the main window itself.

[0021] Secondly, this application also provides an industrial configuration software collaborative working device based on a browser multi-window architecture, the device comprising: The master-slave window manager is used to respond to the user's login operation of the configuration software in the browser, create a master window instance, generate a unique identifier for the master window, load the complete user interface including the header toolbar, left control station tree, tab bar and content area, and create an independent operation record field for the master window; A context-isolated undo / redo engine is used to respond to a user dragging a tab in the main window outside the tab bar by creating a child window and appending parameters containing a window type identifier, a parent window identifier, and a tab identifier to the child window's Uniform Resource Locator URL. The cross-window intelligent navigation service module is used to identify itself as a child window mode according to the window type identifier when the child window is loaded, dynamically hide the header toolbar and the left control station tree, and create an independent operation record field for the child window. A registration module is used to register the child window with the status synchronization bus of the main window when the child window is created; A window state synchronization bus is used to broadcast a state update message to all registered child windows when the main window detects a global state change event. The child windows automatically refresh their interfaces after receiving the message.

[0022] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps: In response to the user's login to the configuration software in the browser, a main window instance is created, a unique identifier for the main window is generated, a complete user interface including the header toolbar, left control station tree, tab bar and content area is loaded, and an independent operation record field is created for the main window; In response to a user dragging a tab in the main window outside the tab bar, a child window is created, and parameters including the window type identifier, parent window identifier, and tab identifier are appended to the child window's Uniform Resource Locator URL. When the child window is loaded, it identifies itself as a child window mode based on the window type identifier, dynamically hides the header toolbar and the left control station tree, and creates an independent operation record field for the child window. The child window registers with the status synchronization bus of the main window when it is created; When the main window detects a global state change event, it broadcasts a state update message to all registered child windows via the state synchronization bus. Upon receiving the message, the child windows automatically refresh their interfaces.

[0023] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps: In response to the user's login to the configuration software in the browser, a main window instance is created, a unique identifier for the main window is generated, a complete user interface including the header toolbar, left control station tree, tab bar and content area is loaded, and an independent operation record field is created for the main window; In response to a user dragging a tab in the main window outside the tab bar, a child window is created, and parameters including the window type identifier, parent window identifier, and tab identifier are appended to the child window's Uniform Resource Locator URL. When the child window is loaded, it identifies itself as a child window mode based on the window type identifier, dynamically hides the header toolbar and the left control station tree, and creates an independent operation record field for the child window. The child window registers with the status synchronization bus of the main window when it is created; When the main window detects a global state change event, it broadcasts a state update message to all registered child windows via the state synchronization bus. Upon receiving the message, the child windows automatically refresh their interfaces.

[0024] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps: In response to the user's login to the configuration software in the browser, a main window instance is created, a unique identifier for the main window is generated, a complete user interface including the header toolbar, left control station tree, tab bar and content area is loaded, and an independent operation record field is created for the main window; In response to a user dragging a tab in the main window outside the tab bar, a child window is created, and parameters including the window type identifier, parent window identifier, and tab identifier are appended to the child window's Uniform Resource Locator URL. When the child window is loaded, it identifies itself as a child window mode based on the window type identifier, dynamically hides the header toolbar and the left control station tree, and creates an independent operation record field for the child window. The child window registers with the status synchronization bus of the main window when it is created; When the main window detects a global state change event, it broadcasts a state update message to all registered child windows via the state synchronization bus. Upon receiving the message, the child windows automatically refresh their interfaces.

[0025] The aforementioned collaborative working method, apparatus, computer equipment, computer-readable storage medium, and computer program product for industrial configuration software based on a browser multi-window architecture, in response to a user's login to the configuration software in a browser, creates a main window instance, generates a unique identifier for the main window, loads a complete user interface including a header toolbar, a left-side control station tree, a tab bar, and a content area, and creates an independent operation record field for the main window; in response to a user's dragging of a tab in the main window outside the tab bar, it creates a child window and appends parameters including a window type identifier, a parent window identifier, and a tab identifier to the child window's Uniform Resource Locator (URL); when the child window loads, it identifies itself as a child window based on the window type identifier, dynamically hides the header toolbar and the left-side control station tree, and creates an independent operation record field for the child window; the child window registers with the main window's state synchronization bus upon creation; when the main window detects a global state change event, it broadcasts a state update message to all registered child windows through the state synchronization bus, wherein the child window automatically refreshes its interface after receiving the message. This system systematically solves the technical problems of existing industrial configuration software in multi-window collaborative work, such as cross-contamination of operation records, confusion between debugging and monitoring, wasted screen space, missing cross-window search, lagging state synchronization, and uncontrolled window resources, through mechanisms such as differentiated rendering between main windows and child windows, window-level isolated undo / redo stack, cross-window intelligent navigation, state synchronization bus, debug session isolation, and hierarchical resource cleanup. It achieves non-interference of editing history in multi-window environment, window-level isolation of debugging behavior, maximization of core editing area space, intelligent navigation with global reach in one search, real-time linkage of main and slave window states, and fine-grained management of window resources. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram illustrating the principle of an industrial configuration software collaborative working method based on a browser multi-window architecture in one embodiment. Figure 2 Here is a flowchart of the control station tree search and window linkage in one embodiment; Figure 3 Here is a flowchart of cross-window lookup and navigation in one embodiment; Figure 4 This is a schematic diagram of a state synchronization bus mechanism in one embodiment; Figure 5 This is a schematic diagram illustrating window closing and resource cleanup in one embodiment. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0030] For example, this embodiment provides a collaborative working method for industrial configuration software based on a browser multi-window architecture, which mainly includes the following steps: Step 1: Initialize the main window.

[0031] In this embodiment, the user opens a browser, accesses the configuration software address, and logs in with their username and password. In response to the user's login, the system creates a main window instance and generates a unique identifier for the main window (e.g., "window_main_001"). The system loads the complete user interface, including the header toolbar, left-side control station tree, tab bar, and content area, and simultaneously creates an independent operation record field for the main window. This operation record field contains independent undo and redo stack instances bound to the main window identifier; initially, both the undo and redo stacks are empty.

[0032] Step 2: Create child windows.

[0033] In this embodiment, the user selects an open tab (e.g., "Control Station A_Ladder Diagram Program 1") in the main window, holds down the left mouse button, drags the tab to the area outside the tab bar, and releases the left mouse button. The system captures this drag-and-drop end event and recognizes it as the user's intention to create a child window. Before creating the child window, the system performs window access control: it obtains the number of currently active child windows through the master and slave window manager and compares it with a preset upper limit (e.g., 5). If the number of currently active child windows has reached the preset upper limit, the system returns a prompt message to the user, "The number of child windows has reached the limit. Please close some windows and try again," and terminates the child window creation process. If the number of currently active child windows has not reached the preset upper limit, the system generates a unique identifier for the child window (e.g., "window_child_001") and returns creation permission to the main window. The system calls a native browser method (e.g., window.open) to create the child window and appends the following parameters to the child window's URL: windowType=child&parentId=window_main_001&tabId=tab_A001. Among them, the window type identifier is used to indicate that the window is in child window mode, the parent window identifier is used to establish the association relationship with the main window, and the tab identifier is used to indicate the specific tab content that the child window needs to load.

[0034] Step 3: Differentiated rendering of sub-windows.

[0035] In this embodiment, when the child window loads, the front-end framework parses the URL parameters. Based on `windowType=child`, it identifies itself as a child window and dynamically calls the DOM manipulation interface to hide the header toolbar and the left-side control station tree, rendering only the content area. The child window's title bar is displayed as "Project X-Control Station A-Ladder Diagram Program 1" according to a set rule for easy user identification. Simultaneously, the system creates an independent operation record field for the child window, containing independent undo and redo stack instances bound to the child window identifier. This operation record field is isolated from the main window's operation record field and does not affect each other.

[0036] Step 4: Register the status synchronization bus.

[0037] In this embodiment, after the child window is created, it sends a registration request to the main window's state synchronization bus. The state synchronization bus adds the child window's window identifier and callback method to the subscriber list, completing the registration. Afterward, the child window can receive state update messages broadcast by the main window.

[0038] Step 5: Global state changes and broadcasts.

[0039] In this embodiment, when an engineer performs a global operation in the main window, such as switching a control station from "online" to "offline," the main window detects this global status change event and encapsulates it into a message object. This message object contains the event type (e.g., "STATUS_CHANGE"), the change content (e.g., "online → offline"), a timestamp, and the source window identifier. The main window sends the message object to the status synchronization bus, which iterates through the subscriber list and broadcasts the status update message to all registered child windows. Upon receiving the message, each child window automatically refreshes its interface based on the event type: the function block diagram editor in the child window updates the element display color from green (online status) to gray (offline status), and the status indicator in the window title bar is updated synchronously.

[0040] In addition, when a child window that is not inactive is activated by the user, the child window actively requests the latest status data from the status synchronization bus. The bus returns the current status data, and the child window completes the interface rendering after confirming that the status is consistent, ensuring that windows that have not been activated for a long time can also obtain the latest status.

[0041] As an optional implementation, when a child window is inactive, it only updates its internal state data (e.g., stores the latest state value in memory) after receiving a broadcast message, and does not perform interface rendering operations to save computing resources. When the user clicks to activate the child window, the window activation check mechanism is triggered, and the child window actively requests the latest state data from the state synchronization bus, which returns the current state data. The child window compares the returned state data with the locally stored state data. If there is a difference, it completes the interface rendering based on the difference and, depending on the event type (e.g., the project has been modified by someone else), pops up a message prompt box to inform the user.

[0042] For example, Figure 1 This is a schematic diagram illustrating the principle of a collaborative working method for industrial configuration software based on a browser multi-window architecture in one embodiment; such as... Figure 1 As shown, the core of this system lies in the design of a "master-slave window management model" and a "context isolation and broadcasting mechanism". The system mainly consists of the following core modules.

[0043] 1) Master-slave window manager: The master-slave window manager is responsible for the following functions: window registration and identification, which generates a unique window identifier for each open browser window and marks its type as a master window or a child window. The master window has complete user interface components (head toolbar, control panel tree), while the child window is a simplified view containing only the content area; lifecycle management, which maintains a list of active windows and cascades all its derived child windows when the master window is closed; and quantity control, which implements the verification of the upper limit of the number of windows and provides a friendly prompt when the limit is exceeded.

[0044] 2) Context-isolated undo / redo engine: The context-isolated undo / redo engine is used to achieve operation record isolation. This engine creates an independent operation stack instance in memory for each window, which belongs only to that window. Every editing operation performed by the user in window A is pushed to window A's dedicated operation stack. Undo operations in window B can only access and modify window B's own operation stack, fundamentally eliminating the confusion of cross-window operation records.

[0045] 3) Cross-window intelligent navigation service (module): The cross-window intelligent navigation service handles cross-window needs such as lookup and replace. When a lookup is initiated in the main window or any child window, the service searches the editing content of all active windows; it aggregates all matching results by window and tab; when the user clicks on a result, the service activates the window based on the window identifier where the result is located, calls the target window's internal method, activates and jumps to the specific tab containing the result, and displays that tab at the top.

[0046] 4) Window state synchronization bus: The window state synchronization bus is responsible for maintaining the consistency of state between the main window and child windows. When a child window is created, it subscribes to the main window's bus for state change notifications. When the main window experiences events such as switching between online and offline status, saving the project, updating function blocks or data types, or switching control station states, it broadcasts these events to all child windows via the bus. When a window is activated by a user, the bus triggers a lazy check, actively retrieves the latest state, and displays a message or updates the state flag on the tab when necessary.

[0047] Figure 2 Here is a flowchart of the control station tree search and window linkage in one embodiment; Figure 3 Here is a flowchart of cross-window lookup and navigation in one embodiment; Figure 4 This is a schematic diagram of a state synchronization bus mechanism in one embodiment; Figure 5 This is a schematic diagram illustrating window closing and resource cleanup in one embodiment.

[0048] In combination with the above Figures 2-5 As shown, the core process may include: First: Main window initialization and child window creation.

[0049] Input: The user opens a browser, visits the configuration software address, logs in, and opens a control station tab. Process: 1) Main window initialization The system initializes a main window instance, generates a unique window identifier for it, and marks it as a main window. The system creates an independent operation stack instance for the main window to record all editing operations performed on that window. The main window loads the complete user interface, including the header toolbar, the left-side control panel tree, the central tab bar, and the content area.

[0050] 2) Child window creation request triggered The user selects the target tab header in the main window, holds down the left mouse button, drags it outside the tab bar area, and releases the left button. The front-end framework captures this drag-and-drop end event and recognizes it as the user's intention to create a child window.

[0051] 3) Window count verification The main window sends a child window creation request to the master-slave window manager. The master-slave window manager obtains the number of currently active child windows and compares it with a preset upper limit. If the current number of child windows has reached the upper limit, the master-slave window manager returns a prompt message to the user, and the child window creation process terminates.

[0052] 4) Instantiation of child windows If the current number of child windows has not reached the limit, the master and slave window managers generate unique identifiers for the child windows and return creation permission to the master window. The master window calls a native browser method to open a new window and appends parameters to the URL of the new window, including the window type identifier, parent window identifier, project identifier, control station identifier, and tab identifier.

[0053] 5) Differentiated rendering of child windows When a new window loads, the front-end framework parses the URL parameters and identifies itself as a child window based on the window type identifier. The child window dynamically hides the header toolbar and left-side control station tree based on the parameters, rendering only the content area. The child window title is concatenated and displayed as "Project-Control Station-Page Signature Title" according to the rules.

[0054] 6) Initialize child window resources The child window creates an independent operation stack instance to record all editing operations performed on that window. The child window registers with the master / slave window manager, adding it to the list of active windows. The child window also registers with the window state synchronization bus, subscribing to state change notifications from the master window.

[0055] Output: A streamlined sub-window focused on the core editing area has been created. This window has its own operation stack and is in state synchronization with the main window.

[0056] Second: Cross-window search and reference with precise navigation.

[0057] Input: The user selects the target variable in the source window (main window or child window), triggering the lookup reference operation.

[0058] Processing procedure: 1) Search request initiation and forwarding When a user performs a lookup operation on a variable in the source window, the source window obtains the variable's identification information, including the variable name, variable identifier, and the control station it belongs to. The source window encapsulates this information into a lookup request and sends it to the front-end lookup service module, which then forwards the request to the server.

[0059] 2) Server-side unified retrieval and result construction After receiving a search request, the server performs a global search in the project configuration. The search scope covers all program organizational units in the current project, including ladder diagram programs, function block diagram programs, structured text programs, as well as variable table definitions, function block pin bindings, and variable references in script code.

[0060] The server organizes all retrieved matching results into a lookup reference tree structure. Each node in this tree structure contains the following location information: the window identifier of the window containing the reference, the tab identifier of the page containing the reference, the tab type, the variable name of the referenced variable, the line index or position index of the variable in the file, the context description of the reference location, and the reference type. The lookup reference tree is returned to the front end in JSON format.

[0061] 3) Results grouping and visualization After receiving the search reference tree, the front-end search service groups and aggregates the results by window identifier and tab identifier, grouping reference results belonging to the same window together and reference results belonging to the same tab into subgroups. The front-end generates a tree view in the source window, expanding and displaying all reference results hierarchically, with each result entry displaying a description of the reference location and reference type.

[0062] 4) Jump target selection and location request When a user clicks on a reference result in the tree view, the source window extracts the location information corresponding to that result entry, including the target window identifier, target tab identifier, variable name, and variable index. The source window then encapsulates this location information into a redirect request and sends it to the front-end search service module.

[0063] 5) Target window activation and tab positioning The front-end lookup service module locates the target window based on the target window identifier. If the target window is the main window and is not currently active, the "Bring Window to the Foreground" method is called to activate it; if the target window is a child window and is not currently active, the "Bring Window to the Foreground" method is also called to activate it; if the target window is closed, a message indicating that the target window does not exist is returned to the user, and the process terminates.

[0064] Once the target window is activated, tab positioning is performed based on the target tab identifier. If the target tab is not already open in the target window, a new tab is created and its content is loaded; if the target tab is already open but not active, it is activated to become the currently edited tab.

[0065] 6) Row-level precise positioning and highlighting After the tab is activated, the target window performs a positioning operation based on the variable index. For text editors such as structured text programs or variable tables, the target line position is calculated based on the variable index, the editor is scrolled to the target line, and the target line is highlighted. For graphical editors such as ladder diagram programs or function block diagrams, the position coordinates of the target network are obtained based on the function block ID, the canvas is scrolled to the target network, and the function block containing the target variable element in the target network is highlighted.

[0066] Output: The target window is automatically activated, the target tab is expanded, and the location of the target variable is accurately located and highlighted, achieving intelligent navigation and precise jumps across windows.

[0067] Third: Management of isolation operation records.

[0068] Input: Users perform editing operations in various windows and execute undo or redo commands.

[0069] Processing procedure: 1) Operation record field initialization The system creates independent operation log fields for the main window and each child window. Each operation log field contains independent undo and redo stack instances. The identifier of the operation log field is bound to the window identifier, and its lifecycle is consistent with the window's lifecycle.

[0070] 2) Record of editing operations When a user performs an editing operation in any window, the system encapsulates the operation as a command object. The command object contains the operation type, operation parameters, execution method, and undo method. The system locates the corresponding operation record field based on the identifier of the current window, pushes the command object onto the top of the undo stack of that operation record field, and clears the redo stack of that operation record field.

[0071] 3) Execution of undo operation When a user performs an undo operation in a window, the system locates the corresponding operation record field based on the current window's identifier. The system pops the command object from the top of the undo stack of that operation record field, calls the command object's undo method, and executes the undo logic. The undone command object is then pushed onto the top of the redo stack of that operation record field.

[0072] 4) Execution of redo operations When a user performs a redo operation in a window, the system locates the corresponding operation record field based on the current window's identifier. The system pops a command object from the top of the redo stack of that operation record field, calls the command object's execution method, and performs the redo logic. The redone command object is then pushed onto the top of the operation stack of that operation record field.

[0073] 5) Operation record isolation verification The system ensures that the operation log field for each window is completely independent. An undo operation in window A only affects window A's operation log field and does not affect the operation log fields of windows B and C; a redo operation in window B only affects window B's operation log field and does not affect other windows. The operation log interface for each window only displays the operation log content of the current window and does not display the operation logs of other windows.

[0074] Output: The editing history of each window is perfectly isolated. Undo and redo operations only affect the current window, and cross-window operations do not interfere with each other.

[0075] Fourth: Child window linkage triggered by main window events.

[0076] Input: Engineers perform global operations in the main window, such as switching between online and offline modes, saving projects, and updating the template library.

[0077] Processing procedure: 1) Event Subscription Registration When each child window is created, it sends a subscription request to the main window's window state synchronization bus. The window state synchronization bus then adds the child window's window identifier and callback methods to the subscriber list, completing the registration.

[0078] 2) Global operation execution Users perform global operations in the main window, which then processes the operation command. Taking online / offline switching as an example, the main window switches the control station status from "online" to "offline" and updates the local status display.

[0079] 3) Event encapsulation and broadcasting The main window encapsulates state change events into message objects, which include the event type, change details, timestamp, and source window identifier. The main window then sends the message object to the window state synchronization bus, which iterates through the subscriber list and broadcasts the message object to all registered child windows.

[0080] 4) Child window receiving and refreshing After receiving a broadcast message, each child window performs the corresponding interface refresh operation based on the event type in the message object. Taking online / offline switching as an example, the child window updates the status icon on the toolbar from "Online" to "Offline" and updates the display color of elements in the editor, such as the function block diagram, from green to gray.

[0081] 5) Check when the window is active When a child window is inactive, it only updates its internal state data after receiving a broadcast message and does not perform UI rendering. When the user clicks to activate the child window, the window activation check mechanism is triggered. The child window requests the latest state from the window state synchronization bus. The bus returns the current state data, and the child window completes UI rendering after confirming that the state is consistent, displaying message prompts if necessary.

[0082] Output: A single global operation on the main window triggers a real-time refresh of all associated child windows, ensuring that the states of multiple windows remain consistent in real time, eliminating the problems of manual refresh and state lag.

[0083] Fifth: Close the window and clean up resources.

[0084] Input: The user closed the browser window, causing the WebSocket connection to be disconnected.

[0085] Processing procedure: 1) Connection disconnection detection When a user closes a browser window, the front-end cannot intercept this action. The server detects the user's offline status via a WebSocket connection disconnection event and searches for the corresponding window session information in the session manager based on the disconnection identifier.

[0086] 2) Window type determination The server determines the type of window to close based on the found window session information. If the window type is a child window, the child window cleanup process is executed; if the window type is a main window, the main window cleanup process is executed.

[0087] 3) Sub-window cleanup process When a child window is closed, the server performs the following cleanup operations: terminates the ongoing project download session in the child window; terminates debugging sessions such as variable monitoring and forced writes in the child window; releases the operation stack memory independently maintained by the child window; cleans up the session data layer dedicated to the child window; and removes the child window record from the server's session list. The process ends after the child window cleanup is complete, without affecting the main window or other child windows.

[0088] 4) Main window cleanup process When the main window is closed, the server performs a cascading cleanup operation. The server retrieves a list of all associated child windows under the main window, iterates through the list, and performs the following operations on each child window in sequence: terminate the download session in the child window; terminate the debug session in the child window; release the operation stack memory of the child window; clean up the session data layer of the child window; and remove the child window record from the server's session list.

[0089] After all associated child windows have been cleaned up, the server performs the following cleanup operations on the main window: terminates the debugging session in the main window; releases the operation stack memory of the main window; cleans up the session data layer of the main window; removes the main window record from the server session list; and releases underlying resources such as database connections.

[0090] Output: Differentiated cleanup is performed based on window type. When a child window is closed, only its own resources are cleaned up. When the main window is closed, all associated child windows are cleaned up first, and then its own resources are cleaned up, ensuring that all window resources are completely released and there is no memory leak.

[0091] For example, based on the above embodiments, the specific implementation method of operation log isolation is further described.

[0092] The main window operation log field creates independent undo and redo stacks for the main window, each bound to the window identifier. The stack data structure is implemented using an array, with each stack element being a command object. When an engineer performs an "Add Block" operation in the main window, the system encapsulates this operation as a command object. This command object contains: operation type (e.g., "ADD_BLOCK"), operation parameters (e.g., block ID, coordinates, type name), execution method (used to restore the operation during redo), and undo method (used to roll back the operation during undo). The system pushes this command object onto the top of the main window's undo stack and simultaneously clears the main window's redo stack.

[0093] Optionally, when an engineer presses Ctrl+Z (the undo shortcut) in the main window, the system pops a command object from the top of the undo stack in the main window and calls the undo method of that command object. For example, the undo method of the "Add Function Block" operation will delete the function block and restore the canvas state. The undone command object is then pushed onto the top of the redo stack in the main window.

[0094] Optionally, when an engineer presses Ctrl+Y (the redo shortcut) in the main window, the system pops a command object from the top of the redo stack in the main window, calls the execution method of the command object, and pushes the redone command object onto the top of the undo stack in the main window.

[0095] Throughout the above process, the operation history field of the main window remains completely independent. Even if the user performs several editing operations simultaneously in the child windows, the undo operation in the main window only rolls back the operation history of the main window itself and does not affect the content of the child windows. The operation history interface of each window (such as the undo / redo drop-down list) only displays the operation history of the current window and does not display the operation history of other windows.

[0096] Child Window Operation Log Fields: The operation log fields of each child window are implemented in the same way as the main window, but are independent of each other. For example, when a user deletes a variable in child window A and modifies a PID parameter in child window B, each child window maintains its own undo stack and redo stack. If the user performs an undo operation in child window A, only the variable deletion operation in child window A is rolled back; the PID parameter modification in child window B is unaffected.

[0097] For example, based on the above embodiments, the specific implementation method of cross-window intelligent navigation is further described.

[0098] The engineer selects a variable "Motor_Speed" in the main window (source window), right-clicks, and selects "Find Reference". The system retrieves the identification information of the target variable (variable name, variable identifier, and associated control station ID) and sends a search request to the server.

[0099] For example, upon receiving a search request, the server performs a global search within the current project configuration. The search scope covers all program organizational units in the current project, including: ladder diagram programs (LD), function block diagram programs (FBD), structured text programs (ST), as well as variable table definitions, function block pin bindings, and variable references in script code. The server organizes all retrieved matching results into a search reference tree structure. Each tree node contains the following location information: the window identifier of the referenced window (e.g., "window_main_001" or "window_child_002"), the tab identifier of the referenced tab, the tab type, the variable name of the referenced variable, the line index of the variable in the file (for text editors) or its position coordinates (for graphical editors), the contextual description of the reference location, and the reference type (read reference / write reference). The search reference tree is returned to the front end in JSON format.

[0100] Furthermore, after receiving the lookup reference tree, the front-end groups and aggregates the results according to the window identifier and tab identifier: reference results belonging to the same window are grouped together, and reference results belonging to the same tab are grouped into subgroups. The front-end generates a tree view in the source window (main window), expanding and displaying all reference results hierarchically, with each result entry displaying a description of the reference location and reference type.

[0101] Optionally, the engineer clicks on a referenced result in the tree view (e.g., a reference in a ladder diagram program within child window B). The source window extracts the location information corresponding to that result entry: the target window identifier "window_child_002", the target tab identifier "tab_B003", and the variable index "line 24".

[0102] In this embodiment, the system locates the target window based on the target window identifier: if the target window is a child window B and is not currently active, the `window.focus()` method is called to activate it and bring it to the foreground. After child window B is activated, tab positioning is performed based on the target tab identifier: if the target tab is not yet open in child window B, a new tab is created and the corresponding program file is loaded; if the target tab is open but not active, the tab is activated to become the currently edited tab.

[0103] After the tab is activated, the system performs precise line-level positioning based on the variable index and editor type: For structured text programs or text editors such as variable tables, the target line position is calculated based on the variable index "line 24", the editor's scrolling API is called to scroll the view to the target line, and the background color of the target line is highlighted (e.g., yellow). For graphics editors such as ladder diagram programs or function block diagrams, the position coordinates of the target network are obtained based on the function block ID, the canvas scrolling API is called to scroll the canvas to the target network, and the function block containing the target variable element in the target network is outlined and highlighted.

[0104] Through the above steps, cross-window intelligent navigation and precise redirection are achieved, enabling "one search, global accessibility".

[0105] For example, based on the above embodiments, the specific implementation method of debugging session isolation is further described.

[0106] The system allocates an independent debug session data layer on the server for each window (the main window and each child window). This debug session data layer is a temporary session-level data storage space bound to the window identifier, used to store debug data such as forced write values ​​and forced assignment states specific to that window. When an engineer performs a "force write TRUE" operation on the variable "Valve_001" via the right-click menu in the main window, the system writes this debug operation to the debug session data layer specific to the main window, but not to the actual data file of the project. The editor in the main window displays the forced value TRUE, but the variable watch table in other open child windows (such as child window A and child window B) still displays the actual process value FALSE for that variable.

[0107] When an engineer performs a forced assignment FALSE on the same variable in child window A, the operation only applies to the debug session data layer of child window A. Child window A displays FALSE, the main window still displays TRUE, and child window B displays the actual value FALSE. The three windows each display different values ​​without interfering with each other, achieving window-level isolation for debugging behavior.

[0108] When a user switches the control station's online / offline status, only the debug session data layer of the currently active window changes state; the debug session data layers of other windows remain unchanged. When the user closes the window, the corresponding debug session data layer is automatically released.

[0109] In this embodiment, the debugging session isolation mechanism fundamentally solves the industry pain point of debugging behavior polluting the production monitoring screen, and achieves physical isolation between debugging and monitoring.

[0110] For example, based on the above embodiments, the specific implementation method of window resource hierarchical cleanup is further described.

[0111] Child window closing cleanup: When a user clicks the close button of a child window (the browser's native close button), the front end cannot directly intercept this operation. The server detects the user's offline status via the WebSocket connection disconnection event. The server searches for the corresponding window session information in the session manager based on the disconnected socket identifier to determine the window type as a child window. The server executes the following child window cleanup process: terminates the ongoing project download session in the child window; terminates the variable monitoring, forced write, and other debugging sessions in the child window; releases the operation stack memory independently maintained by the child window; cleans up the debugging session data layer dedicated to the child window; and removes the child window record from the server's session list. The process ends after the child window cleanup is complete; the main window and other child windows are unaffected.

[0112] Main window close cleanup: When the user closes the main window (e.g., closes the browser's main tab), the server detects the WebSocket connection disconnection event. The server determines the window type as the main window and performs cascading cleanup operations.

[0113] The server retrieves a list of all associated child windows under the main window (by querying the association through the parent window identifier). It then iterates through this list, performing the following actions for each child window in sequence: terminating the download session in the child window; terminating the debug session in the child window; releasing the operation stack memory of the child window; cleaning up the debug session data layer of the child window; and removing the child window record from the server's session list.

[0114] After all associated child windows are cleaned up, the server performs cleanup operations on the main window: terminating the debug session in the main window; releasing the operation stack memory of the main window; cleaning up the debug session data layer of the main window; removing the main window record from the server session list; and releasing underlying resources such as database connections.

[0115] As an optional implementation, when the WebSocket connection is disconnected, the server looks up the corresponding window session information in the Session Map of the Session Manager based on the socket ID of the disconnected socket. The Session Map stores the window session object (containing information such as window identifier, window type, and parent window identifier) ​​as the value, with the socket identifier as the key and the window session object as the value.

[0116] The aforementioned tiered cleanup mechanism ensures that all window resources are fully released, thus preventing memory leaks.

[0117] For example, this embodiment provides an industrial configuration software collaborative working device based on a browser multi-window architecture, including the following modules: The master-slave window manager is used to respond to the user's login operation of the configuration software in the browser, create a master window instance, generate a unique identifier for the master window, load the complete user interface including the header toolbar, left control station tree, tab bar and content area, and create an independent operation record field for the master window.

[0118] A context-isolated undo / redo engine is used to create a child window in response to a user dragging a tab in the main window outside the tab bar, and appends parameters containing a window type identifier, a parent window identifier, and a tab identifier to the child window URL.

[0119] The cross-window intelligent navigation service module is used to identify itself as a child window mode based on the window type identifier when the child window is loaded, dynamically hide the header toolbar and the left control station tree, and create an independent operation record field for the child window.

[0120] The registration module is used to register the child window with the status synchronization bus of the main window when the child window is created.

[0121] A window state synchronization bus is used to broadcast a state update message to all registered child windows when the main window detects a global state change event. The child windows automatically refresh their interfaces after receiving the message.

[0122] The specific implementation methods of the above modules are described in the method steps of the above method embodiments, and will not be repeated here.

[0123] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described in any one of Embodiments 1 to 5.

[0124] The computer equipment also includes a monitor and a network interface. The monitor is used to display the user interface of the main window or child windows. The network interface is used to communicate with the server for lookup reference requests, status synchronization messages, and debug session data.

[0125] When the processor executes the computer program, it also performs the following functions: allocates independent memory space for each browser window to store operation record fields; implements state synchronization bus message passing between the main window and child windows through the browser's native cross-window communication API (such as BroadcastChannel or postMessage); and triggers a hierarchical resource cleanup process according to the type of window closing event.

[0126] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method steps of the various embodiments described above.

[0127] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the method steps of the various embodiments described above.

[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0129] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0130] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A collaborative working method for industrial configuration software based on a browser multi-window architecture, characterized in that, The method includes: In response to the user's login to the configuration software in the browser, a main window instance is created, a unique identifier for the main window is generated, a complete user interface including the header toolbar, left control station tree, tab bar and content area is loaded, and an independent operation record field is created for the main window; In response to a user dragging a tab in the main window outside the tab bar, a child window is created, and parameters including the window type identifier, parent window identifier, and tab identifier are appended to the child window's Uniform Resource Locator URL. When the child window is loaded, it identifies itself as a child window mode based on the window type identifier, dynamically hides the header toolbar and the left control station tree, and creates an independent operation record field for the child window. The child window registers with the status synchronization bus of the main window when it is created; When the main window detects a global state change event, it broadcasts a state update message to all registered child windows via the state synchronization bus. Upon receiving the message, the child windows automatically refresh their interfaces.

2. The method according to claim 1, characterized in that, Creating an independent operation record field for the main window includes: Create separate undo and redo stack instances for the main window, each bound to a window identifier; When the main window performs an editing operation, the corresponding operation is encapsulated as a command object and pushed onto the top of the undo stack corresponding to the current window, and the redo stack corresponding to the current window is cleared. When a user performs an undo operation in the main window, the command object is popped from the top of the undo stack corresponding to the current window and the undo logic is executed. The undoed command object is then pushed onto the top of the redo stack corresponding to the current window. When a user performs a redo operation in the main window, the command object is popped from the top of the redo stack corresponding to the current window and the redo logic is executed. The redoed command object is then pushed onto the top of the undo stack corresponding to the current window. The operation log field of the main window is completely independent, and the undo and redo operations only apply to the operation log field of the current window itself.

3. The method according to claim 1, characterized in that, Creating an independent operation record field for the child window includes: Create separate undo and redo stack instances for each child window, each bound to a window identifier; When a user performs an editing operation in any child window, the corresponding operation is encapsulated as a command object and pushed onto the top of the undo stack of the current window, and the redo stack of the current window is cleared. When a user performs an undo operation in any child window, the command object is popped from the top of the undo stack corresponding to the current window and the undo logic is executed. The undoed command object is then pushed onto the top of the redo stack corresponding to the current window. When a user performs a redo operation in any child window, the command object is popped from the top of the redo stack corresponding to the current window and the redo logic is executed. The redone command object is pushed onto the top of the undo stack corresponding to the current window. Each sub-window's operation record field is completely independent, and undo and redo operations only apply to the operation record field of the current window itself.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: In response to a user's lookup reference operation triggered on a target variable in the source window, after obtaining the identification information of the target variable, a lookup request is sent to the server. The source window may include the main window or any child window. The server performs a global search in the project configuration, covering all program organization units and variable tables in the current project. The matching results are then organized into a search reference tree structure that includes window identifiers, tab identifiers, variable names, position indexes, and reference types before being returned to the front end. The front end groups and aggregates the matching results according to the window identifier and tab identifier, and generates a tree view in the source window to display all referenced results; In response to the user's selection of a reference result in the tree view, extract the target window identifier, target tab identifier, and variable index; Activate the target window according to the target window identifier; Activate or create the target tab based on the target tab identifier, and perform precise line-level positioning and highlighting in the target tab based on the variable index and editor type.

5. The method according to any one of claims 1 to 3, characterized in that, The global status change events include: online and offline status switching events, project saving events, template library update events, and control station switching events; After receiving the status update message, the child window performs a corresponding interface refresh operation according to the event type. The interface refresh operation includes at least one of the following: updating the toolbar status icon of the main window, updating the window title or refreshing the content area display of the child window, updating the display color of elements in the editor, refreshing variable monitoring values, or reloading tab content.

6. The method according to claim 5, characterized in that, The method further includes: When a child window that is not inactive is activated by the user, the child window actively requests the latest status data from the status synchronization bus, and the bus returns the current status data. After confirming that the status is consistent through the sub-window, the interface rendering is completed.

7. The method according to any one of claims 1 to 3, characterized in that, Before creating a child window in response to a user dragging a tab in the main window outside the tab bar, the method further includes: The number of currently active child windows is obtained through the master and slave window manager and compared with a preset upper limit value; If the number of active child windows has reached the preset limit, return a prompt message to the user and terminate the child window creation process; If the number of currently active child windows has not reached the preset limit, a unique identifier for the child window is generated, creation permission is returned to the main window, and the child window creation operation continues.

8. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Assign an independent debug session data layer to the main window and each child window; When a user performs a forced write or forced assignment debugging operation in the main window, the debugging operation only applies to the debugging session data layer specific to the current window and does not affect the real data view of other windows. When a user switches the online or offline status of the control station, only the debug session data layer of the current window changes state, while the debug session data layers of other windows remain unchanged.

9. The method according to any one of claims 1 to 3, characterized in that, The method further includes: When a child window is detected to be closed, only the debug session, operation stack memory, and session data layer of the child window are cleaned up. When the main window is detected to be closed, first obtain a list of all associated child windows under the main window, then clean up the debug session, operation stack memory and session data layer of each child window in turn, and remove them from the session list. After all associated child windows have been cleaned up, clean up the debug session, operation stack memory, session data layer and underlying database connection resources of the main window itself.

10. An industrial configuration software collaborative working device based on a browser multi-window architecture, characterized in that, The device includes: The master-slave window manager is used to respond to the user's login operation of the configuration software in the browser, create a master window instance, generate a unique identifier for the master window, load the complete user interface including the header toolbar, left control station tree, tab bar and content area, and create an independent operation record field for the master window; A context-isolated undo / redo engine is used to respond to a user dragging a tab in the main window outside the tab bar by creating a child window and appending parameters containing a window type identifier, a parent window identifier, and a tab identifier to the child window's Uniform Resource Locator URL. The cross-window intelligent navigation service module is used to identify itself as a child window mode according to the window type identifier when the child window is loaded, dynamically hide the header toolbar and the left control station tree, and create an independent operation record field for the child window. A registration module is used to register the child window with the status synchronization bus of the main window when the child window is created; A window state synchronization bus is used to broadcast a state update message to all registered child windows when the main window detects a global state change event. The child windows automatically refresh their interfaces after receiving the message.

Images