Dom driven method for building desktop application partial content ecosystem

Abstract

The application discloses a DOM-driven construction method for local content ecology of desktop application, and the core concept is "window nucleus". When the position or size of a sub-window is changed, the sub-window is triggered to send a WM_WINDOWPOSCHANGING message, and the sub-window is called a window nucleus of a parent window, and the parent window is called a "nucleus window". The application calls an output function BindDOMToNucleus of a dynamic library "universe.dll", and dynamically creates a surrounding layout and a new window group filled with the layout according to a DOM description outside the window nucleus, so that the local dynamic content ecology is formed. The application provides a consistent DOM-driven content ecology construction capability for desktop application, and developers can quickly construct and switch local dynamic content according to scenes by binding different DOM descriptions to the window nucleus.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of desktop application development, and particularly relates to a method for constructing local content ecology of desktop application driven by DOM. BACKGROUND

[0002] In the development of Windows desktop applications, there is a special type of sub-window that plays an extremely important role in actual applications. This type of sub-window is often located at the center position of its parent window, and when the position or size of the sub-window changes, the sub-window is triggered to send a WM_WINDOWPOSCHANGING message. The parent window is called a "nucleus window", and most of the "top-level windows" we know are "nucleus windows", and there is more than one window nucleus. The following types of window objects are typical "window nucleus" objects, including.NETUI objects with Dock attribute values of "DockFill, DockNone", MFC CView, CSplitterWnd objects, WebView windows in browser windows, document content windows in Ice applications, and View objects in Eclipse; and in a specific desktop application, whether a sub-window is a "window nucleus" is determined by whether the developer actively sets the "SWP_NOSENDCHANGING flag" in the flag parameter when directly or indirectly calling SetWindowPos to handle the layout position of the sub-window. For.NET WinForm developers, controls with Dock attributes other than "DockFill, DockNone" will have this call flag set by SetWindowPos due to layout optimization when handling.NET object UI layout. ff ice application content windows, and View objects in Eclipse; and in a specific desktop application, whether a sub-window is a "window nucleus" is determined by whether the developer actively sets the "SWP_NOSENDCHANGING flag" in the flag parameter when directly or indirectly calling SetWindowPos to handle the layout position of the sub-window. For.NET WinForm developers, controls with Dock attributes other than "DockFill, DockNone" will have this call flag set by SetWindowPos due to layout optimization when handling.NET object UI layout.

[0003] The traditional Windows desktop window system has the characteristics of "design-time geometric layout planning + post-compilation static + atomization and non-descriptiveness", and its structure and layout mechanism are strictly constrained by the native model of the operating system. In such a system, HWND is the entity of position and size, but has no semantics; layout relies on manual coordinate calculation; components cannot be reorganized; it uses a message-driven approach and lacks state modeling; and this design has three fundamental limitations:

[0004] Dynamic response is missing: unable to achieve flow layout or flexible reorganization according to runtime content changes, losing interface adaptation capability; component isolation: windows are considered as indivisible wholes, lacking a dynamic mounting mechanism similar to Web components; and ecological interoperability barrier: there is no standardized structural description like DOM, making cross-application content aggregation and interaction difficult to achieve.

[0005] While the Web technology breaks through the physical space limit by decoupling the content structure engine (DOM) and the layout rendering engine (CSS) through a two-engine decoupling architecture, and realizes the dynamic decoupling of "content-layout". In order to realize the layout capability similar to the DOM level in the desktop environment, it is necessary to overcome two technical barriers: layout engine abstraction (convert physical coordinate calculation to virtual layout space operation) and structure description standardization (establish a DOM-like window content tree and style binding mechanism). In the traditional desktop window system, SetWindowPos is the core API of the underlying layout, and the SWP_NOSENDCHANGING flag controls the event flow and update paradigm of the window system, resulting in the existing technology being divided into synchronous event-driven mode and silent forced update mode. These two modes expose the essential contradiction between dynamicity and high efficiency that the traditional architecture cannot balance.

