Uniform interface implementation method and system for cross-platform office plug-ins

Abstract

The invention discloses a method and a system for realizing a uniform interface of a cross-platform office plug-in. The method comprises the following steps of: loading a platform adaptation layer in host office software; receiving a calling request from a front-end interface through a platform adaptation layer, and matching a corresponding local processing function based on a predefined path identifier; in the execution process of the local processing function, if cross-language data interaction with a host script environment is involved, a constrained secure memory reading mechanism is adopted; and after the local processing function is executed, returning a processing result to a front-end interface through a unified callback channel so as to support multiple response modes. By constructing a platform adaptation layer, a secure memory interaction mechanism and a unified callback channel, the consistency of the cross-operating system office plug-in in functional interface, calling mode and operation stability is realized, and the problems of poor compatibility and host crash caused by underlying platform difference and cross-language interaction are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a unified interface implementation method and system for cross-platform office plugins. Background Technology

[0002] In existing office software plugin development, to adapt to different operating systems such as Windows and macOS, developers typically need to implement underlying functional modules separately for each platform. Due to significant differences in operating system architecture, office software API support, and script execution environments—for example, early versions of macOS PowerPoint did not support dynamic Ribbons, lacked the .NET Open XML SDK, and required cross-language interaction with native languages ​​like Swift via VBA—code reuse across different platforms is difficult, necessitating the independent development and maintenance of multiple implementations. Especially during cross-language data transfer, the lack of unified security control over the lifecycle of string encoding (such as UTF-16) pointers and memory access boundaries easily leads to memory overflows, dangling pointers, and even host application crashes, severely restricting plugin stability and cross-platform consistency. Therefore, there is an urgent need for a cross-platform office plugin implementation solution that can shield underlying platform differences, ensure cross-language interaction security, and support a unified invocation and callback mechanism. Summary of the Invention

[0003] In view of this, the present invention proposes a unified interface implementation method and system for cross-platform office plugins, which can achieve uniformity in functional interfaces and calling methods for cross-operating system office plugins. The present invention provides the following technical solution: A unified interface implementation method for cross-platform office plugins includes: A platform adaptation layer is loaded in the host office software, and the platform adaptation layer calls the corresponding local implementation modules under different operating systems; The platform adaptation layer receives call requests from the front-end interface and matches the corresponding local processing function based on the predefined path identifier. The local processing function is provided by the local implementation module of each platform. During the execution of the local processing function, if cross-language data interaction with the host script environment is involved, a constrained safe memory read mechanism is adopted to prevent host crashes due to pointer out of bounds or improper lifecycle management. After the local processing function completes its execution, the processing result is returned to the front-end interface through a unified callback channel to support multiple response modes.

[0004] Optionally, the platform adaptation layer loaded in the host office software includes: On the macOS platform, the PowerPoint Add-in (PPAM) file is used as the plugin entry point, and the embedded native dynamic link library is loaded in the VBA script environment; On the Windows platform, natively implemented modules are loaded via the .NET Plugin Framework. The native dynamic link library or .NET plugin module encapsulates the local function implementation of the corresponding operating system and provides a consistent calling interface for unified scheduling by the platform adaptation layer.

[0005] Optionally, the local processing function declares its corresponding path identifier to the platform adaptation layer through an automatic registration mechanism when the plugin starts. The path identifier is a hierarchical path composed of multi-level strings. The platform adaptation layer constructs a multi-level routing structure based on all registered hierarchical paths, and when a call request is received, it matches the routing structure level by level according to the path identifier in the request until the corresponding local processing function is located and called.

[0006] Optionally, the constrained secure memory read mechanism includes: For pointer data from the host script environment, boundary identification is performed using platform-adaptive terminator detection or preset length limits; Based on the identified boundaries, block memory copy operations are performed, accessing only small and contiguous memory regions each time, avoiding direct reading of entire blocks of memory with unknown accessibility; Set a global character limit during the copying process; when the limit is reached, force the reading to terminate and return the acquired content. The target buffer is pre-allocated based on the actual length of the detected data, and then the raw bytes are directly moved to the target buffer to avoid encoding conversion; When a null pointer exception, invalid address, or memory access exception is detected, the exception is automatically caught and a null value is safely returned to prevent the host application from crashing.

