Standardized framework code generation method for Qt application program development

Abstract

The invention discloses a standardized framework code generation method for Qt application program development. The standardized framework code generation method comprises the steps that a KjDataStuct source code file is used for achieving data structure definition, message type definition and public buffer area definition of standardized framework codes for Qt application program development; the KjDb source code file is used for providing a universal database management class to realize database operation; the KjDemo source code file is used for providing a demonstration case used by a standardized framework code developed by a Qt application program; the KjTransfer source code file is used for realizing background udp communication data transceiving processing and serial port stream data processing. The invention provides a set of comprehensive, systematic and efficient standardized framework codes for Qt application program development, and fills the blank of existing Qt application program development software architecture and development standard specifications.

Description

Technical Field

[0001] This invention relates to the field of Qt application development technology, and more specifically, to a standardized framework code generation method for Qt application development. Background Technology

[0002] Qt applications excel in applications such as serial communication and UDP short message transmission due to their cross-platform consistency, thread management capabilities, low-level API encapsulation capabilities, and development efficiency. However, there is currently no universal framework for quickly generating basic application code in Qt application development, and most developers build their own based on existing modules. While Qt provides a rich set of functional modules for application development, such as data structure classes like QList, QVector, and QMap to meet most common data organization and storage needs; the QtSql module for database operations, supporting various databases, with the QSqlDatabase class for managing database connections and QSqlQuery for executing SQL queries; network programming modules for background communication, such as QUdpSocket for easy UDP communication, QThread for multithreaded processing, and QTimer for timer functions, developers still need to design and implement their own logic for background communication, data transmission, reception, and processing based on these modules and classes; and the QSerialPort module for serial communication, supporting cross-platform serial port operations and facilitating opening, closing, reading, and writing of serial ports, but filtering interference data and reassembling correct data packets after receiving stream data need to be implemented by the developers themselves.

[0003] Therefore, in the field of Qt application development, there is currently no mature framework that can integrate the four key elements of data structure definition, database operations, background communication data transmission and reception, and serial stream data processing. This often forces developers to build the software architecture from scratch, which is not only time-consuming and labor-intensive but also inefficient. Significant differences in software architecture between different applications, coupled with a lack of unified standards and specifications, greatly reduce code portability and readability, causing numerous inconveniences for subsequent maintenance, expansion, and team collaboration. Summary of the Invention

[0004] To address the problems existing in the prior art, this invention provides a standardized framework code generation method for Qt application development, offering a comprehensive, systematic, and efficient standardized framework code for Qt application development, filling the gap in existing Qt application development software architecture and development standards.

[0005] To achieve the above technical objectives, the present invention adopts the following technical solution: a standardized framework code generation method for Qt application development, comprising generating KjDataStruct source code files, KjDb source code files, KjDemo source code files, and KjTransfer source code files;

[0006] The KjDataStruct source code file is used to implement the data structure definition, message type definition, and public buffer definition of the standardized framework code for Qt application development.

[0007] The KjDb source code files are used to provide general database management classes to implement database operations;

[0008] The KjDemo source code file is used to provide a demonstration case of using standardized framework code for Qt application development;

[0009] The KjTransfer source code file is used to implement background UDP communication data transmission and reception processing as well as serial port stream data processing.

[0010] Furthermore, the data structure definition is used to customize the data structure and uniformly place it in struct.h; the message type definition is used to uniformly standardize the message types used by Qt applications using an enumeration structure; the public buffer is a unit used to save data packets received in background UDP communication. The public buffer definition includes: defining the maximum length of the public buffer through the MAXDATABUFFERSIZE macro, defining the unit index for writing to the public buffer through writePos, defining the unit index for reading from the public buffer through readPos, the data type of each unit is DataUnit, and the element of each unit contains a dynamically allocated byte array and the length of the space.

[0011] Furthermore, the exemplary cases include:

[0012] The callback function definition for data parsing and processing after serial port data reading includes:

[0013] When there is only one serial port device, register it using the global serial port read / write and data processing callback function;

[0014] When multiple serial port devices exist, register callback functions for each serial port read / write and data processing;

[0015] The callback function definition for data parsing and processing after receiving data in the background UDP communication includes:

[0016] When the background UDP communication thread reads data in the main thread and processes data in the child thread, it adopts a fixed number of child threads and registers callback functions for communication data processing in the child threads.

[0017] The background UDP communication thread reads data in the main thread and processes data in a child thread. It dynamically adjusts the number of child threads by monitoring the usage rate of the shared buffer through the thread pool, and dynamically adjusts the size of the receive buffer by monitoring the usage rate of the receive buffer through the thread pool. By setting the communication data processing callback function of the thread pool, the callback function for communication data processing in the child thread is registered when the number of child threads is increased.