[0006] This contradiction deeply reveals the fundamental defect of the desktop window system that cannot balance the runtime dynamic arrangement and high-performance rendering. Breaking through this dilemma requires establishing a new layout paradigm beyond the native API, which is the core mission of the present application. SUMMARY

[0007] The present application aims to at least solve one of the technical problems existing in the prior art; for this purpose, the present application proposes a DOM-driven method for building a local content ecosystem of desktop applications, which is used to solve the following technical problems:

[0008] The structure of the traditional Windows desktop window is "design-time geometric layout planning + post-compilation static + atomization non-description", which has the following characteristics: the window layout mechanism is strictly constrained by the native model of the operating system, and the HWND hierarchical relationship, coordinate positioning and size rules of the desktop application are fixed at the compilation period (through SetWindowPos, MoveWindow, etc. API). This results in a rigid atomic architecture of the window system. This design has three fundamental limitations: dynamic response is missing: unable to realize flow layout or elastic reorganization according to runtime content changes, losing interface adaptation capability; component isolation: the window is considered as an indivisible whole, lacking a dynamic mounting mechanism similar to Web components; and ecological interoperability barrier: there is no standardized structure description similar to DOM, making it difficult to realize cross-application content aggregation and interaction.

[0009] To solve the above problems, the present application provides a DOM-driven method for building a local content ecosystem of desktop applications, comprising the following steps:

[0010] S1: define the window core as a sub-window that must trigger the WM_WINDOWPOSCHANGING message when the position or size changes;

[0011] S2: through function parameters:

[0012] S201: HWND hNucleus binds target window nucleus;

[0013] S202: LPCTSTR strKey uniquely identifies layout configuration;

[0014] S203: LPCTSTR strDOMScript declares the DOM structure surrounding the window;

[0015] S3: in response to the WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED messages of the window nucleus, the layout engine executes:

[0016] S301: extracts the WINDOWPOS structure pointer from the message lParam parameter;

[0017] S302: parses the strDOMScript description corresponding to the current strKey;

[0018] S303: if it is the first binding strKey, then dynamically creates the surrounding window group according to the DOM structure;

[0019] S304: strictly depends on the DOM structure rules and the WINDOWPOS data to calculate the window group geometry parameters in real time;

[0020] S305: updates the position and size of the surrounding window group;

[0021] S4: calls BindDOMToNucleus through a new strKey to switch the activated DOM layout configuration.

[0022] To solve the above problems, other aspects of the present application provide a system for building a desktop application local content ecosystem driven by DOM, comprising:

[0023] A window nucleus recognition unit is configured to detect whether a sub-window implements layout update by responding to a WM_WINDOWPOSCHANGING message and whether a SWP_NOSENDCHANGING flag bit is not set in a SetWindowPos call;

[0024] A drift control unit is configured to intercept the WM_WINDOWPOSCHANGING message of the window nucleus, dynamically modify the x, y, cx and cy parameters in the WINDOWPOS structure, and drive the window nucleus to produce a position or size offset in the parent window client area;

[0025] A dynamic layout area generation unit, which calculates programmable layout areas derived from the parent window according to the geometry boundary of the window core after offset;

[0026] A structured binding engine, which maps the programmable layout areas into a structured layout description tree containing nested nodes, the description tree supports XML or JSON format, and the nodes contain layout constraint attributes, including at least grid row and column definition, main area identification, size constraint, and window type matching attribute;

[0027] A rendering execution unit, which parses the structured layout description tree, dynamically creates child window components and calls SetWindowPos to position them to the corresponding coordinates of the programmable layout areas.

[0028] Preferably, the window core includes at least one of the following:

[0029] A control in.NET Framework with Dock property set to DockFill or DockNone;

[0030] A CView class or CSplitterWnd class instance in MFC framework;

[0031] A WebView component in browser embedded window;

[0032] A document content window of Office application.