[0007] Optionally, the unified callback channel includes the following response modes: Synchronous response mode is used to return the execution result immediately, while the caller remains blocked until the result is received; The progress push mode is used to transmit intermediate status or progress information to the caller in batches during the execution of a long-running task. Asynchronous completion mode is used to notify the caller in a non-blocking manner after the task is completed, allowing the caller to continue other operations during task execution; The response mode is exposed through a unified callback interface. The local processing function selects the appropriate response mode according to the business scenario and looks up the corresponding front-end callback function in the callback mapping table registered by the global event listener manager for invocation.

[0008] Optionally, after the platform adaptation layer is loaded, the method further includes: Receive an event registration request from the front-end interface, the event registration request including the host event type to be listened to and the corresponding front-end callback function identifier; Store the mapping relationship between the event types and callback function identifiers in the global event listener manager; When the host office software triggers the event type, it retrieves the corresponding callback function identifier from the global event listener manager and calls the callback function registered by the front end through the unified callback channel.

[0009] This invention further discloses a unified interface implementation system for cross-platform office plugins, comprising: The platform adaptation layer loading module is used to load the platform adaptation layer in the host office software. The platform adaptation layer calls the corresponding local implementation module under different operating systems. The request route matching module is used to receive call requests from the front-end interface through the platform adaptation layer, and match the corresponding local processing function based on the predefined path identifier. The local processing function is provided by the local implementation module of each platform. The secure memory interaction module is used to employ a constrained secure memory reading mechanism when cross-language data interaction with the host script environment is involved during the execution of the local processing function, in order to prevent host crashes caused by pointer out of bounds or improper lifecycle management. The unified callback channel module is used to return the processing result to the front-end interface through a unified callback channel after the local processing function is executed, so as to support multiple response modes.

[0010] The present invention further discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0011] The present invention further discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described method.

[0012] The present invention further discloses a computer program product, including a computer program that implements the above-described method when executed by a processor.

[0013] According to the technical solution of this invention, by loading a platform adaptation layer into the host office software, local implementation modules under different operating systems can be uniformly scheduled, and local processing functions are matched based on predefined path identifiers. This shields the differences in API support, plugin loading mechanisms, and development frameworks between platforms such as Windows and macOS. Combined with the introduced constrained and secure memory read mechanism, it effectively avoids host crashes caused by UTF-16 pointer out-of-bounds errors and chaotic lifecycle management. At the same time, the unified callback channel supports synchronous replies, progress pushes, and asynchronous completion response modes, achieving consistency in functional interfaces, calling methods, and operational stability for cross-operating system office plugins. This effectively solves the problems of poor compatibility and host crashes caused by differences in underlying platforms and cross-language interaction. Attached Figure Description

[0014] For illustrative and not limiting purposes, the present invention will now be described in conjunction with embodiments and accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a unified interface implementation method for a cross-platform office plugin according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the components of a unified interface implementation system for a cross-platform office plugin according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of the electronic device in an embodiment of the present invention. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0016] It should be noted that, where there is no conflict, the embodiments and features of the embodiments in this application can be combined with each other. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0017] refer to Figure 1 This embodiment discloses a unified interface implementation method for cross-platform office plugins, which includes the following steps: S100: Load the platform adaptation layer in the host office software. The platform adaptation layer calls the corresponding local implementation module under different operating systems.