[0018] Furthermore, the background UDP communication data transmission and reception processing includes: the CommunicationManage class, the CommunicationHandleThread class, and the CommunicationThreadPool class;

[0019] The CommunicationManage class places the received data in a public buffer;

[0020] The CommunicationHandleThread class opens a sub-thread to read data from the public buffer and calls the communication data callback function registered by the secondary developer to parse and process the data;

[0021] The CommunicationThreadPool class dynamically increases or decreases the number of CommunicationHandleThread communication data processing sub-threads based on the utilization rate of the storage units in the public buffer, and dynamically increases or decreases the size of the listening socket receive buffer of the CommunicationManage object based on the utilization rate of the socket receive buffer.

[0022] Furthermore, the CommunicationManage class is used to receive data as follows: when applying for a socket, the local machine acts as the server. The port number passed when defining the CommunicationManage class object is used as the port number for the server to listen on. The socket is bound to this port to receive and listen for data. The start method is called to bind the readyRead signal of QUdpSocket to the recvMsg method to read the data sent by the client.

[0023] Furthermore, the CommunicationManage class calls the sendMsg() method to send data. The input parameters of the sendMsg() method include: the byte stream data to be sent, the destination IP, and the destination port number.

[0024] Furthermore, the communication data callback function is registered by calling the RegisterCallback(CallbackCommunicationFunc func) method, where CallbackCommunicationFunc represents a pointer to the communication data callback function. The pointer to the communication data callback function is in the form of typedef int(*CallbackCommunicationFunc)(char*data), indicating that the input parameter of the communication data callback function is a char pointer, pointing to the header byte of a complete data packet.

[0025] Furthermore, the serial port stream data processing includes: the SerialPortManager class and the SerialReadThread class;

[0026] The SerialPortManager class provides methods for setting serial port parameters, opening and closing the serial port, sending data, and receiving data.

[0027] The SerialReadThread class has a member variable mySerail of type SerialPortManager, which is used to store the serial port device of type SerialPortManager operated in the SerialReadThread serial port data reading and processing thread.

[0028] The SerialReadThread class reads serial port data by listening to the serial port device on the member variable mySerail of type SerialPortManager, and calls the serial port data processing callback function registered by the secondary developer to parse and process the data.

[0029] Furthermore, the serial port data processing callback function is registered by calling the RegisterCallback(CallbackFunc func) method, where CallbackFunc represents a pointer to the serial port data processing callback function. The pointer to the serial port data processing callback function is in the form of typedef int(*CallbackFunc)(char*data,int offset,int len), indicating that the input parameters of the serial port data processing callback function include: a char pointer pointing to the internal circular buffer of the thread, the offset of the current complete data packet data, and the data length. The current complete data packet is len bytes starting from offset in the space pointed to by data.

[0030] Furthermore, it includes the following steps:

[0031] Verify that the QtFrameWork directory exists in the / home directory of the Linux system. If not, install the standardized framework code for Qt application development. Otherwise, parse the installation path of the standardized framework code for Qt applications and the SHA-256 hash values ​​of the KjDataStruct, KjDb, KjTransfer, and KjDemo source code files from the " / home / QtFrameWork / kjconfig.ini" configuration file.

[0032] Check each source code file provided by the standardized framework code to see if it exists. If not, clear the QtFrameWork directory and copy the KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders from the installation path to the / home / QtFrameWork directory. Otherwise, determine if all source code files are normal by judging their size and SHA-256 hash value. If not, clear the / home / QtFrameWork directory and copy the KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders from the installation path to the / home / QtFrameWork directory.

[0033] Based on the project path selected by the secondary developer, copy the KjDataStruct source code folder, KjDb source code folder, KjTransfer source code folder, and KjDemo source code folder from the / home / QtFrameWork directory to the project path.