[0033] Preferably, the drift control unit sets SWP_NOREDRAW and SWP_NOACTIVATE flag bits synchronously when modifying the WINDOWPOS parameter, to suppress unnecessary window redraw and focus switching.

[0034] Preferably, the structured binding engine exposes function interfaces through dynamic link library.

[0035] Preferably, the system is applicable to the graphical window management framework of Windows, macOS or Linux operating system, and the structured layout description tree is compatible with the node operation interface defined in W3C DOM Level 3Core specification.

[0036] The beneficial effects of the present application are:

[0037] The present application enables "declarative assembly" of desktop window components, assembles multiple window contents like <xobj> <xobj>< / xobj> < / xobj> , has a unified expression model for "floating window", "tab page", and "nested panel", and provides structured mounting points for low-code platforms;

[0038] The application makes the layout appearance of the desktop view describable, storable and reproducible, and is no longer limited to the static layout in the designer, and the structure state can be saved as JSON / XML.

[0039] The application breaks through the limitations of the traditional desktop window system, such as the lack of dynamic response, the isolation of components and the obstacle of ecological interoperability, and makes the desktop application become an application ecological environment similar to the Web mode, and in principle, the specific design architecture of the application is not modified, and the application is provided with flexible and ecological-based expansion capability.

[0040] The application is suitable for a graphical window management framework of Windows, macOS or Linux operating system, and the structured layout description tree is compatible with the node operation interface defined in the W3C DOM Level 3Core specification, and has good cross-platform expansibility. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 It is a module flowchart of the application;

[0042] Figure 2 It is a method flowchart of the application;

[0043] Figure 3 It is a window position flag matrix diagram for illustrating the application;

[0044] Figures 4-6 It is a process for generating a dynamic layout area by window core drift of the application;

[0045] Figures 7-8 It is a corresponding relationship between the structured description tree and the final rendering effect for demonstrating the application;

[0046] Figure 9 It is an MFC SDI FormView application interface of the application, and is used for showing an embodiment of the MFC application;

[0047] Figure 10 It is a WinForm application interface of the application, and is used for showing an embodiment of the WinForm application. DETAILED DESCRIPTION

[0048] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.

[0049] Please refer to Figure 1As shown, the application is a DOM-driven construction of a desktop application local content ecosystem, comprising:

[0050] A window core identification unit is configured to detect whether a sub-window implements layout update by responding to a WM_WINDOWPOSCHANGING message and whether a SWP_NOSENDCHANGING flag is set in a SetWindowPos call.

[0051] A drift control unit is configured to intercept a WM_WINDOWPOSCHANGING message of the window core, dynamically modify x, y, cx, and cy parameters in a WINDOWPOS structure, and drive the window core to generate a position or size drift in a parent window client area.

[0052] A dynamic layout area generation unit is configured to calculate a programmable layout area derived in the parent window according to a geometric boundary of the window core after the drift.

[0053] A structured binding engine is configured to map the programmable layout area to a structured layout description tree containing nested nodes, the description tree supports XML or JSON format, and the nodes contain layout constraint attributes including at least grid row and column definitions, main area identification, size constraints, and window type matching attributes.

[0054] A rendering execution unit is configured to parse the structured layout description tree, dynamically create sub-window components, and call SetWindowPos to position them to corresponding coordinates of the programmable layout area.

[0055] Specifically, the application is based on the "BindDOMToNucleus" function of the self-developed dynamic library "universe.dll", and provides a.NET version "cosmos.dll" of the function, which establishes a binding relationship between the handle of a sub-window and a dynamic DOM description to achieve dynamic layout of the sub-window. Since the position change of the window core completely depends on the WM_WINDOWPOSCHANGING message, the x, y, cx, and cy parameters in the WINDOWPOS structure of the message can be adjusted to cause the "window core" to drift in the rectangular area of the parent window at runtime, thereby generating a new "surrounding area" outside the window core. The key term definitions include: programmable layout area: a blank area formed in the parent window after the window core drifts, and its geometric properties can be parameterized calculated, and structured layout description tree: a hierarchical data structure similar to DOM, used to express the layout relationship between window components.

