Custom interface integration debugging method for message

Abstract

The invention relates to the technical field of computers, in particular to a custom interface integrated debugging method for messages, which comprises the following steps of: constructing a socket proxy service, a message processing service and an interface control object according to a plurality of configuration files, taking the interface control object as a front end, taking the socket proxy service and the message processing service as a rear end, and taking the socket proxy service and the message processing service as the front end; data connection between the interface control object and the socket proxy service and between the interface control object and the message processing service is established to obtain the interface control capable of performing GUI debugging, and core parameters and processing rules of the socket proxy service and the message processing service can be flexibly updated by modifying a configuration file (without recompiling codes); the analysis and combination requirements of different protocol messages are automatically adapted, repeated development work is avoided, and the message-interface debugging efficiency is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a custom interface integrated debugging method for messages. Background Technology

[0002] When faced with the need to debug a large number of communication message protocols (such as in industrial control and network communication testing scenarios), a development model that couples the front-end and back-end, and hard-codes the message protocol with the interface control, is typically used to develop corresponding message debugging tools. However, those skilled in the art have found through long-term practice that this development model has many drawbacks, severely restricting debugging efficiency and system adaptability, as follows: ① Severe repetitive development: When dealing with different types of message protocols such as TCP, UDP, and MQTT, it is necessary to develop corresponding socket sending and receiving processing logic for each protocol separately. At the same time, it is also necessary to customize exclusive GUI debugging interfaces for different scenarios such as software testing and simulation tooling. Furthermore, the interface controls (such as message input boxes, send buttons, and receive display areas) and communication logic cannot be reused across protocols, which leads to developers having to repeatedly perform homogeneous development work, resulting in a significant waste of human and time resources. ② High protocol adjustment costs: Because the message protocol processing logic is deeply bound to the code, when the message protocol changes due to debugging needs such as adding or removing fields or adjusting the format, it is necessary to modify the message parsing rules, sending and receiving control logic and related interface interaction code one by one. Moreover, any modification requires recompiling the entire project to take effect. Not only is the operation process cumbersome, but repeated compilation also generates a lot of repetitive work, making it difficult to respond quickly to protocol change requirements, significantly reducing development and debugging efficiency and extending the project cycle. ③ High coupling between messages and interface, poor maintainability: The existing development model adopts a design approach that strongly couples message processing logic with interface controls. The two do not have a clear functional boundary. Core logic such as message parsing and sending / receiving control are directly related to the input boxes, buttons and other controls on the interface. When modifying the interface layout (such as adjusting the position of controls) or the interaction logic (such as adding a secondary confirmation pop-up), the corresponding message processing code must be modified simultaneously. Optimizing the message parsing algorithm or adjusting the sending / receiving logic will also affect the normal display and operation of the interface controls. This results in excessively strong interrelationships between system modules. Once a fault occurs, it is difficult to quickly locate the root cause, which greatly reduces maintainability. At the same time, it is also impossible to flexibly expand new message protocols or interface functions, thus limiting scalability. ④ Insufficient data processing capabilities: When faced with a large number of concurrent messages, the current process of message reception, parsing, and interface display mostly adopts a synchronous processing approach. If a sudden surge of large-volume messages (such as status reports when devices are deployed in batches) floods in, data can easily accumulate in memory, causing software lag and an inability to respond to operation commands in a timely manner. In severe cases, memory overflow or CPU resource exhaustion can lead to program crashes, failing to guarantee the stability and robustness of the system under high-concurrency scenarios.

[0003] In summary, existing message development and debugging solutions suffer from problems such as repetitive work, poor protocol adaptation flexibility, high module coupling, and lack of dynamic debugging capabilities. These problems not only lead to low integration and debugging efficiency and a surge in manpower and time costs, but also fail to meet the actual needs of frequent communication protocol changes and diverse debugging scenarios. They have become a key bottleneck restricting the efficient integration and debugging of messages and interfaces. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by providing a custom interface integration and debugging method for messages. This method allows for flexible updates to the core parameters and processing rules of socket proxy services and message processing services by directly modifying configuration files (without recompiling the code). It automatically adapts to the parsing and combination requirements of different protocol messages, quickly integrates multiple message protocols, automatically generates interface controls, and supports dynamic adjustment of message logic. This avoids repetitive development work, eliminates the need for repeated code compilation, and achieves low coupling, greatly improving the debugging efficiency of messages.