[0018] This implementation uses a typical scenario with Microsoft PowerPoint as the host office software. Specifically, on macOS, the platform adaptation layer uses the PowerPoint Add-in File (PPAM) as the plugin entry point. When a user installs the plugin, PowerPoint automatically loads the PPAM file upon startup. This file contains a VBA script project. During the initialization phase, the VBA script project dynamically loads the native dynamic link library (dylib) embedded in the PPAM resources. This dylib is compiled from Swift and encapsulates macOS-specific functionalities, such as PowerPoint object model manipulation, system-level file access, and communication bridging with WebView. On Windows, the platform adaptation layer utilizes PowerPoint's COM add-in mechanism, automatically injected by the .NET plugin framework when the Office process starts. This framework loads a compiled .NET assembly, which encapsulates native Windows functionalities such as document processing based on the Open XML SDK and Ribbon interface customization. Crucially, both the dylibs on macOS and the .NET assemblies on Windows strictly adhere to a unified interface specification for exposing functionality. On macOS, Swift code defines method signatures through the Objective-C public protocol; on Windows, C# code implements the same method signatures through a public interface class. The platform adaptation layer automatically selects the corresponding platform's native implementation module at runtime using conditional compilation directives, eliminating the need for upper-layer callers to be aware of underlying differences. This eliminates the problem of redundant plugin development caused by differences in the underlying operating system architecture. Developers only need to maintain a unified interface definition to deploy on both Windows and macOS platforms. Furthermore, by isolating platform-related code within the native implementation module, it avoids version compatibility risks that might arise from direct coupling between VBA and native code, improving the long-term maintainability and operational stability of the plugin, and providing fundamental architectural support for the industrial development of cross-platform office plugins.

[0019] S200: Receive an event registration request from the front-end interface, the event registration request including the host event type to be listened to and the corresponding front-end callback function identifier; store the mapping relationship between the event type and the callback function identifier in the global event listener manager; when the host office software triggers the event type, retrieve the corresponding callback function identifier from the global event listener manager, and call the front-end registered callback function through the unified callback channel.

[0020] Specifically, once the platform adaptation layer loads, the front-end interface (JavaScript in WebView) sends an event registration request to the host via a pre-defined communication interface. This request includes the type of host event to be listened to and a unique string ID generated by the front-end. This request is relayed through the VBA script layer to the global event listener manager (EventCenter) implemented in Swift. The EventCenter internally maintains an event-callback mapping table, stored in a dictionary structure, recording the mapping between received event types and callback function IDs. When PowerPoint triggers a host event, such as a user performing a save operation, the VBA script layer captures the event and calls the event notification interface registered in the Swift layer. The Swift layer queries the mapping table in the EventCenter based on the event type, retrieves the corresponding callback function ID, and returns the event data and callback ID to the front-end interface through a defined unified callback channel. The front-end matches the local JavaScript function based on the callback ID and executes it, completing the event response.

[0021] As can be seen, by centrally managing event subscription relationships through a global event listener manager, the front end does not need to be aware of the underlying details of cross-language interaction between VBA and Swift, effectively avoiding memory leaks and host crashes caused by direct manipulation of VBA objects in traditional solutions. At the same time, the event registration and triggering process is completely decoupled, and the front end can dynamically subscribe to any host event, which significantly improves the scalability and maintenance efficiency of the plugin and provides technical support for the stable operation of cross-platform office plugins in complex event scenarios.

[0022] S300: Receives call requests from the front-end interface through the platform adaptation layer, and matches the corresponding local processing function based on the predefined path identifier. The local processing function is provided by the local implementation module of each platform.

[0023] The front-end interface initiates a call request through a unified communication interface. This request includes predefined path identifiers and parameter data. During the plugin initialization phase, the platform adaptation layer constructs route mapping relationships through an automatic registration mechanism. Specifically, when the local implementation modules of each platform start up, such as Swift dynamic libraries on macOS or .NET modules on Windows, they traverse all exposed local processing functions. Each function declares its corresponding array of path identifiers through a protocol; for example, Swift uses the AutoRegisterableMethod protocol to implement the methodChain property. The platform adaptation layer collects these declarations and constructs a multi-level route structure, where each node corresponds to a string identifier in the path hierarchy. When a front-end call request is received, the platform adaptation layer splits the path identifiers in the request hierarchically and matches nodes level by level in the route tree. If the complete path is matched successfully, the corresponding local processing function is located, and the parameter data is passed to that function for execution; if the match fails, an error message is returned. This step eliminates the maintenance cost of traditional hard-coded routing tables through an automatic registration mechanism. New features only need to declare path identifiers in the local module to be automatically included in the scheduling system. The multi-level routing structure accurately maps the business function level, enabling cross-platform plugins to provide consistent calling interfaces on Windows and macOS. Developers do not need to write differentiated routing logic for different platforms. It significantly improves the robustness of cross-platform calls and provides a technical foundation for the efficient iteration and unified delivery of office plugins.