[0034] Compared with existing technologies, the present invention has the following beneficial effects: The standardized framework code generation method of the present invention for Qt application development integrates data structure definition, database operations, background UDP communication data transmission and reception processing, and serial port stream data processing by generating KjDataStruct source code files, KjDb source code files, KjDemo source code files, and KjTransfer source code files. This greatly improves development efficiency, reduces repetitive work, and allows developers to focus more on the implementation of core business logic. At the same time, it can also ensure architectural consistency between different applications, improve code portability and readability, promote team collaboration and code sharing, provide strong support for the rapid development and high-quality delivery of Qt applications, and promote the development of Qt development technology towards a more standardized and efficient direction. Furthermore, this invention provides three classes—CommunicationManage, CommunicationHandleThread, and CommunicationThreadPool—for background UDP communication data transmission and reception, enabling separate processing of data reception and processing to improve concurrency performance. For serial port data transmission and reception, this invention provides two classes—SerialPortManager and SerialReadThread. The SerialPortManager class is responsible for serial port configuration and management, while the SerialReadThread class is responsible for serial port data reading and processing. Through centralized management and asynchronous reading, stuttering caused by serial port issues is reduced. Through the design of communication and serial port processing classes, concurrency performance and system stability are improved respectively. In the fields of industrial control, IoT, and desktop development where Qt is widely used, this invention can meet the needs of enterprises for rapid development, cost reduction and efficiency improvement, and enhanced software quality, and has broad market prospects. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the background UDP communication data reception process of the present invention;

[0036] Figure 2 This is a schematic diagram of the background UDP communication data processing process of the present invention;

[0037] Figure 3 This is a schematic diagram of serial port data packet assembly and callback of the present invention;

[0038] Figure 4 This is a flowchart illustrating the standardized framework installation process for Qt application development according to the present invention.

[0039] Figure 5 This is a flowchart of the standardized framework code generation method for Qt application development according to the present invention;

[0040] Figure 6 This is a schematic diagram illustrating the unloading of the standardized framework for Qt application development according to the present invention. Detailed Implementation

[0041] The technical solution of the present invention will be further explained and described below with reference to the accompanying drawings.

[0042] To provide a comprehensive, systematic, and efficient standardized framework code for Qt application development, this invention generates KjDataStruct, KjDb, KjDemo, and KjTransfer source code files. The KjDataStruct source code file defines the data structures, message types, and common buffers of the standardized framework code for Qt application development, facilitating centralized management and enabling calls from secondary development business classes or other service classes generated by the standardized framework. The KjDb source code file provides a general database management class to implement database operations, which can be called by secondary development business classes. The KjDemo source code file provides a demonstration case of using the standardized framework code for Qt application development, serving as a reference for secondary developers. The KjTransfer source code file implements background UDP communication data transmission and reception processing and serial port stream data processing, which can be called by secondary development business classes. This invention integrates functions such as data structure definition, database operations, background UDP communication data transmission and reception processing, and serial stream data processing, greatly improving development efficiency, reducing repetitive work, and allowing developers to focus more on the implementation of core business logic. At the same time, it can also ensure architectural consistency between different applications, improve code portability and readability, promote team collaboration and code sharing, provide strong support for the rapid development and high-quality delivery of Qt applications, and promote the development of Qt development technology towards a more standardized and efficient direction.

[0043] In one technical solution of the present invention, the data structure definition is used to customize the data structure and uniformly place it in the struct.h specification; the message type definition is used to uniformly specify the message types used by Qt applications using an enumeration structure; the public buffer is a unit used to save data packets received in background UDP communication, and its data structure is a DataBuffer structure type. The public buffer definition includes: defining the maximum length of the public buffer through the MAXDATABUFFERSIZE macro, defining the unit index for writing to the public buffer through writePos, defining the unit index for reading from the public buffer through readPos, the data type of each unit is DataUnit, and the element of each unit contains a dynamically allocated byte array and the length of the space.

[0044] In one technical solution of this invention, the KjDb source code file provides a general database management class that supports multiple database types. It encapsulates the multi-step operation of setting database connection parameters into a one-step method based on data type. Furthermore, it combines JSON and XML, two common data structures, to support query methods that directly obtain result sets in JSON and XML formats, simplifying the database connection and operation process. For example, for SQLite databases, only the database type and database name need to be set; for server-type databases such as MySQL and DM, the database type, database name, hostname, username, password, and port number need to be set. The hostname, username, password, and port number can be omitted. When the hostname is not specified, the default value is localhost. When the username, password, and port number are not specified, the default username, password, and port number are used. The default username, password, and port number are different for each database and are set according to the database type.

[0045] In one technical solution of the present invention, exemplary cases include:

[0046] The callback function definition for data parsing and processing after serial port data reading includes:

[0047] When there is only one serial port device, register it using the global serial port read / write and data processing callback function;

[0048] When multiple serial port devices exist, register callback functions for each serial port read / write and data processing;

[0049] The callback function definition for data parsing and processing after receiving data in the background UDP communication includes:

[0050] When the background UDP communication thread reads data in the main thread and processes data in the child thread, it adopts a fixed number of child threads and registers callback functions for communication data processing in the child threads.