[0005] The objective of this invention is achieved through the following approach: A custom interface integration debugging method for messages includes the following steps: 1) Generate a socket proxy service based on the socket configuration file to manage sockets and proxy the unified sending and receiving of messages; 2) Based on the message protocol file, the message is abstracted into individual class objects to generate a message processing service, which is used to parse, combine and forward the message; 3) Based on the UI control configuration file, parse the message into UI control objects; 4) Based on the dynamic adjustment parameter file, add dynamic adjustment processing to the message processing service to perform additional logic processing on the message and adapt to message debugging needs. 5) Using the UI control object as the front end, and the dynamically adjusted message processing service and socket proxy service as the back end, establish a data connection between the UI control object and the socket proxy service and message processing service to obtain a UI control that can be debugged by the GUI.

[0006] This invention generates a multi-threaded socket proxy service (including message queue data smoothing and socket priority allocation) based on the socket configuration file using a factory proxy pattern. It automatically parses and combines messages according to the message protocol file (abstracting messages into class objects). Based on a dynamically adjusted parameter file, it loads message filtering / conditional judgment / combination and sending logic into the message processing service. It generates front-end and back-end separated interface control objects—a human-computer interaction interface (front-end responsible for display, back-end responsible for data processing)—based on the control configuration file. By establishing data connections between the interface control objects and the socket proxy service and message processing service, a GUI-debugging interface control is obtained. It supports flexible updates to the core parameters and processing rules of the socket proxy service and message processing service by modifying the configuration file (without recompiling the code), automatically adapting to the parsing and combination requirements of different protocol messages, avoiding repetitive development work, greatly improving message-interface debugging efficiency, and saving labor costs.

[0007] Preferably, in step 1), the socket configuration file includes socket protocol and type configuration, basic communication parameter configuration, control and priority configuration, and message queue configuration.

[0008] Preferably, in step 2), the message protocol file includes a message basic identifier, message field definitions, message parsing rules, message combination rules, and message-entity object mapping rules.

[0009] Preferably, in step 3), the interface control configuration file includes message-control mapping relationship, control basic attributes, control interaction rules, and control business filtering rules.

[0010] Preferably, in step 4), the dynamically adjusted parameter file includes logical triggering conditions, message filtering rules, message condition judgment rules, message combination sending rules, and secondary confirmation / multi-key operation rules.

[0011] Preferably, in step 1), the service content of the socket service specifically includes: ① It provides unified sending and receiving proxy processing for messages of multiple protocol types, covering the needs of different communication scenarios; ② It uses independent threads to perform open, close, receive, and send operations on sockets, enabling multiple sockets to run in parallel without interference. ③ For resource contention scenarios involving multiple sockets, priority allocation is achieved by setting the order of signal and slot response connections and thread priorities, ensuring that high-priority communication tasks are executed first; ④ Adopting the producer-consumer pattern, the socket proxy service is used as the producer and the asynchronous processing thread is used as the consumer. The message queue is used to cache the message data in real time and smooth out the data spikes, so as to avoid the software lag or crash caused by data accumulation and ensure the stability and robustness of the system operation.

[0012] The socket service of this invention adopts a factory proxy model, decoupling socket creation and usage. It can independently generate and proxy sockets for various protocols (such as UDP, TCP, MQTT, etc.) based on configuration files. Socket parameters (IP, port, protocol type, etc.) can be adjusted without modifying code or recompiling, significantly improving the adaptability and flexibility of the socket proxy service. Simultaneously, sockets support independent control (opening, closing, sending / receiving operations), capable of performing operations such as opening, closing, data reception, and data transmission. Furthermore, a priority allocation mechanism based on an event-response model is designed, which can adjust connection order and thread priority through signal and slot responses, effectively handling resource contention scenarios. In addition, combined with the "producer-consumer" model of message queues, it enables real-time message caching and data smoothing, avoiding software lag or crashes caused by large data influxes, significantly enhancing the stability and robustness of communication transmission and reception.