[0024] S400: During the execution of the local processing function, if cross-language data interaction with the host script environment is involved, a constrained safe memory read mechanism is adopted to prevent host crashes due to pointer out of bounds or improper lifecycle management.

[0025] In this step, when the local processing function needs to read a UTF-16 encoded string pointer from the host scripting environment (VBA), boundary identification is performed first. Specifically, on macOS, since VBA does not provide string length, a platform-adaptive terminator detection mechanism is used, scanning character by character from the pointer's starting position until a double-byte null terminator (0x0000) is encountered; on Windows, the preset length parameter passed by the .NET environment is used directly. Subsequently, based on the identified boundaries, block memory copying is performed, dividing the area to be read into contiguous small memory intervals, for example, copying no more than 1024 characters at a time, accessing only the current small block of memory, avoiding direct reading of the entire unknown accessibility area. During the copying process, a global character limit is set; when the cumulative number of copied characters reaches the limit, reading is immediately terminated and the acquired content is returned. Simultaneously, a target buffer is pre-allocated based on the actual detected valid length, and the original UTF-16 byte stream is directly moved to this buffer, avoiding any encoding conversion operations throughout the process. If a null pointer, invalid memory address, or memory access exception is detected during the process, the exception is automatically caught and an empty string is returned to ensure the host application does not crash. For example, when VBA passes a slide title pointer to a Swift function, this mechanism allows for safe reading of the content, preventing the PowerPoint process from terminating even if the VBA object has been prematurely released. This demonstrates that it solves the host crash problem caused by pointer out-of-bounds errors or inconsistent object lifetimes in cross-language interactions; through block copying and upper bound constraints, it effectively defends against malicious excessively long string attacks, while the zero-casting construction strategy significantly reduces CPU resource consumption; the globally unified safe reading mechanism eliminates the need for developers to repeatedly write protective code at each interaction point, greatly improving the robustness and development efficiency of cross-platform plugins and providing a fundamental guarantee for the long-term stable operation of office software plugins.

[0026] S500: After the local processing function is executed, the processing result is returned to the front-end interface through a unified callback channel to support multiple response modes.

[0027] Specifically, after the local processing function completes execution, the corresponding response mode is selected based on the business scenario: for immediate operations, a synchronous response mode is used, directly constructing a result data packet and returning it immediately through the callback channel, with the caller's front-end interface in a blocked waiting state; for time-consuming tasks, a progress push mode is used, generating progress data packets in batches during task execution and pushing them to the front-end multiple times through the same callback channel; when the task is finally completed, it switches to asynchronous completion mode, constructing a data packet containing the final result for non-blocking notification. All data packets are transmitted through a unified callback interface, provided by the platform adaptation layer and internally linked to a global event listener manager; the manager accurately routes the data packet to the corresponding front-end JavaScript function based on the callback function identifier provided during front-end registration.

[0028] By using a single callback channel in this step to support three response modes, the redundant architecture of designing independent communication paths for different interaction types in traditional solutions is eliminated. The ability to dynamically switch between synchronous response, asynchronous completion, and progress advancement modes enables the plugin to accurately adapt to the full range of needs, from millisecond-level queries to hourly-level tasks, significantly improving the front-end interactive experience. The global event listener manager ensures accurate callback delivery, avoiding memory leaks caused by improper callback function lifecycle management in cross-language environments, and making the stability of plugins on platforms such as macOS reach the same level as that on Windows platforms.

[0029] This invention achieves unified scheduling across operating systems by loading a platform adaptation layer into the host office software. It accurately locates local processing functions based on automatic registration of predefined path identifiers and a multi-level routing matching mechanism. Combined with a constrained and secure memory read mechanism for cross-language data interaction, it solves the host crash problem caused by pointer out-of-bounds errors and improper lifecycle management. Furthermore, it dynamically supports three response modes—synchronous response, progress push, and asynchronous completion—through a unified callback channel, and uses a global event listener manager to implement event registration and precise callbacks. Thus, while maintaining complete consistency in external interfaces, it effectively shields the underlying differences between platforms such as Windows and macOS, significantly reducing the development and maintenance costs of multi-platform plugins, reducing the host application crash rate to a negligible level, and improving the functionality, operational stability, and user experience of cross-platform office plugins.