[0051] The background UDP communication thread reads data in the main thread and processes data in a child thread. It dynamically adjusts the number of child threads by monitoring the usage rate of the shared buffer through the thread pool, and dynamically adjusts the size of the receive buffer by monitoring the usage rate of the receive buffer through the thread pool. By setting the communication data processing callback function of the thread pool, the callback function for communication data processing in the child thread is registered when the number of child threads is increased.

[0052] The background UDP communication data transmission and reception processing includes the CommunicationManage, CommunicationHandleThread, and CommunicationThreadPool classes. To support the sending and receiving of both string data and byte stream data, these three classes need to encapsulate data according to a certain protocol when sending and receiving data. The encapsulation example provided by the standard framework uses 2 bytes to represent the length of the data packet, 1 byte to represent the information type, and then the actual data. If secondary developers follow this encapsulation protocol, the entire communication class can be used directly by referring to the example provided in the KjDemo source code file. If it is necessary to change the encapsulation protocol, the data parsing and encapsulation can be modified in the sending method, receiving method, and business processing callback method.

[0053] The CommunicationManage class places received data in a shared buffer. Specifically, the process of receiving data using the CommunicationManage class is as follows: When requesting a socket, the local machine acts as the server. The port number passed when defining the CommunicationManage object is used as the server's listening port number. The socket is bound to this port for data reception and listening. When secondary developers use the UDP communication service, they call the start method to bind the QUdpSocket's readyRead signal to the recvMsg method to read the data sent by the client. This simplifies socket request, port number binding, and signal and slot binding for the receive method. To improve concurrency performance when acting as a server, data reception and processing are handled separately, and only the read data is stored in the shared buffer.

[0054] like Figure 1The specific implementation process of the recvMsg method for receiving communication data is as follows: It receives the readyRead signal from the QUdpSocket, locks the shared buffer for writing, and if writePos equals MAXDATABUFFERSIZE, sets writePos to 0, enabling the cyclic use of the shared buffer. It checks whether there is free space in the shared buffer using writePos and readPos. If not, it releases the write lock on the shared buffer, relinquishing CPU execution rights; otherwise, it calculates the index for this data storage, reads data using readDatagram, parses the data length from the data stream, checks whether the data field of the storage unit dataunit at the current index is empty, and if not, releases and sets the data field of dataunit to empty. It then allocates space based on the data length, copies the data to the storage unit, increments writePos by 1 as the base value for the next storage index, releases the write lock on the shared buffer, and relinquishes CPU execution rights.

[0055] The `CommunicationHandleThread` class creates a child thread to read data from the shared buffer and calls the communication data callback function registered by the secondary developer to parse and process the data. Specifically, the communication data callback function is registered by calling the `RegisterCallback(CallbackCommunicationFunc func)` method, where `CallbackCommunicationFunc` represents a pointer to the communication data callback function. The communication data callback function registered by the secondary developer must conform to the form `typedef int(*CallbackCommunicationFunc)(char*data)`, indicating that the input parameter of the communication data callback function is a `char` pointer pointing to the header byte of a complete data packet. In this business processing callback function, the data length is first parsed according to the data encapsulation protocol. To ensure efficient use of the shared buffer, the data processing thread copies the data from the shared buffer to a temporary space and then releases the corresponding storage unit in the shared buffer. Therefore, the business processing callback function here also stores the data in the created child thread, which can prevent memory leaks.

[0056] like Figure 2The communication data processing process is as follows: The CommunicationHandleThread class controls the infinite loop and exit of the thread through a boolean control variable: When the boolean control variable is true, it reads the shared buffer, checks whether the data field of the storage unit on readPods is empty. If it is, it releases the read lock on the shared buffer and yields the CPU execution right; otherwise, it parses the data length of the data field, allocates the corresponding byte space, copies the data into the byte space, releases the data field resource, and assigns the data field of the storage unit dataunit to empty. It increments readPods by 1. If readPods equals MAXDATABUFFERSIZE after incrementing by 1, it sets readPods to 0, thus realizing the cyclic use of the shared buffer. Otherwise, it uses it as the base value for the next storage index, releases the read lock on the shared buffer, yields the CPU execution right, and uses the registered CallbackCommunicationFunc type communication data callback function for data processing.