[0013] Preferably, in step 2), the service content of the message processing service specifically includes: ① Message parsing: According to the message parsing rules in the message protocol file, the message is abstracted into a class of individual objects in the program, and the message fields are transformed into attributes of the class of individual objects, so that the message parsing process is transformed into the parsing of class of individual objects; ② Automatic message combination and sending: Extract multiple attribute values ​​from individual objects of the class, combine the attribute values ​​into raw message data that meets the socket sending requirements, and pass the raw message data to the socket proxy service.

[0014] This invention abstracts a single message protocol into a class-based individual object (message entity object) in the program by defining formatted message writing and parsing rules, and maps message fields to object attributes, thus realizing "object-oriented" message processing. On the one hand, message parsing (loading parsing rules into the runtime environment, supporting polymorphic parsing) and combined sending (extracting message object attributes for free combination) can be automatically completed based on the message configuration file, without the need to repeatedly develop processing logic for different protocols. On the other hand, when it is necessary to adapt to a new message protocol or adjust an existing protocol, only the configuration file needs to be modified to achieve functional adaptation, without changing the core code, which greatly reduces the technical complexity and development workload of message protocol adaptation.

[0015] Preferably, in step 4), the dynamic adjustment process includes message filtering, message sending condition judgment, multi-message combination sending, message secondary confirmation, and multi-key operation. Each function is adapted to scenarios such as batch message testing (e.g., focusing on core data through message filtering), priority execution of key debugging tasks (e.g., ensuring priority through message sending condition judgment), collaborative debugging of multiple devices in industrial control (e.g., achieving linkage through multi-message combination sending), and preventing accidental touches in high-risk operations (e.g., increasing the safety threshold through message secondary confirmation and multi-key operation). It can meet the personalized debugging needs of fields such as industrial control and network communication testing.

[0016] The beneficial effects of this invention include the following: ① This invention generates a socket proxy service based on the socket configuration file, which can uniformly handle the sending and receiving of messages for multiple protocols such as TCP, UDP, and MQTT without the need to develop separate socket sending and receiving logic for each protocol. Based on the interface control configuration file, the message is parsed into an independent interface control object. The interface controls (such as input boxes and send buttons) are associated with the communication logic through configuration mapping, which can be reused across protocols. There is no need to customize a dedicated GUI interface for different scenarios such as software testing and simulation tooling, which can avoid developers performing homogeneous development repeatedly and reduce the waste of human and time resources. ② The message protocol processing logic (parsing rules, sending and receiving control) of this invention is decoupled from the core code. When the message protocol changes due to debugging needs, such as adding or removing fields or adjusting the format, only the message protocol file needs to be modified (updating message field definitions, parsing rules, etc.) or the parameter file needs to be dynamically adjusted (adjusting filtering, combination rules, etc.). There is no need to modify the message parsing code, sending and receiving control code, and interface interaction code one by one. Moreover, all configuration changes can take effect without recompiling the entire project. The operation process is simple, and it can quickly respond to protocol change requirements, greatly improving development and debugging efficiency. ③ This invention uses the interface control object as the front end, and the socket proxy service and message processing service together as the back end. The two are connected and linked through data. When modifying the interface layout (such as adjusting the position of the control), there is no need to modify the message processing code simultaneously. Optimizing the message parsing algorithm will not affect the normal operation of the interface control. This front-end and back-end separation mode means that when adding a new message protocol, only the corresponding configuration file needs to be supplemented, and when expanding the interface function, only the control configuration needs to be adjusted. The system has strong scalability, and when a fault occurs, the weak module correlation allows for quick location of the root cause, greatly improving maintainability. ④ This invention uses an independent thread to run the socket proxy service and uses a producer-consumer pattern message queue in the socket proxy service. The message queue is used to cache message data in real time and smooth out data spikes. When a sudden surge of large traffic messages (such as batch device online status reporting) occurs, it can avoid data accumulation in memory, prevent software lag or program crashes caused by memory overflow or CPU resource exhaustion, and ensure the stability and robustness of the system in high-concurrency scenarios.

