A client-side method and system for AutoCAD task processing based on named pipes
By decoupling the communication between the Electron client and AutoCAD through named pipes and background worker threads, the problem of isolation between the Electron client and AutoCAD processes is solved, achieving efficient and reliable task processing, suitable for a variety of engineering applications.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIAMEN ANTAI NEW ENERGY TECH
- Filing Date
- 2026-03-05
- Publication Date
- 2026-06-30
Smart Images
Figure CN122309061A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, specifically to a client-side method and system for processing AutoCAD tasks based on named pipes. Background Technology
[0002] With the increasing automation of engineering design, more and more design firms are adopting desktop automation clients to uniformly manage parameter input, task scheduling, and result display. The Electron+Vue framework, due to its cross-platform compatibility and rapid development capabilities, is now widely used to build such clients. However, in AutoCAD automatic drawing scenarios, the following problems exist:
[0003] 1. As a large-scale drawing software, AutoCAD's automation capabilities mainly rely on its built-in .NET API. However, the Electron client is naturally isolated from the AutoCAD process and cannot directly call the AutoCAD API.
[0004] 2. Conventional communication methods (such as file polling, registry, intermediate database, COM interface, etc.) have drawbacks such as poor real-time performance, high coupling, and imperfect transaction support;
[0005] 3. When performing a large number of calculations or drawing operations, if communication is coupled with the main thread (i.e., the UI thread), it can easily cause AutoCAD to freeze or become unresponsive.
[0006] 4. Electron clients have both asynchronous requirements, such as sending tasks without caring about the results, and synchronous requirements, such as waiting for AutoCAD to return the results.
[0007] Therefore, there is an urgent need to provide a task processing solution that is loosely coupled, highly reliable, supports both synchronous and asynchronous operations, and avoids blocking the main thread. Summary of the Invention
[0008] To address the shortcomings of existing technologies, this invention provides a client-AutoCAD task processing method and system based on named pipes, which solves one or more of the aforementioned problems in existing AutoCAD automatic drawing scenarios. It can reduce the coupling between the Electron client and AutoCAD, improve communication reliability, support synchronous and asynchronous coexistence, and avoid blocking the main thread.
[0009] To achieve the above objectives, the present invention provides the following technical solution:
[0010] Firstly, a client-AutoCAD task processing method based on named pipes, the method comprising the following steps:
[0011] When AutoCAD loads a DLL plugin, it initializes the communication service through the DLL plugin and establishes a named pipe between the DLL plugin and the client to achieve a communication connection.
[0012] The DLL plugin obtains the client's request data through a named pipe, parses the client's request data to generate parsing results, and performs asynchronous or synchronous task processing based on the parsing results.
[0013] Secondly, a client-AutoCAD task processing system based on named pipes, the system including a communication connection module and a task processing module;
[0014] The communication connection module is used to initialize the communication service through the DLL plugin when AutoCAD loads the DLL plugin, and establish a named pipe between the DLL plugin and the client to realize the communication connection.
[0015] The task processing module is used by the DLL plugin to obtain client request data through the established named pipe, parse the client request data to generate parsing results, and execute asynchronous or synchronous task processing based on the parsing results.
[0016] By adopting the above-described technical solution of the present invention, at least the following beneficial effects are achieved:
[0017] 1. The design uses named pipes to connect and communicate between the Electron client and the AutoCAD DLL plugin, which effectively decouples the Electron client and AutoCAD. Furthermore, named pipes offer high real-time performance and stability, ensuring clear and reliable communication.
[0018] 2. Registering the DoWork event, which is used to execute named pipe listening and data reading logic, to a background worker thread effectively separates business processing logic from the main thread. This decoupling of business processing logic from the main thread can effectively reduce AutoCAD freezing or becoming unresponsive during a large amount of drawing and calculation, thus avoiding blocking the main thread.
[0019] 3. By designing the client's request data to include marker parameters for indicating synchronous or asynchronous operation, and designing a DLL plugin to execute corresponding asynchronous or synchronous task processing based on the parsing results, it can well support the coexistence of synchronous and asynchronous tasks, thus adapting to a variety of different business scenarios.
[0020] 4. The DLL plugin can continuously provide communication services throughout its lifecycle, meaning that the DLL plugin will be in a resident communication listening state without needing to repeatedly load the DLL plugin or restart AutoCAD.
[0021] 5. The design of the task dispatcher can effectively reduce the coupling between the communication layer and specific business logic, so as to facilitate subsequent function expansion and maintenance, and ensure a clear task dispatch mechanism.
[0022] 6. It is applicable to various engineering application scenarios such as parametric drawing, batch drawing, and automatic modeling, and has good engineering practicality. Attached Figure Description
[0023] Figure 1 This is a schematic diagram of the overall system architecture of the present invention;
[0024] Figure 2 This is a flowchart illustrating the execution process of a client-AutoCAD task processing method based on named pipes according to the present invention.
[0025] Figure 3 This is a timing diagram of the entire operation in this invention;
[0026] Figure 4 This is a schematic diagram of the structure of a client and AutoCAD task processing system based on named pipes according to the present invention. Detailed Implementation
[0027] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0028] Before proceeding, let's first introduce some of the technical foundations for implementing the technical solution of this invention:
[0029] AutoCAD currently provides a complete .NET API, which supports secondary development of AutoCAD using languages such as C# to automate entity creation, modification, deletion, and drawing logic.
[0030] The AutoCAD .NET API provides the IExtensionApplication interface, which is used for plugin lifecycle management: when an AutoCAD .NET plugin (i.e., a DLL plugin) is loaded (via NETLOAD or registry autoloading), AutoCAD automatically calls the Initialize() method; when the DLL plugin is unloaded or AutoCAD is closed, AutoCAD calls the Terminate() method. Therefore, the IExtensionApplication interface provides a standard entry point for DLL plugins to initialize background services (such as communication services) during the loading phase.
[0031] Named pipes are an operating system-level inter-process communication (IPC) mechanism that offers advantages such as cross-process communication, bidirectional data transmission, low latency, and high reliability.
[0032] The following describes the overall system architecture of this invention. Please refer to [link / reference]. Figure 1 As shown, it mainly consists of an Electron+Vue automation client, an AutoCAD .NET plugin (hereinafter collectively referred to as a DLL plugin), and a communication channel based on named pipes. The client and the DLL plugin communicate through named pipes. The client is responsible for inputting various drawing parameters and initiating tasks, while the DLL plugin is responsible for receiving client requests and completing the corresponding automatic drawing or calculation processing in the AutoCAD runtime environment.
[0033] Example 1
[0034] Please see the appendix Figures 1 to 3 As shown, this invention provides a client-AutoCAD task processing method based on named pipes, the method comprising the following steps:
[0035] When AutoCAD loads a DLL plugin, it initializes the communication service through the DLL plugin and establishes a named pipe between the DLL plugin and the client to enable data transmission between them.
[0036] The DLL plugin obtains the client's request data through a named pipe, parses the client's request data to generate parsing results, and performs asynchronous or synchronous task processing based on the parsing results.
[0037] In some embodiments of the present invention, the initialization of the communication service via the DLL plugin specifically includes:
[0038] In this invention, when AutoCAD loads a DLL plugin, it automatically calls the IExtensionApplication interface of the DLL plugin. In the Initialize() method of the IExtensionApplication interface, a background worker thread is created by creating a BackgroundWorker instance. The DoWork event and the RunWorkerCompleted event are registered in the background worker thread. The DoWork event is used to execute named pipe listening and data reading logic, and the RunWorkerCompleted event is used to execute business dispatch and CAD operations (i.e., execute drawing or calculation tasks) in the context of the main thread (i.e., the UI thread).
[0039] Calling the RunWorkerAsync() method causes a background worker thread to execute the named pipe's listening logic.
[0040] This invention effectively separates business processing logic from the main thread by registering the DoWork event, which is used to execute named pipe listening and data reading logic, to a background worker thread. At the same time, the background worker thread also registers the RunWorkerCompleted event, which is used to execute business dispatch and CAD operations in the main thread context. This decouples business processing logic from the main thread and can effectively reduce the occurrence of AutoCAD freezing or becoming unresponsive during a large amount of drawing and calculation.
[0041] In some embodiments of the present invention, establishing a named pipe between the DLL plugin and the client to enable communication specifically includes:
[0042] In the background worker thread, a PipeSecurity object is created, and read and write permissions are configured for the built-in user group (BuiltinUsersSid). This creates a pipe security policy to prevent unauthorized access and improve security. A NamedPipeServerStream instance supporting bidirectional communication is created to implement the server-side object for the named pipe. An asynchronous mode is used to listen for client connections; that is, serverStream.WaitForConnection() is called to block the background worker thread and wait for the Electron client to establish a communication connection. This step is mainly executed in the Background_DoWork() method, and by adopting the above method, the security and stability of the entire communication process can be ensured.
[0043] In a specific implementation, the following access permissions can be added to the built-in user group:
[0044] ReadWrite;
[0045] CreateNewInstance;
[0046] Bind permission rules using PipeAccessRule.
[0047] The parameters of the NamedPipeServerStream instance are as follows:
[0048] Pipe Name: PeonyCadPipe
[0049] Communication direction: Bidirectional (InOut)
[0050] Maximum number of instances: 1
[0051] Transmission mode: Message (read by message boundaries)
[0052] Asynchronous mode: PipeOptions.Asynchronous
[0053] Input buffer: 1024 bytes
[0054] Output buffer: 1024 bytes
[0055] Security policy: PipeSecurity object.
[0056] The client is based on the Electron+Vue framework and connects with a named pipe created by the DLL plugin through the createConnection() method in the net module provided by Node.js, thereby enabling communication.
[0057] In some embodiments of the present invention, the client's request data includes task request parameters, which include user-input drawing parameters and marker parameters for indicating synchronous or asynchronous operation. The drawing parameters are used by the DLL plugin to perform automatic drawing or calculation processing in the AutoCAD runtime environment, and the marker parameters are used by the DLL plugin to determine the communication mode to execute the corresponding asynchronous or synchronous task processing. In a specific implementation of the present invention, the main data structure of the client's task dispatch input parameters is as follows:
[0058] {
[0059] MessageType: "getSideView", / / Method signature
[0060] Payload: inputParamObjList, / / actual input parameter
[0061] WaitForResult: false, / / Marks whether it is synchronous or asynchronous
[0062] };
[0063] Meanwhile, the client serializes the request data into JSON format, encodes the serialized request data, and then sends the encoded request data through named pipes to further enhance the security of data transmission.
[0064] In one specific embodiment of the present invention, UTF-8 is used to encode the serialized request data. UTF-8 is a variable-length character encoding for Unicode, which is compatible with ASCII and can represent any character in the Unicode standard. Of course, the above is only a preferred encoding method listed in the present invention, but the present invention is not limited to this, and other encoding methods can be used according to actual needs in specific implementations.
[0065] In some embodiments of the present invention, the step of parsing the client's request data to generate a parsing result specifically includes:
[0066] After the DLL plugin reads the complete client request data, it decodes the data. If the client uses UTF-8 encoding, the DLL plugin decodes it using UTF-8. For example, it can use `Encoding.UTF8.GetString(pipeData)` to convert the byte data into a JSON string and then deserialize the decoded data into a unified `PipeRequest` object. This allows the DLL plugin to retrieve task request parameters. Specifically, it can use `Newtonsoft.Json: pipeRequest = JsonConvert.DeserializeObject`. <piperequest>(jsonData) is used to generate a unified PipeRequest object. In specific implementations, to ensure that the DLL plugin can read complete request data, a custom method ReadPipeData(stream) can be called. In this custom method, the DLL plugin reads 256 bytes of data at a time until it is accumulated into a List. <byte>When the length of the read data is less than 256, the message is considered to be over, and a final complete byte array is generated.
[0067] The communication mode is determined based on the task request parameters in the request data, and a parsing result of synchronous or asynchronous mode is generated. In specific implementation, the communication mode can be determined based on the PipeRequest.WaitForResult field, that is, the WaitForResult field of the client input parameter. When WaitForResult is True, it indicates synchronous mode, and when WaitForResult is False, it indicates asynchronous mode.
[0068] In some embodiments of the present invention, the step of performing asynchronous or synchronous task processing based on the parsing result specifically includes:
[0069] When the parsing result is in synchronous mode (i.e., `pipeRequest.WaitForResult == true`), the named pipe connection between the DLL plugin and the client is maintained to facilitate returning the execution result to the client later. The `PipeRequest` request object and the named pipe server object are passed to the background worker thread, triggering the `RunWorkerCompleted` event of the background worker thread to execute the CAD operation. This involves encapsulating `PipeRequest` and `NamedPipeServerStream` into a `new PipeMessage { request, Stream}`, and passing it to `RunWorkerCompleted` via `e.Result = PipeMessage`, so that the actual business processing can be performed in the `RunWorkerCompleted` stage. After the CAD operation is completed, the execution result is serialized into JSON format and returned to the client through the named pipe. After receiving the execution result, the client closes the named pipe connection between the DLL plugin and the client. In a specific implementation of this invention, the main data structure for the client to receive the execution result is as follows:
[0070] {
[0071] Success: true / false, / / true indicates the request was successful, false indicates the request failed.
[0072] Data: {}, / / The specific result object
[0073] Message: "", / / Error message to carry when the request fails
[0074] }
[0075] When the parsing result is in asynchronous mode, i.e., pipeRequest.WaitForResult == false, the DLL plugin immediately constructs an acknowledgment response:
[0076] {
[0077] Success: true,
[0078] Message: "the request have received,please wait----"
[0079] };
[0080] The confirmation response is serialized into JSON format and returned to the client via a named pipe. Specifically, a JSON string can be written to the named pipe using a StreamWriter. Upon receiving the confirmation response, the client closes the named pipe connection between the DLL plugin and the client, specifically by calling `serverStream.Dispose()`. The client will immediately disconnect upon receiving the confirmation response. The PipeRequest object is then passed to a background worker thread, triggering the RunWorkerCompleted event to execute CAD operations. The actual business logic is performed during the RunWorkerCompleted phase, which can be achieved by calling `pipeDispatcher.Dispatch(pipeRequest)` on the main thread to execute automatic drawing or calculation tasks. Because this is asynchronous, the client does not need to wait for the execution result, making it particularly suitable for scenarios such as batch drawing.
[0081] This invention incorporates marker parameters in the client's request data to indicate whether the task is synchronous or asynchronous. Simultaneously, a DLL plugin is designed to execute corresponding asynchronous or synchronous tasks based on the parsing results. This effectively supports the coexistence of synchronous and asynchronous tasks, thus adapting to various business scenarios.
[0082] In some embodiments of the present invention, the method further includes: after each task is completed, the background worker thread immediately restarts the named pipe's listening logic to continuously wait for the next client connection. In specific implementations of the present invention, background.RunWorkerAsync() can be executed in the RunWorkerCompleted finally block, enabling the DLL plugin to continuously provide communication services throughout its lifecycle; that is, the DLL plugin will be in a persistent communication listening state without needing to repeatedly load the DLL plugin or restart AutoCAD.
[0083] In some embodiments of the present invention, the method further includes: introducing a task dispatcher within the DLL plugin, selecting the corresponding business logic based on the request type or command identifier through the task dispatcher, and uniformly managing different drawing, modeling, and calculation tasks using the task dispatcher. In specific implementations of the present invention, this step is mainly executed in `Background_RunWorkerCompleted()`, specifically through `var response = pipeDispatcher.Dispatch(request)` to call the task dispatcher, enabling the task dispatcher to call the corresponding CAD API to execute drawing or calculation tasks based on the request type or command identifier. The design of the task dispatcher effectively reduces the coupling between the communication layer and specific business logic, facilitating subsequent functional expansion and maintenance.
[0084] In this invention, the main data structure of the task dispatcher is as follows:
[0085] / / Dictionary of task types and corresponding handlers
[0086] private readonly Dictionary<string, RequestHandler> handlers;
[0087] / / Register tasks in the constructor
[0088] public PipeDispatcher() {
[0089] this.Register("getSideView", payLoad =>
[0090] {
[0091] DrawSolarView view = new DrawSolarView();
[0092] view.Draw(payLoad);
[0093] return "ok";
[0094] });
[0095] }
[0096] / / Task registration function
[0097] public void Register(string messageType, RequestHandler handler)
[0098] {
[0099] handlers[messageType] = handler;
[0100] }
[0101] / / Specific processing logic for task dispatching
[0102] public PipeResponse Dispatch(PipeRequest request){
[0103] var handler;
[0104] if (handlers.TryGetValue(request.MessageType, out handler)){
[0105] try{
[0106] var result = handler(request.Payload);
[0107] return new PipeResponse { Success = true, Message = "ok", Data = result};
[0108] }catch (Exception ex){
[0109] return new PipeResponse { Success = false, Message = ex.Message};}
[0110] }else{
[0111] return new PipeResponse { Success = false, Message = $"Unknown MessageType: {request.MessageType}"};}}。
[0112] Meanwhile, in synchronous mode, the task dispatcher constructs the execution result, generating a unified response object: PipeResponse {Success,Message, Data}; and uses using (var writer = newStreamWriter(syncMsg.Stream, new UTF8Encoding(false), 1024, leaveOpen:false)){writer.AutoFlush=true;writer.Write(JsonConvert.SerializeObject(response)+"\n");} to send the execution result to the client via a named pipe, and immediately closes the named pipe connection between the DLL plugin and the client after the execution result is sent.
[0113] By adopting the above-described technical solution of the present invention, at least the following beneficial effects are achieved:
[0114] 1. The design uses named pipes to connect and communicate between the Electron client and the AutoCAD DLL plugin, which effectively decouples the Electron client and AutoCAD. Furthermore, named pipes offer high real-time performance and stability, ensuring clear and reliable communication.
[0115] 2. Registering the DoWork event, which is used to execute named pipe listening and data reading logic, to a background worker thread effectively separates business processing logic from the main thread. This decoupling of business processing logic from the main thread can effectively reduce AutoCAD freezing or becoming unresponsive during a large amount of drawing and calculation, thus avoiding blocking the main thread.
[0116] 3. By designing the client's request data to include marker parameters for indicating synchronous or asynchronous operation, and designing a DLL plugin to execute corresponding asynchronous or synchronous task processing based on the parsing results, it can well support the coexistence of synchronous and asynchronous tasks, thus adapting to a variety of different business scenarios.
[0117] 4. The DLL plugin can continuously provide communication services throughout its lifecycle, meaning that the DLL plugin will be in a resident communication listening state without needing to repeatedly load the DLL plugin or restart AutoCAD.
[0118] 5. The design of the task dispatcher can effectively reduce the coupling between the communication layer and specific business logic, so as to facilitate subsequent function expansion and maintenance, and ensure a clear task dispatch mechanism.
[0119] 6. It is applicable to various engineering application scenarios such as parametric drawing, batch drawing, and automatic modeling. For example, it can be widely used in engineering structure CAD automatic drawing system, parametric modeling and batch drawing platform, collaborative automation of CAD and external computing system, and Electron-based desktop engineering automation client, etc., and has good engineering practicality.
[0120] Example 2
[0121] Please see Figure 1 , Figure 3 and Figure 4 As shown, the present invention also provides a client and AutoCAD task processing system based on named pipes, the system including a communication connection module and a task processing module;
[0122] The communication connection module is used to initialize the communication service through the DLL plugin when AutoCAD loads the DLL plugin, establish a named pipe between the DLL plugin and the client to realize the communication connection, and enable data transmission between the DLL plugin and the client through the named pipe.
[0123] The task processing module is used by the DLL plugin to obtain client request data through the established named pipe, parse the client request data to generate parsing results, and execute asynchronous or synchronous task processing based on the parsing results.
[0124] In some embodiments of the present invention, the initialization of the communication service via the DLL plugin specifically includes:
[0125] In this invention, when AutoCAD loads a DLL plugin, it automatically calls the IExtensionApplication interface of the DLL plugin. In the Initialize() method of the IExtensionApplication interface, a background worker thread is created by creating a BackgroundWorker instance. The DoWork event and the RunWorkerCompleted event are registered in the background worker thread. The DoWork event is used to execute named pipe listening and data reading logic, and the RunWorkerCompleted event is used to execute business dispatch and CAD operations (i.e., execute drawing or calculation tasks) in the context of the main thread (i.e., the UI thread).
[0126] Calling the RunWorkerAsync() method causes a background worker thread to execute the named pipe's listening logic.
[0127] This invention effectively separates business processing logic from the main thread by registering the DoWork event, which is used to execute named pipe listening and data reading logic, to a background worker thread. At the same time, the background worker thread also registers the RunWorkerCompleted event, which is used to execute business dispatch and CAD operations in the main thread context. This decouples business processing logic from the main thread and can effectively reduce the occurrence of AutoCAD freezing or becoming unresponsive during a large amount of drawing and calculation.
[0128] In some embodiments of the present invention, establishing a named pipe between the DLL plugin and the client to enable communication specifically includes:
[0129] In the background worker thread, a PipeSecurity object is created, and read and write permissions are configured for the built-in user group (BuiltinUsersSid). This creates a pipe security policy to prevent unauthorized access and improve security. A NamedPipeServerStream instance supporting bidirectional communication is created to implement the server-side object for the named pipe. An asynchronous mode is used to listen for client connections; that is, serverStream.WaitForConnection() is called to block the background worker thread and wait for the Electron client to establish a communication connection. This step is mainly executed in the Background_DoWork() method, and by adopting the above method, the security and stability of the entire communication process can be ensured.
[0130] In a specific implementation, the following access permissions can be added to the built-in user group:
[0131] ReadWrite;
[0132] CreateNewInstance;
[0133] Bind permission rules using PipeAccessRule.
[0134] The parameters of the NamedPipeServerStream instance are as follows:
[0135] Pipe Name: PeonyCadPipe
[0136] Communication direction: Bidirectional (InOut)
[0137] Maximum number of instances: 1
[0138] Transmission mode: Message (read by message boundaries)
[0139] Asynchronous mode: PipeOptions.Asynchronous
[0140] Input buffer: 1024 bytes
[0141] Output buffer: 1024 bytes
[0142] Security policy: PipeSecurity object.
[0143] The client is based on the Electron+Vue framework and connects with a named pipe created by the DLL plugin through the createConnection() method in the net module provided by Node.js, thereby enabling communication.
[0144] In some embodiments of the present invention, the client's request data includes task request parameters, which include user-input drawing parameters and marker parameters for indicating synchronous or asynchronous operation. The drawing parameters are used by the DLL plugin to perform automatic drawing or calculation processing in the AutoCAD runtime environment, and the marker parameters are used by the DLL plugin to determine the communication mode to execute the corresponding asynchronous or synchronous task processing. In a specific implementation of the present invention, the main data structure of the client's task dispatch input parameters is as follows:
[0145] {
[0146] MessageType: "getSideView", / / Method signature
[0147] Payload: inputParamObjList, / / actual input parameter
[0148] WaitForResult: false, / / Marks whether it is synchronous or asynchronous
[0149] };
[0150] Meanwhile, the client serializes the request data into JSON format, encodes the serialized request data, and then sends the encoded request data through named pipes to further enhance the security of data transmission.
[0151] In one specific embodiment of the present invention, UTF-8 is used to encode the serialized request data. UTF-8 is a variable-length character encoding for Unicode, which is compatible with ASCII and can represent any character in the Unicode standard. Of course, the above is only a preferred encoding method listed in the present invention, but the present invention is not limited to this, and other encoding methods can be used according to actual needs in specific implementations.
[0152] In some embodiments of the present invention, the step of parsing the client's request data to generate a parsing result specifically includes:
[0153] After the DLL plugin reads the complete client request data, it decodes the data. If the client uses UTF-8 encoding, the DLL plugin decodes it using UTF-8. For example, it can use `Encoding.UTF8.GetString(pipeData)` to convert the byte data into a JSON string and then deserialize the decoded data into a unified `PipeRequest` object. This allows the DLL plugin to retrieve task request parameters. Specifically, it can use `Newtonsoft.Json: pipeRequest = JsonConvert.DeserializeObject`. <piperequest>(jsonData) is used to generate a unified PipeRequest object. In specific implementations, to ensure that the DLL plugin can read complete request data, a custom method ReadPipeData(stream) can be called. In this custom method, the DLL plugin reads 256 bytes of data at a time until it is accumulated into a List. <byte>When the length of the read data is less than 256, the message is considered to be over, and a final complete byte array is generated.
[0154] The communication mode is determined based on the task request parameters in the request data, and a parsing result of synchronous or asynchronous mode is generated. In specific implementation, the communication mode can be determined based on the PipeRequest.WaitForResult field, that is, the WaitForResult field of the client input parameter. When WaitForResult is True, it indicates synchronous mode, and when WaitForResult is False, it indicates asynchronous mode.
[0155] In some embodiments of the present invention, the step of performing asynchronous or synchronous task processing based on the parsing result specifically includes:
[0156] When the parsing result is in synchronous mode (i.e., `pipeRequest.WaitForResult == true`), the named pipe connection between the DLL plugin and the client is maintained to facilitate returning the execution result to the client later. The `PipeRequest` request object and the named pipe server object are passed to the background worker thread, triggering the `RunWorkerCompleted` event of the background worker thread to execute the CAD operation. This involves encapsulating `PipeRequest` and `NamedPipeServerStream` into a `new PipeMessage { request, Stream}`, and passing it to `RunWorkerCompleted` via `e.Result = PipeMessage`, so that the actual business processing can be performed in the `RunWorkerCompleted` stage. After the CAD operation is completed, the execution result is serialized into JSON format and returned to the client through the named pipe. After receiving the execution result, the client closes the named pipe connection between the DLL plugin and the client. In a specific implementation of this invention, the main data structure for the client to receive the execution result is as follows:
[0157] {
[0158] Success: true / false, / / true indicates the request was successful, false indicates the request failed.
[0159] Data: {}, / / The specific result object
[0160] Message: "", / / Error message to carry when the request fails
[0161] }
[0162] When the parsing result is in asynchronous mode, i.e., pipeRequest.WaitForResult == false, the DLL plugin immediately constructs an acknowledgment response:
[0163] {
[0164] Success: true,
[0165] Message: "the request have received,please wait----"
[0166] };
[0167] The confirmation response is serialized into JSON format and returned to the client via a named pipe. Specifically, a JSON string can be written to the named pipe using a StreamWriter. Upon receiving the confirmation response, the client closes the named pipe connection between the DLL plugin and the client, specifically by calling `serverStream.Dispose()`. The client will immediately disconnect upon receiving the confirmation response. The PipeRequest object is then passed to a background worker thread, triggering the RunWorkerCompleted event to execute CAD operations. The actual business logic is performed during the RunWorkerCompleted phase, which can be achieved by calling `pipeDispatcher.Dispatch(pipeRequest)` on the main thread to execute automatic drawing or calculation tasks. Because this is asynchronous, the client does not need to wait for the execution result, making it particularly suitable for scenarios such as batch drawing.
[0168] This invention incorporates marker parameters in the client's request data to indicate whether the task is synchronous or asynchronous. Simultaneously, a DLL plugin is designed to execute corresponding asynchronous or synchronous tasks based on the parsing results. This effectively supports the coexistence of synchronous and asynchronous tasks, thus adapting to various business scenarios.
[0169] In some embodiments of the present invention, the system further includes a restart monitoring module;
[0170] The aforementioned listening and restart module is used to immediately restart the named pipe's listening logic after each task is completed, so as to continuously wait for the next client connection. In a specific implementation of this invention, background.RunWorkerAsync() can be executed in the RunWorkerCompleted finally block, enabling the DLL plugin to continuously provide communication services throughout its lifecycle. That is, the DLL plugin will be in a resident communication listening state without having to repeatedly load the DLL plugin or restart AutoCAD.
[0171] In some embodiments of the present invention, the system further includes a task management module;
[0172] The task management module is used to introduce a task dispatcher within the DLL plugin. The task dispatcher selects the corresponding business logic based on the request type or command identifier and manages different drawing, modeling, and calculation tasks uniformly. In specific implementations, this step is mainly executed in `Background_RunWorkerCompleted()`, specifically through `var response = pipeDispatcher.Dispatch(request)` to call the task dispatcher, enabling it to invoke the corresponding CAD API to execute drawing or calculation tasks based on the request type or command identifier. The task dispatcher design effectively reduces the coupling between the communication layer and the specific business logic, facilitating subsequent functional expansion and maintenance.
[0173] In this invention, the main data structure of the task dispatcher is as follows:
[0174] / / Dictionary of task types and corresponding handlers
[0175] private readonly Dictionary<string, RequestHandler> handlers;
[0176] / / Register tasks in the constructor
[0177] public PipeDispatcher() {
[0178] this.Register("getSideView", payLoad =>
[0179] {
[0180] DrawSolarView view = new DrawSolarView();
[0181] view.Draw(payLoad);
[0182] return "ok";
[0183] });
[0184] }
[0185] / / Specific function for task registration
[0186] public void Register(string messageType, RequestHandler handler)
[0187] {
[0188] handlers[messageType] = handler;
[0189] }
[0190] / / Specific processing logic for task dispatching
[0191] public PipeResponse Dispatch(PipeRequest request){
[0192] var handler;
[0193] if (handlers.TryGetValue(request.MessageType,out handler)){
[0194] try{
[0195] var result = handler(request.Payload);
[0196] return new PipeResponse { Success = true, Message = "ok", Data = result};
[0197] }catch (Exception ex){
[0198] return new PipeResponse { Success = false, Message =ex.Message};}
[0199] }else{
[0200] return new PipeResponse { Success = false, Message = $"Unknown MessageType: {request.MessageType}"};}}.
[0201] Meanwhile, in synchronous mode, the task dispatcher constructs the execution result, generating a unified response object: PipeResponse {Success,Message, Data}; and uses using (var writer = newStreamWriter(syncMsg.Stream, new UTF8Encoding(false), 1024, leaveOpen:false)){writer.AutoFlush=true;writer.Write(JsonConvert.SerializeObject(response)+"\n");} to send the execution result to the client via a named pipe, and immediately closes the named pipe connection between the DLL plugin and the client after the execution result is sent.
[0202] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.< / byte> < / piperequest> < / byte> < / piperequest>
Claims
1. A client-AutoCAD task processing method based on named pipes, characterized in that, The method includes the following steps: When AutoCAD loads a DLL plugin, it initializes the communication service through the DLL plugin and establishes a named pipe between the DLL plugin and the client to achieve a communication connection. The DLL plugin obtains the client's request data through a named pipe, parses the client's request data to generate parsing results, and performs asynchronous or synchronous task processing based on the parsing results.
2. The client-AutoCAD task processing method based on named pipes according to claim 1, characterized in that, The initialization of the communication service via DLL plugin specifically includes: The IExtensionApplication interface of the DLL plugin is called. In the Initialize() method of the IExtensionApplication interface, a background worker thread is created by creating a BackgroundWorker instance. The DoWork event and the RunWorkerCompleted event are registered in the background worker thread. The DoWork event is used to execute named pipe listening and data reading logic, and the RunWorkerCompleted event is used to execute business dispatch and CAD operations in the main thread context. Calling the RunWorkerAsync() method causes a background worker thread to execute the named pipe's listening logic.
3. The client-AutoCAD task processing method based on named pipes according to claim 2, characterized in that, The establishment of a named pipe between the DLL plugin and the client to enable communication specifically includes: Create a PipeSecurity object in a background worker thread and configure read and write permissions for the built-in user group; create a NamedPipeServerStream instance that supports bidirectional communication to implement the server object for creating named pipes, and listen for client connections in asynchronous mode; The client is based on the Electron+Vue framework and connects with a named pipe created by the DLL plugin through the createConnection() method in the net module provided by Node.js, thereby enabling communication.
4. The client-AutoCAD task processing method based on named pipes according to claim 2, characterized in that, The client's request data includes task request parameters, which include user-input drawing parameters and marker parameters for indicating synchronous or asynchronous operation. Meanwhile, the client serializes the request data into JSON format, encodes the serialized request data, and then sends the encoded request data through named pipes.
5. The client-AutoCAD task processing method based on named pipes according to claim 4, characterized in that, The specific steps of parsing the client's request data to generate parsing results include: After the DLL plugin reads the complete client request data, it decodes the client request data and deserializes the decoded request data into a unified PipeRequest object. The communication mode is determined based on the task request parameters in the request data, and a parsing result for synchronous or asynchronous mode is generated.
6. The client-AutoCAD task processing method based on named pipes according to claim 5, characterized in that, The specific steps of performing asynchronous or synchronous task processing based on the parsing results include: When the parsing result is in synchronous mode, the named pipe connection between the DLL plugin and the client is maintained. The PipeRequest request object and the named pipe server object are passed to the background worker thread, triggering the RunWorkerCompleted event of the background worker thread to execute the CAD operation. After the CAD operation is completed, the execution result is serialized into JSON format and returned to the client through the named pipe. After receiving the execution result, the client closes the named pipe connection between the DLL plugin and the client. When the parsing result is in asynchronous mode, the DLL plugin immediately constructs a confirmation response, serializes the confirmation response into JSON format, and returns it to the client through a named pipe. After receiving the confirmation response, the client closes the named pipe connection between the DLL plugin and the client; passes the PipeRequest object to the background worker thread, triggers the RunWorkerCompleted event of the background worker thread to execute the CAD operation.
7. The client-AutoCAD task processing method based on named pipes according to claim 2, characterized in that, The method further includes: after each task is completed, the background worker thread immediately restarts the named pipe's listening logic to continuously wait for the next client connection.
8. A client-AutoCAD task processing method based on named pipes according to any one of claims 1-7, characterized in that, The method further includes: introducing a task dispatcher inside the DLL plugin, selecting the corresponding business logic according to the request type or command identifier through the task dispatcher, and using the task dispatcher to uniformly manage different drawing, modeling, and calculation tasks.
9. The client-AutoCAD task processing method based on named pipes according to claim 4, characterized in that, The serialized request data is encoded using UTF-8.
10. A client-AutoCAD task processing system based on named pipes, characterized in that, The system includes a communication connection module and a task processing module; The communication connection module is used to initialize the communication service through the DLL plugin when AutoCAD loads the DLL plugin, and establish a named pipe between the DLL plugin and the client to realize the communication connection. The task processing module is used by the DLL plugin to obtain client request data through the established named pipe, parse the client request data to generate parsing results, and execute asynchronous or synchronous task processing based on the parsing results.