[0057] The `CommunicationThreadPool` class dynamically increases or decreases the number of `CommunicationHandleThread` child threads for communication data processing based on the utilization rate of the shared buffer's storage units. It also dynamically increases or decreases the size of the `CommunicationManage` object's listening socket receive buffer based on its utilization rate. Specifically, it obtains the number of storage units in the shared buffer, determines idle storage units based on the read and write indices, and handles the read index acquisition within the `udp_handle_lock` global lock and the write index acquisition within the `udp_write_lock` global lock. Because the shared buffer is read and written to unit by unit in a loop, determining the utilization rate means determining the number of storage units that have stored data but have not yet been read, i.e., the number of storage units to be processed. There are two cases: when the write index is larger than the read index, the number of storage units to be processed is the write index position minus the read index position; when the write index is smaller than the read index, it means the write operation has restarted from the largest storage unit, and the number of storage units to be processed is the write index position plus the number of storage units in the shared buffer minus the read index position. Then, the pending processing rate of the common buffer is calculated, which is the number of pending storage units divided by the number of storage units in the common buffer. If the pending processing rate of the common buffer is less than the set utilization limit, it indicates that there are too many processing threads. In this case, `removeIdleHandleThread()` is called to reduce the number of processing threads, i.e., the `QList` method of the `CommunicationThreadPool` class.<CommunicationHandleThread*> The member variable `m_workerHandleThreads` stores the currently active processing threads. If the number of currently active threads is greater than the set minimum number of threads, the last `CommunicationHandleThread` object in `workerHandleThreads` is retrieved, and the control variable of that thread object is set to `false` to reduce the number of threads. If the pending rate of the public buffer is greater than the set usage limit, it means that there are relatively few processing threads. `createNewHandleThread()` is called to increase the number of processing threads. That is, if the number of currently active threads is less than the set maximum number of threads, a new `CommunicationHandleThread` pointer object is created. The business callback processing method is registered through the callback function set when the `CommunicationThreadPool` object is created. The newly created processing thread is started by setting the control variable to `true`, and the thread pointer object is added to the end of `workerHandleThreads` to increase the number of processing threads.

[0058] If the monitoring function of the listening socket receive data buffer of the CommunicationManage object is true and a CommunicationManage object to be monitored is set, the size of the listening socket receive data buffer will be adjusted by judging the rate of data to be processed in its listening socket receive data buffer. The static member variable `ReadBufferSize` of the `CommunicationManage` object stores the size of the data buffer for the listening socket, and it is updated immediately each time it is dynamically set. The static member variable `pendingDataSize` of the `CommunicationManage` object stores the number of bytes of data received by the listening socket that have not yet been processed. It is updated by increasing the number of bytes of data received by the listening socket each time the socket reads data, and by decreasing the number of bytes of data received by the processing thread after processing the data. The number of bytes of data received by the listening socket that have not yet been processed divided by the size of the listening socket's data buffer is the rate of data to be processed in the listening socket's data buffer. When adjusting, it is increased or decreased by 1 / 3. If the space after increasing or decreasing by 1 / 3 is still within the upper or lower limit of the set size of the data buffer, the actual space adjustment operation is performed by calling `QUdpSocket.setSocketOption()`, and the value of the static member variable `ReadBufferSize` of the `CommunicationManage` object is updated.

[0059] In one technical solution of this invention, the CommunicationManage class calls the sendMsg() method to send data. The input parameters of the sendMsg() method include: the byte stream data to be sent, the destination IP address, and the destination port number. This method integrates socket allocation, destination address encapsulation, data length parsing, and data transmission into a single method, greatly simplifying the process of sending data via QUdpSocket. To support high-speed transmission, the QUdpSocket object for sending data is defined inside the sendMsg() method. The sending port of the QUdpSocket object is randomly assigned, and the QUdpSocket object is automatically released after successful data transmission.

[0060] Serial port stream data processing includes the `SerialPortManager` and `SerialReadThread` classes. Since serial port data is stream data and transmission occurs randomly in multiple batches, a packet assembly method is needed, and byte-level encapsulation protocol bytes play a crucial role in this. A common approach is to add specific protocol bytes and the data packet length bytes at the beginning of the data packet. The standard framework provides the following packet assembly protocol: 0xAB and 0xAC represent a 2-byte header, a 1-byte data length, followed by the actual data content, and a 1-byte trailer, typically a checksum. If secondary developers follow this packet assembly protocol, the entire serial port class can be directly used, referring to the example provided in `KjDemo`. If the packet assembly protocol needs to be changed, the data packet assembly is modified in the `run()` method of `SerialReadThread`, and the serial port data processing callback methods can then unpack the data according to the actual packet assembly protocol.

[0061] The SerialPortManager class provides methods for setting serial port parameters, opening and closing the serial port, sending data, and receiving data. It can be used directly without any modification.