[0017] Glossary: Qt refers to a cross-platform C++ application development framework.

[0018] Signal and Slot Mechanism: Signals and slots are one of the core mechanisms of the Qt framework, essentially an implementation of the observer pattern. When an event occurs (such as a button detecting that it has been clicked), the object that triggered the event emits a signal. This signal is transmitted like a broadcast signal and can be perceived by other objects. If an object needs to respond to this signal, it can bind the signal to a specific function (i.e., a slot function) of itself using the `connect` function. When the signal is emitted, all slot functions bound to that signal will be automatically called (callback), thus completing the event response.

[0019] Socket Proxy Service: In this invention, the "Socket Proxy Service" is the core service module responsible for integrating the multi-protocol message communication sending and receiving logic. It can handle message sending and receiving proxy processing for multiple types of protocols such as UDP, TCP, MQTT, HTTP, and WebSocket. It can realize independent generation, independent proxying, and flexible configuration of sockets (the IP, port, protocol type, and other parameters can be adjusted without modifying the code).

[0020] Message processing service: In this invention, the "message processing service" is the core service module responsible for message parsing, combination and entity mapping. It is used to abstract a single message into a class object in the program (such as the QObject class based on Qt), and the message fields are mapped to the attributes of the class object, and a unique mapping index of "message-entity object" is established (such as through message ID management).

[0021] A socket is an interface / endpoint used in network programming to enable inter-process communication on different hosts (or the same host). It is a set of programming interfaces (APIs) provided by the operating system. Essentially, it is a "communication tool" that identifies a unique process on the network by binding an IP address and port number, enabling data to be accurately transmitted between different processes.

[0022] A message is a data unit transmitted over a network. It contains information that needs to be transmitted (such as text, instructions, binary data, etc.) and is usually composed of a "header" (containing control information such as protocol identifiers and length) and a "body" (the actual content).

[0023] Factory Proxy Pattern: In this invention, the "Factory Proxy Pattern" refers to a composite design pattern that combines the "object creation logic" of the "Factory Pattern" with the "object access / business proxy logic" of the "Proxy Pattern." The "Factory Logic" dynamically generates socket instances that meet the requirements (such as sockets of different protocol types like UDP, TCP, and MQTT) based on the configuration file. The "Proxy Logic" then takes over the subsequent business processing of the sockets (such as data sending and receiving, event response, resource contention priority allocation, etc.), ultimately achieving flexible configuration, independent management, and reusability of the socket service. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the process of the present invention; Figure 2 This is a structural diagram of the message-interface rapid integration and debugging scheme in an embodiment of the present invention; Figure 3 This is a diagram of the socket service structure in an embodiment of the present invention; Figure 4 This is a message processing service structure diagram in an embodiment of the present invention; Figure 5 This is a diagram of the dynamic logic processing structure in an embodiment of the present invention; Figure 6 This is a diagram illustrating the message-control mapping generation structure in an embodiment of the present invention. Detailed Implementation

[0025] like Figures 1 to 6 As shown, a custom interface integration debugging method for messages includes the following steps: 1) Generate a socket proxy service based on the socket configuration file; 2) Based on the message protocol file, abstract the message into individual class objects to generate message processing services; 3) Based on the UI control configuration file, parse the message into independent UI control objects; 4) Add dynamic adjustment processing to the message processing service based on the dynamic adjustment parameter file; 5) Using the UI control object as the front end and the socket proxy service and message processing service as the back end, establish a data connection between the UI control object and the socket proxy service and message processing service to obtain a UI control that can be debugged by the GUI.