[0030] refer to Figure 2 This embodiment further discloses a unified interface implementation system for cross-platform office plugins, including a platform adaptation layer loading module 21, an event listening management module 22, a request route matching module 23, a secure memory interaction module 24, and a unified callback channel module 25, which are described in detail below: The platform adaptation layer loading module 21 is used to load the platform adaptation layer in the host office software. The platform adaptation layer calls the corresponding local implementation modules under different operating systems, including: on the macOS platform, using the PowerPoint Add-in File (PPAM) as the plugin entry point, loading the embedded native dynamic link library in the VBA script environment; on the Windows platform, loading the local implementation module through the .NET plugin framework; wherein, the native dynamic link library or .NET plugin module respectively encapsulates the local function implementation of the corresponding operating system and provides a consistent calling interface for unified scheduling by the platform adaptation layer.

[0031] The event listening management module 22 is used to receive event registration requests from the front-end interface. The event registration request includes the host event type to be listened to and the corresponding front-end callback function identifier. The mapping relationship between the event type and the callback function identifier is stored in the global event listening manager. When the host office software triggers the event type, the corresponding callback function identifier is retrieved from the global event listening manager, and the front-end registered callback function is called through the unified callback channel.

[0032] The request route matching module 23 is used to receive call requests from the front-end interface through the platform adaptation layer, and match the corresponding local processing function based on the predefined path identifier. The local processing function is provided by the local implementation module of each platform.

[0033] The secure memory interaction module 24 is used to employ a constrained secure memory reading mechanism during the execution of the local processing function if cross-language data interaction with the host script environment is involved. This mechanism aims to prevent host crashes due to pointer out-of-bounds errors or improper lifecycle management. The mechanism includes: identifying the boundaries of pointer data from the host script environment using platform-adaptive terminator detection or preset length limits; performing block-based memory copy operations based on the identified boundaries, accessing only small, contiguous memory regions at a time to avoid directly reading entire blocks of memory with unknown accessibility; setting a global character limit during the copy process, forcibly terminating the read and returning the acquired content when the limit is reached; pre-allocating a target buffer based on the detected actual data length, and then directly transferring the original bytes to the target buffer to avoid encoding conversion; and automatically capturing exceptions and safely returning null values ​​when null pointers, invalid addresses, or memory access anomalies are detected to prevent host application crashes.

[0034] The unified callback channel module 25 is used to return the processing result to the front-end interface through a unified callback channel after the local processing function has completed execution, in order to support multiple response modes. The unified callback channel includes the following response modes: synchronous response mode, which returns the execution result immediately, with the caller remaining blocked until the result is received; progress push mode, which transmits intermediate status or progress information to the caller in batches during long-running tasks; and asynchronous completion mode, which notifies the caller non-blockingly after the task is completed, allowing the caller to continue other operations during task execution. These response modes are exposed through a unified callback interface. The local processing function selects the appropriate response mode based on the business scenario and searches for the corresponding front-end callback function in the callback mapping table registered in the global event listener manager for invocation.

[0035] Figure 3 A schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 3 As shown, the electronic device 50 includes: a processor 501, a memory 502, and a bus 503; The processor 501 and the memory 502 communicate with each other via the bus 503; the processor 501 is used to call the program instructions in the memory 502 to execute the methods provided in the above-described embodiments.

[0036] This embodiment provides a non-transitory computer-readable storage medium that stores computer instructions that cause a computer to execute the methods provided in the above-described embodiments.

[0037] Those skilled in the art will understand that all or part of the steps of the above-described method implementation can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above-described method implementation. The aforementioned storage medium includes various storage media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0038] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0039] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of each embodiment or some parts of the embodiments.