[0062] The `SerialReadThread` class has a member variable `mySerail` of type `SerialPortManager`, used to store the serial port devices operated on by the `SerialReadThread` thread for serial port data reading and processing. If there is only one serial port device, a global variable `global_serial` of type `SerialPortManager` is defined, and the constructor of `SerialReadThread` does not need to pass any actual parameters. If there are multiple serial port devices, the `SerialPortManager` variable is passed through the constructor of `SerialReadThread`. The constructor of `SerialReadThread` first checks if the input parameter of type `SerialPortManager` is null. If it is null, `mySerail` is set to point to the global variable `global_serial` of type `SerialPortManager`; otherwise, `mySerail` is set to point to the input parameter of type `SerialPortManager` in the constructor. Data is read by calling `readDate()` of `mySerail` in the `run()` method of the `SerialReadThread` thread.

[0063] The SerialReadThread class uses a blocking method to read serial port data by listening to the serial port device on the SerialPortManager member variable mySerail. Due to the random, multi-transmission nature of serial port data, the thread reading and processing the data stream from the same serial port device maintains an internal circular buffer. This thread obtains the data stream from its internal circular buffer, identifies it as a complete data packet through the data encapsulation protocol, and then calls the serial port data processing callback function registered by the secondary developer for data parsing and processing. Specifically, the serial port data processing callback function is registered by calling the RegisterCallback(CallbackFunc func) method. Here, CallbackFunc represents a pointer to the serial port data processing callback function. The serial port data processing callback function registered by the secondary developer must conform to the form of the serial port data processing callback function pointer: typedef int(*CallbackFunc)(char*data, int offset, int len). This indicates that the input parameters of the serial port data processing callback function include: a char pointer to the thread's internal circular buffer, the offset of the current complete data packet data, and the data length. The current complete data packet is len bytes in the space pointed to by data, starting from offset. Given the random, segmented transmission of serial port data, this thread combines reading and packet assembly to ensure correct packet reassembly. Generally, it is recommended to only enable one SerialReadThread thread per serial port device. When serial port data transmission is infrequent, the actual business processing can be completed directly in the serial port data processing callback function. When serial port data transmission is frequent and the data processing logic is time-consuming, to accelerate the actual serial port business processing, data processing can be performed by creating a sub-thread within the serial port data processing callback function.

[0064] The SerialReadThread class uses a boolean control variable to control the thread's infinite loop and exit. When the boolean control variable is true, the `run()` method continuously reads data from the serial port in a blocking manner and then assembles it into packets. To ensure data accuracy during packet assembly, the receiving end needs to identify and filter out interfering data. The packet assembly algorithm provided by this class determines whether the data is interfering based on its reasonableness. For example, if the received data significantly exceeds the normal range, it can be considered interfering data. Also, according to the encapsulation protocol, if the data packet format does not conform to the protocol specifications, such as missing a start marker or the data length not matching the actual content, this data can also be judged as interfering data and discarded. After successful packet assembly, the actual business processing of the data is implemented by calling a callback function pointer. This callback function pointer is a serial port data processing callback function registered by the secondary development user by calling the class's `RegisterCallback()` method.

[0065] like Figure 3 The specific process of serial port data processing in this invention is as follows:

[0066] (a) Define the maximum length of the data packet, the protocol header bytes, the protocol fixed length, the cursor, the data buffer, the length of each data packet, and the length of the packet assembly process;

[0067] (b) Determine if the bool control variable is true. If not, exit the loop and terminate the thread. Otherwise, determine if the length of the packet assembly process is less than the maximum length of the data packet. If not, proceed to step (c). Otherwise, proceed to step (d).

[0068] (c) Discard the data, and reset the data buffer, the length of each data, and the length of the packet assembly process to zero, and reuse them for the judgment of the bool control variable;

[0069] (d) Read data packets from the serial port, store them in the data buffer at the length position of the packet assembly process, record the actual length of the data in this process, and increment the length of the packet assembly process.

[0070] (e) Determine whether the length of the packet assembly process is greater than the fixed length of the protocol. If not, continue to step (d). Otherwise, determine whether the protocol header byte in the read data buffer is equal to the packet assembly protocol byte. If not, update the cursor and decrease the length of the packet assembly process. Continue to step (d). Otherwise, update the cursor.

[0071] (f) Determine whether the length of the packet being assembled plus 1 is greater than the protocol header length. If not, continue to step (d). Otherwise, parse out the length of the data packet and update the cursor accordingly.

[0072] (g) Determine if the length of the packet being assembled is greater than the sum of the length of the data packet and the fixed length of the protocol. If not, determine if the length of the data packet is greater than the maximum length of the data packet. If yes, proceed to step (c); otherwise, move the cursor to the position of the nearest protocol header in the data buffer and use it again to determine the bool control variable; otherwise, proceed to step (g).