[0026] Based on the above method, the following is an example: Before generating UI controls, the development environment needs to be set up. This example uses Qt 5.14 or later (supporting QThread, QObject, signal and slot mechanism, and QSettings configuration reading), and writes four types of configuration files (in INI, XML, or JSON format), including: ① Socket configuration file: Socket protocol and type configuration, basic communication parameter configuration, control and priority configuration, message queue configuration, among which: Socket protocol and type configuration: Define the socket protocol type to be proxied, including UDP, TCP, MQTT, HTTP, WebSocket, etc.; Basic communication parameter configuration: including core send and receive parameters such as IP address, port number, connection timeout, and data encoding method (e.g., ASCII / binary); Control and priority configuration: Independent control permissions for "open / close / receive / send" of a single socket, and priority rules for resource contention (signal and slot connection order, thread priority); Message queue configuration: queue cache capacity, data retrieval frequency, etc., used to achieve data smoothing and real-time processing.

[0027] ② Message protocol file: includes basic message identifiers, message field definitions, message parsing rules, message assembly rules, and message-entity object mapping rules, among which, Basic message identifiers: a unique ID, name, and type (request / response / notification) for each message; Message field definitions: field name (e.g., device number, temperature value), data type (int / string / float), length, default value, constraints (e.g., temperature range -40~85℃); Message parsing rules: field order, separator, checksum (CRC / checksum), supporting runtime polymorphic parsing; Message combination rules: the order of combining multiple messages and the logic for extracting fields; Message-Entity Object Mapping Rules: The correspondence between message fields and Object properties within the program is managed by numbering the mapping index.

[0028] ③ Dynamically adjust configuration files: including logical trigger conditions, message filtering rules, message condition judgment rules, message combination sending rules, and secondary confirmation / multi-key operation rules, among which, Logical trigger conditions: Define scenarios that trigger additional logic using the message ID as an index (such as triggering filtering after receiving a message with ID=001, or triggering condition judgment before sending). Message filtering rules: Field value filtering (e.g., "Messages with temperature > 85℃ are filtered"), Keyword filtering (e.g., messages containing "error code" are not sent); Message condition judgment rules: conditional expression (e.g., "if battery level < 10%, trigger secondary confirmation") and result operation (send after confirmation / discard directly); Message combination sending rules: dynamic combination trigger conditions (e.g., "after receiving a response with ID=002, combine ID=003 / 004 and send"), number of retries on failure; Secondary confirmation / multi-key operation rules: Logic that requires manual intervention (such as popping up a confirmation box before sending the 'device restart' message, or sending a combination of 'confirm + send' multi-key triggers).

[0029] ④ UI control configuration file: This includes message-control mapping relationships, basic control properties, control interaction rules, and control business filtering rules. Message-control mapping relationship: correspondence between message ID and control ID, correspondence between message type and control type (e.g., request type → button, numeric type → input box); Basic control properties: layout (position X / Y, size, grouping), style (color, font, display text), initial state (enabled / disabled, default value); Control interaction rules: trigger actions (e.g., clicking a button → sending the corresponding message, modifying an input box → updating the message field), feedback logic (e.g., successful sending → control turns green, failed sending → control blinks); Control business filtering rules: input filtering (e.g., input boxes only allow numbers), access control (e.g., administrators can modify controls, while ordinary accounts can only view them).

[0030] After writing the above configuration files, this embodiment reads each configuration file using Qt's QSettings class and encapsulates each step of the above method to obtain the following modules: Socket service module: corresponding to step 1), responsible for generating a factory proxy mode socket proxy service according to the socket configuration file, realizing independent thread operation, priority allocation, and message queue data peak shaping; Message processing module (corresponding to step 2): responsible for abstracting messages into individual class objects according to the message protocol file, and realizing automatic message parsing, combination and transmission; In this embodiment, the message processing module is initialized after the socket service. The module has a set of rules for writing and parsing message configuration files, which enables the message parsing process to have certain regularity and logic.

[0031] Dynamic adjustment module (corresponding to step 3): responsible for loading the dynamic adjustment configuration file to realize dynamic processing of message filtering, condition judgment, and combined sending; Interface generation module (corresponding to step 4): responsible for generating controls and binding message objects according to the interface control configuration file, realizing the separation of front-end and back-end interface display and data processing.

[0032] The specific process of constructing a UI control capable of GUI debugging using the above modules in this embodiment is as follows: 1) First, when a Qt program starts, it uses the socket configuration file and a factory proxy pattern to generate a socket proxy service (i.e., initialize the socket service module) using the socket service module. Figure 3 As shown, the socket proxy service supports sockets and protocols including UDP, TCP, MQTT, HTTP, and WebSocket.