[0040] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A unified interface implementation method for cross-platform office plugins, characterized in that, include: A platform adaptation layer is loaded in the host office software, and the platform adaptation layer calls the corresponding local implementation modules under different operating systems; The platform adaptation layer receives call requests from the front-end interface and matches the corresponding local processing function based on the predefined path identifier. The local processing function is provided by the local implementation module of each platform. During the execution of the local processing function, if cross-language data interaction with the host script environment is involved, a constrained safe memory read mechanism is adopted to prevent host crashes due to pointer out of bounds or improper lifecycle management. After the local processing function completes its execution, the processing result is returned to the front-end interface through a unified callback channel to support multiple response modes.

2. The unified interface implementation method for cross-platform office plugins according to claim 1, characterized in that, The loading of the platform adaptation layer in the host office software includes: On the macOS platform, the PowerPoint Add-in (PPAM) file is used as the plugin entry point, and the embedded native dynamic link library is loaded in the VBA script environment; On the Windows platform, natively implemented modules are loaded via the .NET Plugin Framework. The native dynamic link library or .NET plugin module encapsulates the local function implementation of the corresponding operating system and provides a consistent calling interface for unified scheduling by the platform adaptation layer.

3. The unified interface implementation method for cross-platform office plugins according to claim 1, characterized in that, The local processing function declares its corresponding path identifier to the platform adaptation layer through an automatic registration mechanism when the plugin starts. The path identifier is a hierarchical path composed of multi-level strings. The platform adaptation layer constructs a multi-level routing structure based on all registered hierarchical paths, and when a call request is received, it matches the routing structure level by level according to the path identifier in the request until the corresponding local processing function is located and called.

4. The unified interface implementation method for cross-platform office plugins according to claim 1, characterized in that, The constrained secure memory read mechanism includes: For pointer data from the host script environment, boundary identification is performed using platform-adaptive terminator detection or preset length limits; Based on the identified boundaries, block memory copy operations are performed, accessing only small and contiguous memory regions each time, avoiding direct reading of entire blocks of memory with unknown accessibility; Set a global character limit during the copying process; when the limit is reached, force the reading to terminate and return the acquired content. The target buffer is pre-allocated based on the actual length of the detected data, and then the raw bytes are directly moved to the target buffer to avoid encoding conversion; When a null pointer exception, invalid address, or memory access exception is detected, the exception is automatically caught and a null value is safely returned to prevent the host application from crashing.

5. The unified interface implementation method for cross-platform office plugins according to claim 1, characterized in that, The unified callback channel includes the following response modes: Synchronous response mode is used to return the execution result immediately, while the caller remains blocked until the result is received; The progress push mode is used to transmit intermediate status or progress information to the caller in batches during the execution of a long-running task. Asynchronous completion mode is used to notify the caller in a non-blocking manner after the task is completed, allowing the caller to continue other operations during task execution; The response mode is exposed through a unified callback interface. The local processing function selects the appropriate response mode according to the business scenario and looks up the corresponding front-end callback function in the callback mapping table registered by the global event listener manager for invocation.

6. The unified interface implementation method for cross-platform office plugins according to claim 1, characterized in that, After the platform adaptation layer is loaded, the method further includes: Receive an event registration request from the front-end interface, the event registration request including the host event type to be listened to and the corresponding front-end callback function identifier; Store the mapping relationship between the event types and callback function identifiers in the global event listener manager; When the host office software triggers the event type, it retrieves the corresponding callback function identifier from the global event listener manager and calls the callback function registered by the front end through the unified callback channel.

7. A unified interface implementation system for cross-platform office plugins, characterized in that, include: The platform adaptation layer loading module is used to load the platform adaptation layer in the host office software. The platform adaptation layer calls the corresponding local implementation module under different operating systems. The request route matching module is used to receive call requests from the front-end interface through the platform adaptation layer, and match the corresponding local processing function based on the predefined path identifier. The local processing function is provided by the local implementation module of each platform. The secure memory interaction module is used to employ a constrained secure memory reading mechanism when cross-language data interaction with the host script environment is involved during the execution of the local processing function, in order to prevent host crashes caused by pointer out of bounds or improper lifecycle management. The unified callback channel module is used to return the processing result to the front-end interface through a unified callback channel after the local processing function is executed, so as to support multiple response modes.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method of any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-6.

Images