[0073] (h) Form a complete data packet from the byte stream of the data buffer starting from the position of the sum of the protocol header byte and the length byte minus the cursor position, parse out the length of the data packet, call the actual business logic processing using the callback function pointer, and update the length during packet assembly by subtraction and update the cursor by increment;

[0074] (i) Determine if the length of the packet assembly process is greater than 0 and the cursor length is greater than 0. If so, move the remaining bytes to the beginning of the buffer, set the cursor to 0, release the write lock on the global buffer, and relinquish the CPU execution right; otherwise, directly release the write lock on the global buffer and relinquish the CPU execution right.

[0075] In one technical solution of the present invention, the KjDataStruct source code file, KjDb source code file, KjDemo source code file, and KjTransfer source code file need to be copied to the / home / QtFrameWork directory of the Linux system for the generation of standardized framework code for Qt application development.

[0076] Before generating standardized framework code, the Qt application needs to be installed, such as... Figure 4 The specific process is as follows: Check if the QtFrameWork directory exists in the / home directory of the Linux system. If it exists, delete all files in the / home / QtFrameWork directory. Otherwise, create the QtFrameWork directory and generate the kjconfig.ini configuration file in the " / home / QtFrameWork" directory. Record the installation path in the kjconfig.ini configuration file. Copy the KjDataStruct source code files, KjDb source code files, KjTransfer source code files, and KjDemo source code files from the installation package to the installation path. Calculate the SHA-256 hash value of each source code file using QCryptographicHash and record it in the kjconfig.ini configuration file. Copy the KjDataStruct source code folder, KjDb source code folder, KjTransfer source code folder, and KjDemo source code folder from the installation path to the " / home / QtFrameWork" directory.

[0077] like Figure 5 The standardized framework code generation method for Qt application development includes the following steps:

[0078] Verify that the QtFrameWork directory exists in the / home directory of the Linux system. If not, install the standardized framework code for Qt application development. Otherwise, parse the installation path of the standardized framework code for Qt applications and the SHA-256 hash values ​​of the KjDataStruct, KjDb, KjTransfer, and KjDemo source code files from the " / home / QtFrameWork / kjconfig.ini" configuration file.

[0079] Check each source code file provided by the standardized framework code to see if it exists. If not, clear the QtFrameWork directory and copy the KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders from the installation path to the / home / QtFrameWork directory. Otherwise, determine the integrity of all source code files by checking their size and SHA-256 hash value. If not, clear the / home / QtFrameWork directory and copy the KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders from the installation path to the / home / QtFrameWork directory.

[0080] Then, based on the project path selected by the secondary developer, first check if there are historical KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders under that project path. If they exist, delete them. Then, copy the complete framework source code folder from the / home / QtFrameWork directory to the project path and integrate it into the secondary developer's project for use or reference modification. This ensures the consistency of the standardized framework between different applications and improves the portability and readability of the code.

[0081] In one technical solution of the present invention, a process for unloading standardized framework code for Qt application development is also provided, such as... Figure 6 Extract the installation path from the " / home / QtFrameWork / kjconfig.ini" configuration file, delete the QtFrameWork directory under the " / home" directory, and delete all folders under the software installation path.

[0082] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A standardized framework code generation method for Qt application development, characterized in that, This includes generating KjDataStruct source code files, KjDb source code files, KjDemo source code files, and KjTransfer source code files; The KjDataStruct source code file is used to implement the data structure definition, message type definition, and public buffer definition of the standardized framework code for Qt application development. The KjDb source code files are used to provide general database management classes to implement database operations; The KjDemo source code file is used to provide a demonstration case of using standardized framework code for Qt application development; The KjTransfer source code file is used to implement background UDP communication data transmission and reception processing as well as serial port stream data processing.

2. The standardized framework code generation method for Qt application development according to claim 1, characterized in that, The data structure definition is used to define custom data structures and uniformly place them in struct.h; the message type definition is used to standardize the message types used by Qt applications using an enumeration structure; the public buffer is a unit used to store data packets received in background UDP communication. The public buffer definition includes: defining the maximum length of the public buffer through the MAXDATABUFFERSIZE macro, defining the unit index for writing to the public buffer through writePos, defining the unit index for reading from the public buffer through readPos, the data type of each unit is DataUnit, and the element of each unit contains a dynamically allocated byte array and the length of the space.