[0033] In this embodiment, the socket proxy service generates corresponding sockets based on actual message-interface debugging requirements and performs full lifecycle control and scheduling on the generated sockets. This includes independent control of the sockets (opening, closing, receiving, and sending operations), event-response-based state management (such as immediate response when an event is triggered), and priority allocation of multiple socket proxies (resolving resource contention, such as priority scheduling of signal slot connections and thread resources), ensuring stable operation of the sockets according to debugging requirements. Furthermore, the socket proxy service also undertakes the core business processing responsibilities for message data, namely, proxying the receiving and sending of messages, and combining message queues (based on a producer-consumer pattern) to achieve separation of "data receiving and processing," ensuring real-time data processing and data smoothing (avoiding program crashes due to excessive data volume), ultimately completing the message data business processing at the socket level. The specific service content of the socket service includes: ① It provides unified sending and receiving proxy processing for messages of multiple protocol types (supported protocol types include UDP, TCP, MQTT, HTTP, WebSocket, etc.) to cover the needs of different communication scenarios; ② Each socket corresponds to an independent thread, which runs independently and performs open, close, receive, and send operations on the socket, so as to achieve non-interference parallel operation of multiple sockets; ③ For resource contention scenarios involving multiple sockets, priority allocation is achieved by setting the order of signal and slot response connections and thread priorities, ensuring that high-priority communication tasks are executed first; ④ Adopting the producer-consumer pattern, the socket proxy service is used as the producer and the asynchronous processing thread is used as the consumer. The message queue is used to cache the message data in real time and smooth out the data spikes, so as to avoid the software lag or crash caused by data accumulation and ensure the stability and robustness of the system operation.

[0034] It is worth noting that the asynchronous processing thread is created on demand and automatically destroyed after the message data processing is completed. This enables real-time data processing and data smoothing, preventing program crashes caused by excessive data volume.

[0035] In this embodiment, an event-response-based design (i.e., a corresponding response is triggered when an event is activated) is adopted to control and manage the socket, including configuration and parsing, thereby achieving orderly processing and response to events, as detailed below: S1) By using the event transmitter, various events generated during the operation of the socket (such as socket connection requests, data reception notifications, and instruction events triggered by user operations) are inserted into the event queue, providing an initial entry point for subsequent event processing and ensuring that events are not lost.

[0036] S2) The event queue is responsible for storing and sorting events to be processed. The event processing queue is maintained according to the order in which events are triggered, ensuring the orderliness of event processing and avoiding logical chaos caused by disordered events.

[0037] S3) continuously retrieves events to be processed from the event queue in an infinite loop and accurately distributes the retrieved events to the corresponding event handling functions. This is the core step to ensure that events are processed in a timely manner and are not missed.

[0038] S4) Events are responded to through event handling functions. The specific actions that the application needs to perform after the event is triggered are predefined within the event handling functions. For example, when the left mouse button on the interface is clicked, the actions that the application needs to perform, such as "calling the socket to send the message" and "updating the interface sending status", are all explicitly defined in this type of function.

[0039] It is worth noting that in traditional message debugging, protocol changes and parameter modifications require code recompilation, resulting in repetitive work and low efficiency. In this embodiment, frequently adjusted parameters such as IP address, communication protocol, communication port, and priority are stored in a socket configuration file. When parameter modifications are needed, only the modified socket configuration file needs to be reloaded for the parameter changes to take effect directly, without the need to compile code, thus significantly shortening the parameter adjustment cycle. like Figure 4 As shown, according to the message protocol file, the message processing module abstracts the message into individual class objects to generate a message processing service. Qt's Meta-ObjectSystem is the core mechanism for implementing its dynamic features (such as signals and slots, dynamic properties). The normal operation of this system depends on the following three core elements: Base class (QObject): As the unified base class for all objects that need to use the meta-object system, it provides objects with the basic ability to access the meta-object system and is a prerequisite for the meta-object features to take effect.