[0056] In one embodiment of the application, the window core includes at least one of the following:

[0057] a control in the.NET Framework whose Dock property is set to DockFill or DockNone;

[0058] a CView class or CSplitterWnd class instance in the MFC framework;

[0059] a WebView component in a browser-embedded window;

[0060] a document content window of an Office application.

[0061] In one embodiment of the present application, the drift control unit sets the SWP_NOREDRAW and SWP_NOACTIVATE flag bits synchronously when modifying the WINDOWPOS parameters, to suppress unnecessary window redrawing and focus switching.

[0062] Specifically, since the position change of the window core completely depends on the WM_WINDOWPOSCHANGING message, we can obtain its position information based on this message: WINDOWPOS*lpwndpos=(WINDOWPOS*)lParam; where "lParam" is the LPARAM parameter of WINDOWPOSCHANGING. By adjusting the value of the "lParam" aliquot, we can make the "window core" produce "position drift" within the rectangular area of the parent window at runtime, specifically:

[0063] lpwndpos->x; / / adjust the value of x to modify the top-left vertex coordinate

[0064] lpwndpos->y; / / adjust the value of y to modify the top-left vertex coordinate

[0065] lpwndpos->cx; / / adjust the value of cx to modify the window width

[0066] lpwndpos->cy; / / adjust the value of cy to modify the window height

[0067] lpwndpos->flags|=SWP_NOREDRAW|SWP_NOACTIVATE;

[0068] At runtime, due to the different flag bit settings of the parameters when calling SetWindowPos, the periphery of the window core will produce a new "surrounding area", which will produce different morphological changes (vertex position, width, height, visibility, etc.) according to the position adjustment strategy of the window core.

[0069] In one embodiment of the present application, the structured binding engine exposes a function interface through a dynamic link library:

[0070] IDispatch* BindDOMToNucleus (HWND hWnd, LPCTSTR strKey, LPCTSTR strXML);

[0071] wherein strXML is a string describing layout rules, supporting at least one of the following attributes:

[0072] Grid row and column definitions (rows, cols);

[0073] Master region identification (masterrow, mastercol);

[0074] Size constraints (width, height);

[0075] The entity window type filled in the corresponding layout position is matched using the "objid" attribute of the xobj element, and the window type that can be filled in the layout position includes but is not limited to ActiveX control,.NET control, WinForm, WPF control, MFC CWnd, MFC CView, and a window type customized by a developer;

[0076] wherein the dynamic link library is universe.dll or cosmos.dll.

[0077] Specifically, the self-developed dynamic library "universe.dll" outputs a function "BindDOMToNucleus", which is declared as: __declspec(dllexport)IDispatch*__stdcall BindDOMToNucleus(HWND hWnd,LPCTSTRstrKey,LPCTSTR strXML), wherein hWnd is a window nucleus handle, strKey is a unique identifier of a layout structure, and strXML is layout description data (in XML / JSON format); the static method "BindDOMToNucleus" in the static class "WebRT" of the.NET version "cosmos.dll" is declared as: static Xobj BindDOMToNucleus(control ctrl,string key,string strXobjXml), and when the Dock attribute value of the.NET Control "ctrl" is "DockFill" or "DockNone", the method binds the control "ctrl" according to different "string key values" to different layouts described by "strXobjXml".

[0078] In one embodiment of the present application, the system is applicable to a graphical window management framework of a Windows, macOS or Linux operating system, and the structured layout description tree is compatible with the node operation interface defined in the W3C DOM Level 3Core specification.