3. The standardized framework code generation method for Qt application development according to claim 1, characterized in that, The exemplary cases include: The callback function definition for data parsing and processing after serial port data reading includes: When there is only one serial port device, register it using the global serial port read / write and data processing callback function; When multiple serial port devices exist, register callback functions for each serial port read / write and data processing; The callback function definition for data parsing and processing after receiving data in the background UDP communication includes: When the background UDP communication thread reads data in the main thread and processes data in the child thread, it adopts a fixed number of child threads and registers callback functions for communication data processing in the child threads. The background UDP communication thread reads data in the main thread and processes data in a child thread. It dynamically adjusts the number of child threads by monitoring the usage rate of the shared buffer through the thread pool, and dynamically adjusts the size of the receive buffer by monitoring the usage rate of the receive buffer through the thread pool. By setting the communication data processing callback function of the thread pool, the callback function for communication data processing in the child thread is registered when the number of child threads is increased.

4. The standardized framework code generation method for Qt application development according to claim 1, characterized in that, The background UDP communication data transmission and reception processing includes: the CommunicationManage class, the CommunicationHandleThread class, and the CommunicationThreadPool class; The CommunicationManage class places the received data in a public buffer; The CommunicationHandleThread class opens a sub-thread to read data from the public buffer and calls the communication data callback function registered by the secondary developer to parse and process the data; The CommunicationThreadPool class dynamically increases or decreases the number of CommunicationHandleThread communication data processing sub-threads based on the utilization rate of the storage units in the public buffer, and dynamically increases or decreases the size of the listening socket receive buffer of the CommunicationManage object based on the utilization rate of the socket receive buffer.

5. The standardized framework code generation method for Qt application development according to claim 4, characterized in that, The CommunicationManage class is used to receive data as follows: When applying for a socket, the local machine acts as the server. The port number passed when defining the CommunicationManage class object is used as the port number that the server listens on. The socket is bound to this port to receive and listen for data. The start method is called to bind the readyRead signal of QUdpSocket to the recvMsg method to read the data sent by the client.

6. The standardized framework code generation method for Qt application development according to claim 4, characterized in that, The CommunicationManage class calls the sendMsg() method to send data. The input parameters of the sendMsg() method include: the byte stream data to be sent, the destination IP, and the destination port number.

7. The standardized framework code generation method for Qt application development according to claim 4, characterized in that, The communication data callback function is registered by calling the RegisterCallback(CallbackCommunicationFuncfunc) method, where CallbackCommunicationFunc represents a pointer to the communication data callback function. The pointer to the communication data callback function is in the form of typedef int(*CallbackCommunicationFunc)(char*data), which means that the input parameter of the communication data callback function is a char pointer that points to the header byte of a complete data packet.

8. The standardized framework code generation method for Qt application development according to claim 1, characterized in that, The serial port stream data processing includes: the SerialPortManager class and the SerialReadThread class; The SerialPortManager class provides methods for setting serial port parameters, opening and closing the serial port, sending data, and receiving data. The SerialReadThread class has a member variable mySerail of type SerialPortManager, which is used to store the serial port device of type SerialPortManager operated in the SerialReadThread serial port data reading and processing thread. The SerialReadThread class reads serial port data by listening to the serial port device on the member variable mySerail of type SerialPortManager, and calls the serial port data processing callback function registered by the secondary developer to parse and process the data.

9. A standardized framework code generation method for Qt application development according to claim 8, characterized in that, The serial port data processing callback function is registered by calling the RegisterCallback(CallbackFunc func) method. Here, CallbackFunc represents a pointer to the serial port data processing callback function. The pointer to the serial port data processing callback function is in the form of typedef int(*CallbackFunc)(char*data,intoffset,int len), indicating that the input parameters of the serial port data processing callback function include: a char pointer to the internal circular buffer of the thread, the offset of the current complete data packet data, and the data length. The current complete data packet is len bytes starting from offset in the space pointed to by data.

10. A standardized framework code generation method for Qt application development according to any one of claims 1-9, characterized in that, Includes the following steps: Verify that the QtFrameWork directory exists in the / home directory of the Linux system. If not, install the standardized framework code for Qt application development. Otherwise, parse the installation path of the standardized framework code for Qt applications and the SHA-256 hash values ​​of the KjDataStruct, KjDb, KjTransfer, and KjDemo source code files from the " / home / QtFrameWork / kjconfig.ini" configuration file. Check each source code file provided by the standardized framework code to see if it exists. If not, clear the QtFrameWork directory and copy the KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders from the installation path to the / home / QtFrameWork directory. Otherwise, determine if all source code files are normal by judging their size and SHA-256 hash value. If not, clear the / home / QtFrameWork directory and copy the KjDataStruct, KjDb, KjTransfer, and KjDemo source code folders from the installation path to the / home / QtFrameWork directory. Based on the project path selected by the secondary developer, copy the KjDataStruct source code folder, KjDb source code folder, KjTransfer source code folder, and KjDemo source code folder from the / home / QtFrameWork directory to the project path.

Images