[0040] Macro (Q_OBJECT): Must be explicitly declared in the private member area of ​​a class. Its purpose is to "activate" the core features of the meta-object system for that class, including dynamic property definition, support for signal and slot mechanisms, etc. If the class does not declare this macro, it cannot use the key functions of the meta-object system.

[0041] Meta-Object Compiler (moc): As a Qt-specific compilation aid, it automatically scans the code for classes that inherit from QObject and declare the Q_OBJECT macro, and generates additional code for each class to implement meta-object features (such as meta-object information, underlying binding logic for signals and slots), ensuring that meta-object functions can be called normally at runtime.

[0042] In this embodiment, when abstracting messages into individual objects, Qt's meta-object system is used. The specific operation process is as follows: First, when the message processing module abstracts the message into independent data entities (i.e., individual message objects) in the program, each data entity uses a Qt Object as its carrier. Second, the core field attributes of the message (such as field type, numerical range, function identifier, etc.) are extracted and abstracted and classified. These attributes and corresponding original data are then assigned to the QObject object, so that the QObject object has the complete data characteristics of the original message, thereby realizing the mapping transformation from "original message to QObject object" (i.e., the objectification of message data). Finally, to ensure the traceability of the association between the message and the corresponding data entity, a two-way mapping index between the original message and the QObject entity is established, and the mapping relationship is uniformly managed through a unique number, providing index support for the standardized processing of subsequent message addition, deletion, modification, and query.

[0043] In this embodiment, after establishing the mapping relationship between messages and QObject data entity objects (including bidirectional index management implemented through unique numbers), any data processing operation performed on any original message (such as modifying field content, extracting key information, deleting invalid data, and verifying integrity) can be transformed into an operation on its corresponding QObject data entity object. Specifically, this covers adding, deleting, updating, and querying attributes of the data entity. This approach, relying on the characteristics of the Qt meta-object system and the unique mapping relationship between messages and entity objects, realizes the transformation from traditional procedural message data processing (which requires writing processing logic separately for different message protocols) to a data object-oriented processing mode.

[0044] The above-described message object-oriented design approach follows preset message entity parsing rules during the message reception phase (the rules are derived from the message protocol configuration file, which clarifies the correspondence between message fields and QObject entity attributes, data format verification standards, and parsing priorities, etc.). This "translates" the raw message data into standardized QObject data entity operations, eliminating the need to develop separate processing logic for raw messages of different protocol types such as UDP and TCP or with different field structures. Ultimately, this achieves unified (with QObject data entities as the core processing unit), standardized (strictly following the parsing and operation standards defined in the configuration file), and streamlined (fixed data processing flow: raw message reception → parsing into entity objects according to rules → entity object operation → processing result feedback) message processing.

[0045] In this embodiment, the service content of the message processing service specifically includes: ① Message parsing: According to the message parsing rules in the message protocol file, a single message is abstracted into a class individual object (message entity object) in the program, and the message fields are transformed into attributes of the class individual object, so that the message parsing process is transformed into the parsing of the class individual object; ② Automatic message combination and sending: Extract multiple attribute values ​​from individual objects of the class, combine the attribute values ​​into raw message data that meets the socket sending requirements, and pass the raw message data to the socket proxy service.

[0046] 3) Using the interface generation module, based on the interface control configuration file, the message is parsed into independent interface control objects, and controls with a unified style are generated.

[0047] In this embodiment, the interface control configuration file includes a custom set of message-control generation specifications (also known as message-control parsing rules), which parses messages into independent control individuals. The message-control parsing rules include a mapping relationship between message types and control types, as well as a set of custom control styles, to generate corresponding interface control objects based on messages. The specific process is as follows: read the message definition data in the configuration file, translate it into the corresponding control generation information, and generate the controls in the expandable area of ​​the interface by group, type, and rules.

[0048] 4) Based on the dynamic adjustment parameter file, use the dynamic adjustment module (initialized after the socket service and applied before message sending) to add dynamic adjustment processing to the message processing service, including message filtering, message sending condition judgment, and multi-message combination sending: In this embodiment, the dynamically adjusted parameter file includes a set of custom message logic processing rules and a set of custom logic file parsing rules. The message logic processing rules include message filtering, condition judgment, message combination, secondary confirmation, multi-key operation, etc.; the logic file parsing rules use the message ID as the logical processing index filtering condition.