[0079] In the present embodiment, the present application needs the support of the dynamic libraries "universe.dll" and "cosmos.dll", and needs to install the Creator browser of the patent application team to obtain the two dynamic libraries. After installation, the dynamic libraries are all in the folder: "Program Files\Tangram\AIGCBrowser", and all examples in the embodiment need to be compiled in 64-bit (if a 32-bit version of Creator is installed, then the examples need to be compiled in 32-bit).

[0080] 1. MFC application embodiment

[0081] An MFC SDI FormView application is generated by using Visual Studio Wizard, and two buttons: button1 and button2 are added in the FormView, as shown in the following code: Figure 9

[0082] ​

[0083] After compilation, the effect of CFormView binding DOM can be tested.

[0084] 2、WinForm application embodiment

[0085] A WinForm application is generated by Visual Studio Wizard (64-bit compilation is required), a reference to "cosmos.dll" is added, a panel control is added to the WinForm window, the Dock attribute is set to "DockFill", and two button objects are added to the panel control, as shown in Figure 10

[0086] Event handling of button1 and button2 is added:

[0087]

[0088] Please refer to Figure 2 The application is a DOM-driven method for building a desktop application local content ecosystem, including the following steps:

[0089] S1: Define the window nucleus as a sub-window that must trigger the WM_WINDOWPOSCHANGING message when the position or size changes;

[0090] S2: Through function parameters:

[0091] S201: HWND hNucleus binds the target window nucleus;

[0092] S202: LPCTSTR strKey uniquely identifies the layout configuration;

[0093] S203: LPCTSTR strDOMScript declares the DOM structure around the window;

[0094] S3: Respond to the WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED messages of the window nucleus, and the layout engine executes:

[0095] S301: Extract the WINDOWPOS structure pointer from the message lParam parameter;

[0096] S302: Parse the strDOMScript description corresponding to the current strKey;

[0097] S303: If it is the first binding strKey, create a group around the window dynamically according to the DOM structure;

[0098] ​S304: Real-time calculation of window group geometry parameters strictly depending on DOM structure rules and WINDOWPOS data;

[0099] S305: Update the position and size of the surrounding window group;

[0100] S4: Switch the activated DOM layout configuration by calling BindDOMToNucleus with the new strKey.

[0101] The above embodiments are only used to illustrate the technical method of the present application but not to limit the present application. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical method of the present application can be modified or equivalently replaced without departing from the spirit and scope of the technical method of the present application.

Claims

1. A DOM-driven method for building a partial content ecosystem for desktop applications, characterized in that... This is achieved through the dynamic library export function BindDOMToNucleus(HWND hNucleus, LPCTSTR strKey, LPCTSTR strDOMScript), including the following steps: S1: Define the window kernel as a child window that will always trigger the WM_WINDOWPOSCHANGING message when its position or size changes; S11: Identify the window core, which is a child window that meets the following conditions: when the SetWindowPos function is called to adjust its position or size, the SWP_NOSENDCHANGING flag is not set in the flag parameter of the function, so that the change in its position or size will inevitably trigger the WM_WINDOWPOSCHANGING message. S2: Through function parameters: S201: HWND hNucleus binds to the target window kernel; S202: LPCTSTR strKey unique identifier layout configuration; S203: LPCTSTR strDOMScript declares the DOM structure surrounding the window; S3: Responding to the WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED messages of the window kernel, the layout engine executes: S301: Extract the pointer to the WINDOWPOS structure from the lParam message parameter; S3011: Dynamically adjust the x, y, cx, cy parameters in the WINDOWPOS structure to cause the window kernel to drift in a predefined position within the client area of ​​the parent window, thereby defining a programmable layout area around it. S302: Parse the strDOMScript description corresponding to the current strKey; S303: If this is the first time strKey is bound, a wrapping window group will be dynamically created based on the DOM structure; S304: Strictly relies on DOM structure rules and WINDOWPOS data to calculate window group geometric parameters in real time; S305: Update the position and size of the surrounding window group; S4: Use the new strKey to call BindDOMToNucleus to switch the active DOM layout configuration.

Images