[0049] Based on the front-end and back-end separation design, the interface control object is used as the front-end, and the socket proxy service and message processing service are used as the back-end. A data connection is established between the interface control object and the socket proxy service and message processing service to obtain the interface control that can be debugged by the GUI.

[0050] In summary, this invention takes configuration-driven and modular decoupling as its core design logic. By constructing four standardized configuration systems—socket configuration files, message protocol files, interface control configuration files, and dynamically adjustable parameter files—and combining technologies such as the factory proxy model and the producer-consumer model, it achieves flexible adaptation of the entire process from message sending and receiving, parsing and combining to interface generation. This solves the core technical pain points of traditional message-interface debugging, such as "severe repetitive development, high protocol adjustment costs, high module coupling, and weak high-concurrency data processing capabilities."

[0051] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications made to the present invention by those skilled in the art without departing from the spirit of the present invention shall fall within the protection scope of the present invention.

Claims

1. A custom interface integration debugging method for messages, characterized in that, Includes the following steps: 1) Generate a socket proxy service based on the socket configuration file to manage sockets and proxy the unified sending and receiving of messages; 2) Based on the message protocol file, the message is abstracted into individual class objects to generate a message processing service, which is used to parse, combine and forward the message; 3) Based on the UI control configuration file, parse the message into UI control objects; 4) Based on the dynamic adjustment parameter file, add dynamic adjustment processing to the message processing service to perform additional logic processing on the message and adapt to message debugging needs. 5) Using the UI control object as the front end, and the dynamically adjusted message processing service and socket proxy service as the back end, establish a data connection between the UI control object and the socket proxy service and message processing service to obtain a UI control that can be debugged by the GUI.

2. The method according to claim 1, characterized in that: In step 1), the socket configuration file includes socket protocol and type configuration, basic communication parameter configuration, control and priority configuration, and message queue configuration.

3. The method according to claim 1, characterized in that: In step 2), the message protocol file includes message basic identifier, message field definition, message parsing rules, message combination rules, and message-entity object mapping rules.

4. The method according to claim 1, characterized in that: In step 3), the interface control configuration file includes message-control mapping relationship, basic control properties, control interaction rules, and control business filtering rules.

5. The method according to claim 1, characterized in that: In step 4), the dynamically adjusted parameter file includes logical triggering conditions, message filtering rules, message condition judgment rules, message combination sending rules, and secondary confirmation / multi-key operation rules.

6. The method according to claim 1, characterized in that: In step 1), the specific service content of the socket service includes: ① It provides unified sending and receiving proxy processing for messages of multiple protocol types, covering the needs of different communication scenarios; ② It uses independent threads to perform open, close, receive, and send operations on sockets, enabling multiple sockets to run in parallel without interference. ③ For resource contention scenarios involving multiple sockets, priority allocation is achieved by setting the order of signal and slot response connections and thread priorities, ensuring that high-priority communication tasks are executed first; ④ Adopt the producer-consumer pattern, with the socket proxy service as the producer and the asynchronous processing thread as the consumer. The message queue is used to cache message data in real time and smooth out data spikes, so as to avoid data accumulation that may cause software lag or crash.

7. The method according to claim 1, characterized in that: In step 2), the specific service content of the message processing service includes: ① Message parsing: According to the message parsing rules in the message protocol file, the message is abstracted into a class of individual objects in the program, and the message fields are transformed into attributes of the class of individual objects, so that the message parsing process is transformed into the parsing of class of individual objects; ② Automatic message combination and sending: Extract multiple attribute values ​​from individual objects of the class, combine the attribute values ​​into raw message data that meets the socket sending requirements, and pass the raw message data to the socket proxy service.

8. The method according to claim 1, characterized in that: In step 4), the dynamic adjustment process includes message filtering, message sending condition judgment, multi-message combination sending, message secondary confirmation, and multi-key operation.

Images