CN113608727B - Code processing method, device and system for visual programming - Google Patents
Code processing method, device and system for visual programming Download PDFInfo
- Publication number
- CN113608727B CN113608727B CN202110890840.XA CN202110890840A CN113608727B CN 113608727 B CN113608727 B CN 113608727B CN 202110890840 A CN202110890840 A CN 202110890840A CN 113608727 B CN113608727 B CN 113608727B
- Authority
- CN
- China
- Prior art keywords
- data
- view
- code
- layer
- pin
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a method, a device and a system for processing visually programmed codes, wherein in the method, execution flow data of a view is acquired from an engine layer, and the execution flow data comprises the following steps: and the code view and the function data corresponding to the drawn code view are subjected to data structure disassembly to obtain subcode data, the subcode data and the function data are stored in a memory layer according to a preset data structure to obtain data after being transferred, and finally the data after being transferred are transferred into hard disk data according to a preset format and are stored in a storage layer. According to the technical scheme, after the data of the engine layer are disassembled, the disassembled data are stored according to the self-defined data structure, so that the blueprint code is extracted, and a plaintext data base is provided for other development processes.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, and a system for processing a code by visual programming.
Background
The visual programming (blueprint) has the characteristics of quick operation, low learning threshold, visual graphics and the like, is widely applied to the programming and development fields of non-programming professions, has high use value for those skilled in the fields, can reduce communication and manpower cost, and shortens the design and development period.
When a technician develops a host job using a certain engine (e.g., a fantasy engine), the related functions of the blueprint are commonly used, i.e., the blueprint can be opened in the fantasy engine.
In practical application, the blueprint can only be opened through the illusion engine, and cannot be separated from the automated analysis of the illusion engine, so that the blueprint cannot provide use value for other development processes, and thus cannot meet various development requirements.
Disclosure of Invention
The embodiment of the application provides a code processing method, device and system for visual programming, which are used for solving the problems that the visual code can only be opened through an adaptation engine and can not be separated from automatic analysis of the engine, and further the use value can not be provided for other development processes, so that various development requirements can not be met, and the like.
In a first aspect, an embodiment of the present application provides a method for visually programming code processing, applied to a computer device, where the method includes:
obtaining execution stream data of a view from an engine layer, the execution stream data comprising: a code view and functional data corresponding to the code view are drawn;
performing data structure disassembly on the code view to obtain subcode data, wherein the subcode data comprises: information of at least one node, an identification of the view, and an identification of other views associated with the view;
Storing the sub-code data and the functional data to a memory layer according to a preset data structure to obtain the data after the transfer;
and converting the data after the transfer into hard disk data according to a preset format and storing the hard disk data into a storage layer.
In one possible design of the first aspect, the information for each node includes: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: the identification of at least one pin and the identification of other pins associated with the at least one pin.
In another possible design of the first aspect, the preset data structure includes: an execution flow data table, the execution flow data table comprising: a data area of the view and a data area of a function associated with the view, the data area of the view comprising: at least one junction region, the junction region comprising: at least one pin area, the functional data area associated with the view including pin information for at least one pin.
In yet another possible design of the first aspect, the obtaining, from the engine layer, execution flow data of the view includes:
And acquiring execution flow data of the view from resource data corresponding to the view of the engine layer.
In this possible design, the obtaining the execution flow data of the view from the resource data corresponding to the view of the engine layer includes:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view stored in a tree structure from the engine layer, wherein the code view comprises the first resource data and the second resource data;
and acquiring different parts of the first resource data and the second resource data as the functional data.
In still another possible design of the first aspect, the storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain the data after the transferring includes:
establishing a data object with a structure of the preset data structure in the memory layer;
performing assignment reload processing on the sub-code data and the functional data to obtain extracted execution stream data;
copying the extracted execution stream data into the data object according to the data structure to obtain the data after the transfer.
In yet another possible design of the first aspect, the preset format includes: and converting the transferred data into hard disk data according to a preset format by the JSON format, and storing the hard disk data into a storage layer, wherein the JSON format comprises the following steps:
converting the transferred data into the hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to the storage layer.
In a second aspect, an embodiment of the present application provides a visually programmed code processing apparatus, applied to a computer device, the apparatus including: the device comprises an acquisition module, a processing module and a storage module;
the obtaining module is configured to obtain, from an engine layer, execution flow data of a view, where the execution flow data includes: a code view and functional data corresponding to the code view are drawn;
the processing module is configured to disassemble the data structure of the code view to obtain sub-code data, where the sub-code data includes: information of at least one node, an identification of the view, and an identification of other views associated with the view;
the storage module is used for storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain the data after the data are transferred, and converting the data after the data are transferred to hard disk data according to a preset format and storing the hard disk data to the storage layer.
In one possible design of the second aspect, the information of each node includes: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: the identification of at least one pin and the identification of other pins associated with the at least one pin.
In another possible design of the second aspect, the preset data structure includes: an execution flow data table, the execution flow data table comprising: a data area of the view and a functional data area associated with the view, the data area of the view comprising: at least one junction region, the junction region comprising: at least one pin area, the functional data area associated with the view including pin information for at least one pin.
In a further possible design of the second aspect, the acquisition module is specifically configured to:
and acquiring execution flow data of the view from resource data corresponding to the view of the engine layer.
In this possible design, the acquisition module is specifically configured to:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view stored in a tree structure from the engine layer, wherein the code view comprises the first resource data and the second resource data;
And acquiring different parts of the first resource data and the second resource data as the functional data.
In still another possible design of the second aspect, the storage module stores the sub-code data and the functional data to a memory layer according to a preset data structure, to obtain the data after the transferring, which is specifically configured to:
establishing a data object with a structure of the preset data structure in the memory layer;
performing assignment reload processing on the sub-code data and the functional data to obtain extracted execution stream data;
copying the extracted execution stream data into the data object according to the data structure to obtain the data after the transfer.
In yet another possible design of the second aspect, the preset format includes: and if the JSON format is adopted, the storage module converts the data which are transferred into hard disk data according to a preset format and stores the hard disk data into a storage layer, wherein the storage module is particularly used for:
converting the transferred data into the hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to the storage layer.
In a third aspect, embodiments of the present application provide a visually programmed code processing system, comprising: the system comprises a user layer, an engine layer, a memory layer and a storage layer;
The user layer is used for displaying views;
the engine layer is configured to provide execution flow data in resource data corresponding to the view, where the execution flow data includes: the method comprises the steps of code view and drawing functional data corresponding to the code view, wherein the data structure of the code view is disassembled to obtain subcode data;
the memory layer is used for storing the sub-code data and the functional data according to a preset data structure, and the obtained data after the transfer is obtained;
the storage layer is used for storing hard disk data after converting the data after being transferred according to a preset format.
In a fourth aspect, embodiments of the present application provide a computer device, comprising: a processor, a memory;
the memory stores computer-executable instructions;
the processor executes the computer-executable instructions to cause the computer device to perform the visually programmed code processing method as described in the first aspect and various possible designs described above.
In a fifth aspect, embodiments of the present application provide a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, are configured to implement a code processing method for visual programming as described in the first aspect and in various possible designs described above.
In a sixth aspect, embodiments of the present application provide a computer program product comprising a computer program for implementing a visually programmed code processing method as described in the first aspect and various possible designs above when executed by a processor.
The embodiment of the application provides a method, a device and a system for processing visually programmed codes, wherein in the method, execution stream data of a view is obtained from an engine layer, and the execution stream data comprises the following steps: the method comprises the steps of drawing functional data corresponding to a code view, carrying out data structure disassembly on the code view to obtain subcode data, storing the subcode data and the functional data into a memory layer according to a preset data structure to obtain data after being transferred, and finally converting the data after being transferred into hard disk data according to a preset format and storing the hard disk data into a storage layer. According to the technical scheme, after the data of the engine layer are disassembled, the disassembled data are stored according to the self-defined data structure, so that the blueprint code is extracted, and a plaintext data base is provided for other development processes.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure.
FIG. 1 is a schematic diagram of a framework of a visually programmed code processing system according to an embodiment of the present application;
fig. 2 is a schematic flow chart of a first embodiment of a code processing method for visual programming according to an embodiment of the present application;
fig. 3 is a schematic diagram of acquiring execution stream data according to an embodiment of the present application;
FIG. 4 is a schematic diagram illustrating a data structure according to an embodiment of the present disclosure;
FIG. 5 is a schematic diagram of assignment reloading processing provided in an embodiment of the present application;
FIG. 6 is a schematic diagram of data storage according to an embodiment of the present disclosure;
fig. 7 is a schematic diagram of a preset data structure provided in an embodiment of the present application;
FIG. 8 is a schematic diagram of format storage provided in an embodiment of the present application;
FIG. 9 is a schematic diagram of a visually programmed code processing apparatus according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application.
Specific embodiments of the present disclosure have been shown by way of the above drawings and will be described in more detail below. These drawings and the written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the disclosed concepts to those skilled in the art by reference to specific embodiments.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.
Before introducing embodiments of the present application, the terminology to which the present application relates is first explained:
phantom 4 Engine (universal Engine 4, ue 4): the game engine for opening source, business charge and free learning is the 4 th generation, has very powerful function and is mainly used for manufacturing host games;
UE resource file (uasset): the UE has a self-contained resource file format, stores all types of resources in a binary form, and only the UE can analyze the resources;
JS object numbered musical notation (JavaScript Object Notation, JSON): a lightweight data exchange format adopts a text format completely independent of programming language to store and represent data, is easy for a user to read, write and analyze by a machine, and can effectively improve network transmission efficiency;
Difference File (Difference File, diff): an executable tool program is used for comparing the difference between two files and recording and displaying different information, so that the generated file is a Diff file;
source code control system (Source Code Control System, SCCS): the system scheme of controlling various source codes of different versions by a sleeve is referred, which is convenient for the development of software and the collaborative work of users;
subversion (SVN)): the version control system of the open source code realizes the management of shared resources and centralization by adopting the efficient management of the branch management system, namely being used for developing the same project together by a plurality of persons;
performance (P4): a version management tool has the characteristics of portability and rapidness, and supports various use modes such as a graphical user interface (Graphical User Interface, GUI), a command line and the like.
The background art to which the present application relates is explained below:
along with the rapid development of visual programming ideas, the method is widely applied to the design and development fields of art, programs, industry, aerospace, medical treatment and the like. Visualization programming is also being developed and supported by various business engines, such as UE 4 (illusive engine), unity, and engine massiah.
Among them, various 3A game (triple a game) hosts developed using the UE 4 engine are widely used for visual programming (blueprints).
The visual programming has the characteristics of visual graphics, low learning threshold and quick learning, has high practical value for non-programming professional design or development personnel, can reduce communication and labor cost, and shortens design and development period. However, there are some disadvantages, such as poor portability, large collaboration difficulty, and no versatility, in which the strong binding of the visualized code and the engine is a major disadvantage affecting the application value and development thereof.
Taking the UE 4 as an example, the blueprint has strong function and convenient use, but the blueprint can only be opened by using the UE 4 engine, can not be separated from the engine for automatic analysis, conflicts with the traditional development flow of our department, can not be used by common tools, and greatly influences the project development efficiency. Because the blueprint can only look at Diff in the engine editor and does not provide a merge auxiliary function, the blueprint can only be manually completed by a developer, has high maintenance cost, cannot support multi-branch development, directly influences a project development mode, and causes extremely poor stability of a project version, so that the maintenance cost of the developer is forced to be improved. For most projects of UE 4, development using blueprints is avoided, and it is desirable to replace or bypass the blueprint function of UE 4 with text programming.
However, the blueprint itself is closely related to the engine of the UE 4, many powerful functions are based on the blueprint, and discarding the blueprint has to discard part of the engine functions, thereby affecting the practical value of the engine and additionally generating redundant working costs for bypassing the blueprint.
Taking the Diff presentation function of the UE 4 engine as an example, the UE 4 provides the Diff viewing function only in the graphical editor mode, and discusses with the Graph (i.e., visual view) in the blueprint. Taking a blueprint resource as an example, specific view Diff contents can be viewed through a graphical interface.
Specifically, in the Diff browsing list of the display interface, the changed graphs are listed, and the user can freely browse the changing content of a certain Graph on the operation interface. The UE 4 provides visual comparison of new and old versions, supports functions of movement, dragging, scaling, annotation and the like, and allows a user to conveniently compare Diff contents between the two versions. The technical implementation procedure of the function is outlined as follows:
1. diff processing is carried out on the resources;
2. drawing a Diff browsing interface and filling data required by the interface;
3. initializing data and drawing a User Interface (UI) Interface;
4. generating detailed Diff content and data;
5. Drawing a view module interface and filling related data;
6. and drawing blueprint views for the new version and the old version respectively.
In particular, the prior art Diff application has the following problems:
firstly, automation is not supported, and the monitoring cost is high;
it is often necessary for a tester to monitor whether the user has modified the code correctly, which is frequent, costly by manpower alone, and prone to overlooking. Therefore, the monitoring needs to be performed in an automatic mode, and the monitoring quality can be ensured under the condition of reducing the labor cost. The Diff of the UE 4 is displayed through an interface, and the Diff information can be checked only through the interface operation manually, so that the automation operation cannot be performed.
Secondly, the code is strongly bound with the engine, and the code cannot be independently used;
the blueprint resource of the UE 4 can only be edited by opening an editor of the UE 4 engine, and a user cannot use the code for other purposes without using the engine or manage the code by using the existing development auxiliary tool, so that the working productivity of the user is greatly limited, and particularly for large projects, the problem brings a plurality of difficulties to team collaborative development.
Thirdly, the method has limitations, and the function expansion can not be performed;
the Diff function provided by the UE 4 is already shaped, only the conventional Diff display is adopted, and the self-development is needed to expand more other functions, and the development based on the editor work function of the UE 4 is limited to a certain extent, so that the expansion and the migration are limited. However, if the Diff data can be extracted, any desired processing of the Diff data can be performed by any technique, including display, comparison, inspection, alarm, error correction, etc., and the migration is not too limited, and can be optionally changed according to the needs and environments, including direct application to other existing tools.
Based on the above-mentioned problems in the prior art, fig. 1 is a schematic frame structure of a code processing system for visual programming according to an embodiment of the present application, so as to solve the above-mentioned technical problems. As shown in fig. 1, the structural schematic includes: a user layer 11, an engine layer 12, a memory layer 13 and a storage layer 14.
Wherein the user layer 11 comprises a view that is visible to the user; the engine layer 12 is configured to provide execution flow data in the resource data corresponding to the view, where the execution flow data includes: the method comprises the steps of a code view and drawing functional data corresponding to the code view, wherein the data structure of the code view is disassembled to obtain subcode data; the memory layer 13 is used for storing the sub-code data and the functional data according to a preset data structure, and the obtained data after the transfer is stored; the storage layer 14 is used for storing hard disk data after converting the data after being converted into a preset format.
In one possible design, the user layer 11 displays the view, acquires execution flow data of the view from resource data corresponding to the view of the engine layer 12, and performs data structure disassembly on a code view in the execution flow data (code view and function data corresponding to the drawing of the code view), so as to obtain subcode data, which may include: the identifiers of the nodes and views, etc. store the subcode data and the functional data to the memory layer 13 according to a preset data structure, so as to form a user-definable data structure (data after being transferred), and for convenience of use, convert the data in the memory layer 13 into hard disk data (data file in a universal format, for example, JSON format) required by the user, and store the hard disk data on the storage layer 14.
The technical conception process of the inventor aiming at the technical problems is as follows: the inventor finds that when the engine runs, the visual codes can be extracted from the engine layer, the extracted visual codes are analyzed and finally transferred into a universal data format which is convenient to use, and the application value can be provided for other development processes, so that various development requirements are met.
The following describes the technical solution of the present application in detail by means of a specific embodiment with a schematic diagram of a frame structure shown in fig. 1. It should be noted that the following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Fig. 2 is a flowchart of a first embodiment of a method for processing visually programmed codes according to an embodiment of the present application. As shown in fig. 2, the method may include the steps of:
step 21, obtaining the execution flow data of the view from the engine layer.
In this step, since the visualized code is strongly bound to the engine, the code cannot be used separately from the engine, and at this time, related information of an interface that can be used to draw a function in a view, that is, execution flow data, for example, diff data of the engine layer, needs to be acquired in the engine layer of the computer device.
Specifically, the execution flow data of the view is obtained from the resource data corresponding to the view of the engine layer.
In one implementation, the manner in which the execution stream data of the view is obtained from the engine layer may be implemented as: namely, diff comparison is performed between resource data corresponding to two different versions of resource data (an old version view and a new version view), and then the Diff comparison is processed, for example, fig. 3 is a schematic diagram of obtaining execution flow data provided in an embodiment of the present application. As shown in fig. 3, resource data 31, related data 32 to draw different (Diff), execution stream data 33, diff data backup 34.
Optionally, first resource data corresponding to the new version view and second resource data corresponding to the old version view stored in a tree structure are acquired from the engine layer, and the code view comprises the first resource data and the second resource data; different parts of the first resource data and the second resource data are acquired as functional data.
The Diff processing may be performed by a generatediff list method of the UE 4 engine itself, so as to obtain a masterdiff list (related data required for drawing a current blueprint Diff interface is stored in a tree form), a realdifference (Diff data backup of the current blueprint, which does not contain information required for drawing, is stored in a tree form), and a graph (Diff data of only a code view of the current blueprint is drawn in the Diff interface and is stored in an array form).
Wherein, the MasterDifferencesList, realDifferences and graphics are coupled, and useful information is extracted from the data according to need, and in the embodiment of the application, only the graphics data is used by taking the extraction of the code view Diff as an example.
Further, the execution flow data 33 includes: code views (old version code view and new version code view), and drawing function data corresponding to the code views.
Specifically, the code views in the execution stream data 33 may be represented by graphics, where graphics includes an old version code view being GraphOld and a new version code view being GraphNew. The function data in the execution stream data is difflistdsource, that is, graphDiffInfo described below.
All node information is contained in GraphOld\GraphNew, and the GraphOld\GraphNew can be used for drawing a visual blueprint. The DiffListSource can be used for drawing the difference between the views of which the Diff reflects the new version and the old version as long as the DiffListSource comprises information of different parts in the views between the new version and the old version, namely the DiffListSource only comprises information of difference.
And step 22, carrying out data structure disassembly on the code view to obtain sub-code data.
In this step, data disassembly is required to be performed on the code view (graphold\graphnew) to obtain each node information of the code view, the identification number (Identity Document, ID) of the code view, and other view identifications related to the code view; further disassembling the information of each node to obtain the information of each pin, the ID of the node and the identifications of other nodes associated with the node; further, each pin information is disassembled to obtain the identification of the pin and the identifications of other pins associated with the pin.
Wherein the information of each node includes: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: the identification of at least one pin and the identification of other pins associated with the at least one pin.
In addition, take GraphDiffInfo for drawing functional data as an example, it contains new node difference information, old node difference information; old pin information and new pin information; a difference type identifier; a summary of the differences that may be displayed, etc.
The two data structures, namely graphold\graphnew, are the same in nature, but the contents are different, taking GraphOld as an example, and fig. 4 is a schematic diagram for disassembling the data structure provided in the embodiment of the present application. As shown in fig. 4, the sub-code data (taking the old version code view as an example) includes: information 41 of the node, identification 42 of the view, identification 43 of other views to which the view is associated; the information 41 of the node includes: pin information 411, identification 412 of the node, and identification 413 of other nodes associated with the node; the pin information 411 includes: the identity 4111 of the pin and the identities 4112 of other pins associated with the pin.
Wherein, the information 41 of the node, the pin information 411 and the identifier 4111 of the pin are at least one respectively.
Specifically, information 41 (Nodes) of the Nodes, including node names, types, locations, pins, etc.;
pin information 411 (Pins), including pin name, type, direction, default value, color, etc.; pin identification 4111 (pinguide), which may be a pin ID, is used to identify the pin identity, and is unique to the blueprint; other pin identifiers 4112 (other pininfo), other pin information, data types are all different, and are not listed here one by one; node identification 412 (NodeGuid), which may be a node ID, is used to identify the node identity, and is unique to the blueprint; the identity 413 (other node info) of other nodes, other node information, data types are all different, and are not listed here one by one; an identification 42 (graphguide) of the view, the view ID, possibly including a plurality of different views in a blueprint, for identifying the identity, the blueprint being unique; other view identifiers 43 (other graphinfo), other view information, and data types are different and are not listed here one by one.
Optionally, the data acquired at this time is the engine layer, and other techniques described below are also required for processing.
And step 23, storing the subcode data and the functional data to a memory layer according to a preset data structure to obtain the data after the transfer.
In this step, in order to facilitate development and implementation and reduce code complexity, a method of reloading assignment operators may be used to complete data extraction operation, and assignment reloading corresponding to engine (for example, UE 4) data is completed in each custom data, that is, in this embodiment, assignment reloading is performed on sub-code data and functional data, so as to obtain extracted execution stream data.
The custom data is subcode data and functional data.
By way of example, the assignment reloading process is performed on the sub-code data and the functional data, and continuing with the above example, the assignment reloading process may be performed by performing graphtodiff=fggraphtodiff operation, and in particular, fig. 5 is a schematic diagram provided in the embodiment of the present application. As shown in fig. 5, the assignment reload processing schematic includes: the stream data assignment reload 51, the sub-code data assignment reload 52, the function data assignment reload 53, the node information assignment reload 54, the pin information assignment reload 55 and the linked pin data assignment reload 56 are performed.
Wherein the performing of the assignment reload 51 of the stream data GraphToDiff may be: graphToDiff = (fggraphtodiff); the assignment override 52 of the subcode data Graph may be: graphToDiff & operator= (UEdGraph); the assignment reload 53 of the functional data GraphDiffInfo may be: graphDiffInfo & operator= (fdiffsinglerosult); the assignment reload 54 of the node information GraphNode may be: graphNode operator = (uedsiphenode); assignment reload 55 of pin information GraphPinGraph may be: graphPinGraph operator = (UEdGraphPin); the assignment reload 56 of the pin data LinkPin for the chain may be: linkPin operator= (uedlkpin).
It should be noted that in the process of assigning heavy load, the difficulty is that the initialization, assignment and type conversion of the custom data, such as pin default values, have different default values according to different data types, and can be uniformly converted into character string types; the enumeration types such as the pin direction and the like can be processed by self and converted into the character string type uniformly.
In addition, a data object with a preset data structure is established in the memory layer, and the data object is used for indicating that the sub-code data and the functional data are stored in corresponding positions in the memory layer.
The preset data structure comprises the following data objects: executing a stream data table, the executing the stream data table comprising: a data area of the view and a data area of a function associated with the view, the data area of the view comprising: at least one junction region, the junction region comprising: at least one pin area.
In this step, in order to record the extracted execution stream data in the memory layer for subsequent use, a custom set of available custom data structures is also required for execution stream data storage.
Fig. 6 is a schematic diagram of data storage according to an embodiment of the present application. As shown in fig. 6, the data storage schematic is illustrated by taking the data copy from the engine layer to the memory layer as an example:
at the engine level, comprising: the execution stream data (Graphs, class FGraphToDiff), specifically: old version code view (GraphOld, class uedpraph); new version code view (GraphNew, class uedpraph); functional data (difflistdsource, class FDiffResultem).
In a memory layer, comprising: custom execution stream data (mygraphics, class GraphToDiff), specifically: custom old version code view (MyGraphOld, class Graph); a custom new version code view (MyGraphNew, class Graph); custom function data (MyDiffListSource, class DiffResultem).
Optionally, the extracted execution stream data is copied to a data object according to the data structure to obtain the data after the transfer.
In one possible implementation, graphs are disassembled into GraphOld, graphNew and DiffListSource, and assignment reloading is performed on three data, and stored to corresponding MyGraphOld, myGraphNew and MyDiffListSource, so as to form MyGraphs.
Fig. 7 is a schematic diagram of a preset data structure according to an embodiment of the present application. As shown in fig. 7, the data structure includes: stream data GraphToDiff71, function data GraphDiffInfo72, subcode data Graph73, node information GraphNode74, pin information GraphPinGraph75, and pin data LinkPin76 in the chain are executed.
The execution flow data 71 table records all sub-code data Graph73 and function data Graph diffinfo72, specifically: old code version view (Graph-Old Graph), new code version view (Graph-New Graph), and inter-version difference information (TArra < Graph diffinfo > diffinfo).
The function data (data area of the function) 72 records all Diff difference information, which is operation identification of the difference type such as a newly added node, a deleted node, a modified pin, etc., for each view, and the difference summary is a literal description of the difference type, specifically: old node difference information (GraphNode-OldNodelnfo), new node difference information (GraphNode-New Nodelnfo), old pin difference information (GraphPin-OldPinlnfo), new pin difference information (GraphPin-New Pinlnfo), difference type identification (FString-DiffTYpe), displayable difference summary (FString-displayString).
The sub-code data (data area of view) 73 is used for recording view data, specifically: view name (FString-GroupName), view ID (FGuid-GroupID), all nodes the view contains (TArra < GroupNode > groupndes).
Node information (node area) 74 records node data, node names, i.e., visual code function names, and node positions, which are positions drawn on a planar background in UE 4, can be used for redrawing references, specifically: node ID (FGuid-NodeID), node name (Ftext-NodeTitle), node name color (FLinearColor-NodeTitleColor), node position-abscissa (int 32-NodePosX), node position-ordinate (int 32-NodePosY), all Pins contained in the node (TArra < GroupPin > Pin).
The pin information (pin area) 75 records pin data, the name of the pin, i.e. the name of the entry parameter or return value of the visual code function, the type of the pin data, i.e. the type of the entry parameter or return value, and the direction of the pin is used for distinguishing whether the entry parameter or the return value, and the chain-to-pin, i.e. the pin of the next other node linked to the current pin, can be understood as parameter transfer, specifically: subordinate node ID (FGuid-OwningNodeID), pin ID (FGuid-PinID), pin name (FNAcme-PinName), pin data type (FNAcme-PinTypeName), pin default value (FString-DefaultValue), other pins of the chain Direction (TArra < LinkPin > LinkToPin), direction of the pins (TEnumAcByte < enum EEdGraphPinDirection > Direction).
The pin data (pin area) 76 of the link direction records the pin data of the link direction, specifically: subordinate node ID (FGuid-OwningNodeID), pin ID (FGuid-PinID).
In summary, by the above data structure, various information of the blueprint code view and Diff data can be recorded.
In addition to the above steps, in order to facilitate the use of the extracted execution stream data stored in the memory layer, the following steps may be further performed.
And step 24, converting the data after being transferred into hard disk data according to a preset format and storing the hard disk data into a storage layer.
In this step, according to the preset format defined by the user, the execution flow data of the memory layer is converted into the storage layer, so that the function in a certain engine can be applied to other development flows (code formats for implementing the function).
In one possible implementation, when the preset format includes JSON format, fig. 8 is a schematic diagram of format storage provided in an embodiment of the present application. As shown in fig. 8, the method conversion using the reload sequence includes: a conversion 81 of stream data GraphToDif, a conversion 82 of sub-code data graphis, a conversion 83 of function data GraphDiffInfo, a conversion 84 of information GraphNode of nodes, a conversion 85 of pin information GraphPinGraph, and a conversion 86 of pin data LinkPin in a chain direction are performed.
Wherein the performing of the conversion 81 of stream data may be: graphToDiff-FJsonObject Serialize (); the conversion 82 of the subcode data may be: graphF-JsonObject Serialize (); the conversion 83 of the functional data may be: graphDiffInfo-FJsonObject Serialize (); the conversion 84 of the information of the nodes may be: graphnode-FJsonObject Serialize (); the conversion 85 of the pin information may be: graphPinGraph-FJsonObject Serialize (); the conversion 86 of the pin data of the chain may be: linkPin-FJsonObject. Serialize ().
Optionally, the method of reloading the sequence is to convert the data after being transferred into hard disk data in JSON format by adopting a serialization method, wherein the JSON output type fjson object carried by the UE 4 is used, and on the basis, custom packaging is performed, and the functions can be divided into the following types:
1. inserting a string key value pair into the FJsonObject;
2. inserting FJsonObject nested objects into FJsonObject;
3. inserting an FJsonObject array into the FJsonObject;
4. acquiring FJsonObject nested objects in a certain FJsonObject object;
5. the FJSOnObject object is serialized into a Json string and stored as a Json file.
If other data types which are not included, such as integer, floating point number, boolean, enumeration and the like, can be converted into character string key value pairs for processing, so that the custom data in the memory can be simply and conveniently transferred into a general Json file.
Further, the hard disk data in JSON format is stored to the storage layer. In the storage layer, it is possible to copy freely or implement the functions for other blueprints.
In one possible implementation, after the above steps are combined to convert one UE 4 blueprint visualization code into an example of a Json file, at the Diff presentation interface of another blueprint, the Diff content is a new node, i.e. the execution flow data is applied by another blueprint.
The DiffInfo data in the Json file after partial parsing is shown below, and it can be seen by comparing the part of the double solid line frame with the part of the single solid line frame that a node is added, resulting in a change in the pins:
/>
/>
the new and old view Graph data in the Json file after partial parsing is shown below, and the partial pin names, data types and default values in the new node 'Print String' are shown from the part of the solid line frame, so that the new and old view Graph data is consistent with the actual visualized code content:
/>
the visualized programmed code processing method provided by the application obtains execution flow data of a view from an engine layer, wherein the execution flow data comprises the following steps: the method comprises the steps of drawing functional data corresponding to a code view, carrying out data structure disassembly on the code view to obtain subcode data, storing the subcode data and the functional data into a memory layer according to a preset data structure to obtain data after being transferred, and finally converting the data after being transferred into hard disk data according to a preset format and storing the hard disk data into a storage layer. According to the technical scheme, after the data of the engine layer are disassembled, the disassembled data are stored according to the self-defined data structure, so that the blueprint code is extracted, and a plaintext data base is provided for other development processes.
On the basis of the above method embodiment, fig. 9 is a schematic diagram of a visually programmed code processing apparatus according to an embodiment of the present application. As shown in fig. 9, the processing apparatus includes: an acquisition module 91, a processing module 92, and a storage module 93.
An obtaining module 91, configured to obtain, from an engine layer, execution stream data of a view, where the execution stream data includes: the method comprises the steps of drawing functional data corresponding to a code view;
the processing module 92 is configured to disassemble the data structure of the code view to obtain subcode data, where the subcode data includes: information of at least one node, identification of a view, and identification of other views to which the view is associated;
the storage module 93 is configured to store the subcode data and the functional data to the memory layer according to a preset data structure, obtain the data after being transferred, and convert the data after being transferred to hard disk data according to a preset format, and store the hard disk data to the storage layer.
In one possible design of the embodiment of the present application, the information of each node includes: at least one pin information, an identification of a node, and an identification of other nodes associated with the node, each pin information comprising: the identification of at least one pin and the identification of other pins associated with the at least one pin.
In another possible design of the embodiment of the present application, the preset data structure includes: executing a stream data table, the executing the stream data table comprising: a data area of the view and a functional data area associated with the view, the data area of the view comprising: at least one junction region, the junction region comprising: at least one pin area, the functional data area associated with the view including pin information for the at least one pin.
In still another possible design of the embodiment of the present application, the obtaining module 91 is specifically configured to obtain execution flow data of a view from resource data corresponding to the view of an engine layer.
In this possible design, the acquisition module 91 is specifically configured to:
acquiring first resource data corresponding to a new version view and second resource data corresponding to an old version view stored in a tree structure from an engine layer, wherein the code view comprises the first resource data and the second resource data;
different parts of the first resource data and the second resource data are acquired as functional data.
In still another possible design of the embodiment of the present application, the storage module 93 stores the subcode data and the functional data to the memory layer according to a preset data structure, so as to obtain the data after the transfer, which is specifically used for:
Establishing a data object with a structure of a preset data structure in a memory layer;
performing assignment reloading processing on the sub-code data and the functional data to obtain extracted execution stream data;
and copying the extracted execution stream data into a data object according to the data structure to obtain the data after the transfer.
In yet another possible design of the embodiment of the present application, the preset format includes: the storage module 93 converts the transferred data into hard disk data according to a preset format, and stores the hard disk data in the storage layer, which is specifically used for:
converting the transferred data into JSON format hard disk data by adopting a serialization method;
and storing the JSON-format hard disk data into a storage layer.
The code processing device for visual programming provided in the embodiment of the present application may be used to execute the technical scheme corresponding to the code processing method for visual programming in the embodiment of fig. 2, and its implementation principle and technical effects are similar, and are not described herein again.
It should be noted that, it should be understood that the division of the modules of the above apparatus is merely a division of a logic function, and may be fully or partially integrated into a physical entity or may be physically separated. And these modules may all be implemented in software in the form of calls by the processing element; or can be realized in hardware; the method can also be realized in a form of calling software by a processing element, and the method can be realized in a form of hardware by a part of modules. In addition, all or part of the modules can be integrated together or can be independently implemented. The processing element described herein may be an integrated circuit having signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in a software form.
Fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer device may include: a processor 101, a memory 102, and computer program instructions stored on the memory 102 and executable on the processor 101.
Processor 101 executes computer-executable instructions stored by memory 102, causing processor 101 to perform the aspects of the embodiments described above. The processor 101 may be a general-purpose processor including a central processing unit CPU, a network processor (network processor, NP), etc.; but may also be a digital signal processor DSP, an application specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.
The memory 102 is connected to the processor 101 via a system bus and communicates with each other, the memory 102 being adapted to store computer program instructions.
The system bus may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The system bus may be classified into an address bus, a data bus, a control bus, and the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus.
The computer device provided in the embodiment of the present application may be used to execute the technical scheme corresponding to the code processing method of visual programming in the foregoing embodiment, and its implementation principle and technical effect are similar, and are not described herein again.
The embodiment of the application also provides a chip for running the instruction, which is used for executing the technical scheme of the code processing method of the visual programming in the embodiment.
The embodiment of the application also provides a computer readable storage medium, in which computer instructions are stored, which when executed on a computer device, cause the computer device to execute the technical scheme of the visually programmed code processing method in the embodiment.
The embodiment of the application also provides a computer program product, which comprises a computer program, wherein the computer program is used for executing the technical scheme of the code processing method of the visual programming in the embodiment when being executed by a processor.
The computer readable storage medium described above may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. A readable storage medium can be any available media that can be accessed by a general purpose or special purpose computer device.
It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.
Claims (10)
1. A method of visually programmed code processing, the method comprising:
obtaining execution stream data of a view from an engine layer, the execution stream data comprising: a code view and functional data corresponding to the code view are drawn;
performing data structure disassembly on the code view to obtain subcode data, wherein the subcode data comprises: information of at least one node, an identification of the view, and an identification of other views associated with the view;
storing the sub-code data and the functional data to a memory layer according to a preset data structure to obtain the data after the transfer;
converting the data after the transfer into hard disk data according to a preset format and storing the hard disk data into a storage layer;
the code view comprises first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored in a tree structure and are obtained from the engine layer, and the function data are different parts of the first resource data and the second resource data.
2. The method of claim 1, wherein the information for each node comprises: at least one pin information, an identification of the node, and an identification of other nodes associated with the node, each pin information comprising: the identification of at least one pin and the identification of other pins associated with the at least one pin.
3. The method according to claim 1 or 2, wherein the preset data structure comprises: an execution flow data table, the execution flow data table comprising: a data area of the view and a functional data area associated with the view, the data area of the view comprising: at least one junction region, the junction region comprising: at least one pin area, the functional data area associated with the view including pin information for at least one pin.
4. The method according to claim 1 or 2, wherein the obtaining the execution flow data of the view from the engine layer comprises:
and acquiring execution flow data of the view from resource data corresponding to the view of the engine layer.
5. The method according to claim 1 or 2, wherein storing the sub-code data and the functional data to a memory layer according to a preset data structure to obtain the data after the transfer comprises:
Establishing a data object with a structure of the preset data structure in the memory layer;
performing assignment reload processing on the sub-code data and the functional data to obtain extracted execution stream data;
copying the extracted execution stream data into the data object according to the data structure to obtain the data after the transfer.
6. The method according to claim 1 or 2, wherein the preset format comprises: and converting the transferred data into hard disk data according to a preset format by the JSON format, and storing the hard disk data into a storage layer, wherein the JSON format comprises the following steps:
converting the transferred data into the hard disk data in a JSON format by adopting a serialization method;
and storing the hard disk data in the JSON format to the storage layer.
7. A visually programmed code processing apparatus for application to a computer device, the apparatus comprising: the device comprises an acquisition module, a processing module and a storage module;
the obtaining module is configured to obtain, from an engine layer, execution flow data of a view, where the execution flow data includes: a code view and functional data corresponding to the code view are drawn;
the processing module is configured to disassemble the data structure of the code view to obtain sub-code data, where the sub-code data includes: information of at least one node, the identification of the view and the identification of other views related to the view, and carrying out assignment reload processing on the sub-code data and the functional data to obtain extracted execution stream data;
The storage module is used for storing the extracted execution flow data to a memory layer according to a preset data structure, converting the extracted execution flow data into hard disk data according to a preset format and storing the hard disk data to the storage layer of the computer equipment;
the code view comprises first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored in a tree structure and are obtained from the engine layer, and the function data are different parts of the first resource data and the second resource data.
8. A visually programmed code processing system, comprising: the system comprises a user layer, an engine layer, a memory layer and a storage layer;
the user layer is used for displaying views;
the engine layer is configured to provide execution flow data in resource data corresponding to the view, where the execution flow data includes: the method comprises the steps of code view and drawing functional data corresponding to the code view, wherein the data structure of the code view is disassembled to obtain subcode data;
the memory layer is used for storing the sub-code data and the functional data according to a preset data structure, and the obtained data after the transfer is obtained;
The storage layer is used for storing hard disk data after converting the data after being transferred according to a preset format;
the code view comprises first resource data corresponding to a new version view and second resource data corresponding to an old version view which are stored in a tree structure and are obtained from the engine layer, and the function data are different parts of the first resource data and the second resource data.
9. A computer device, comprising: processor, memory and computer program instructions stored on the memory and executable on the processor, characterized in that the processor implements a visually programmed code processing method according to any of the preceding claims 1 to 6 when executing the computer program instructions.
10. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein computer executable instructions which when executed by a processor are adapted to implement a visually programmed code processing method according to any of the preceding claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110890840.XA CN113608727B (en) | 2021-08-04 | 2021-08-04 | Code processing method, device and system for visual programming |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110890840.XA CN113608727B (en) | 2021-08-04 | 2021-08-04 | Code processing method, device and system for visual programming |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113608727A CN113608727A (en) | 2021-11-05 |
| CN113608727B true CN113608727B (en) | 2023-07-25 |
Family
ID=78306788
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110890840.XA Active CN113608727B (en) | 2021-08-04 | 2021-08-04 | Code processing method, device and system for visual programming |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113608727B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115934086A (en) * | 2022-12-28 | 2023-04-07 | 苏州峰之鼎信息科技有限公司 | Information sharing method, device, equipment and medium for blueprint and page design |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015192555A1 (en) * | 2014-06-20 | 2015-12-23 | 中兴通讯股份有限公司 | Data transmission method, base station, and storage medium |
| CN105204980A (en) * | 2014-05-26 | 2015-12-30 | 腾讯科技（深圳）有限公司 | Method for testing virtual engine software and testing equipment |
| WO2018034585A1 (en) * | 2016-08-17 | 2018-02-22 | Huawei Technologies Co., Ltd | Techniques for data transmission based on irregular connection graphs |
| DE102017101848A1 (en) * | 2017-01-31 | 2018-08-02 | Gritworld GmbH | Data visualization system for industrial design |
| CN109966742A (en) * | 2019-03-21 | 2019-07-05 | 深圳市腾讯信息技术有限公司 | The method and device of rendering performance data is obtained in game running |
| CN110705219A (en) * | 2019-10-21 | 2020-01-17 | 网易（杭州）网络有限公司 | Game data processing method and device, storage medium and electronic equipment |
| CN111596903A (en) * | 2020-03-27 | 2020-08-28 | 完美世界(北京)软件科技发展有限公司 | Data processing method and device in rendering engine |
| CN111949607A (en) * | 2020-09-03 | 2020-11-17 | 网易（杭州）网络有限公司 | Method, system and device for monitoring UDT file |
| CN112883102A (en) * | 2021-03-05 | 2021-06-01 | 北京知优科技有限公司 | Data visualization display method and device, electronic equipment and storage medium |
| CN113018870A (en) * | 2021-04-17 | 2021-06-25 | 腾讯科技（深圳）有限公司 | Data processing method and device and computer readable storage medium |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10195965T1 (en) * | 2000-03-24 | 2003-04-03 | Siemens Energy & Automat | Storage and transfer of a graphical programming language for an industrial automation system |
| US8543939B2 (en) * | 2011-06-07 | 2013-09-24 | The Mathworks, Inc. | Graphical data conversion/translation |
| US10803674B2 (en) * | 2017-11-03 | 2020-10-13 | Samsung Electronics Co., Ltd. | System and method for changing a virtual reality environment dynamically |
-
2021
- 2021-08-04 CN CN202110890840.XA patent/CN113608727B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105204980A (en) * | 2014-05-26 | 2015-12-30 | 腾讯科技（深圳）有限公司 | Method for testing virtual engine software and testing equipment |
| WO2015192555A1 (en) * | 2014-06-20 | 2015-12-23 | 中兴通讯股份有限公司 | Data transmission method, base station, and storage medium |
| WO2018034585A1 (en) * | 2016-08-17 | 2018-02-22 | Huawei Technologies Co., Ltd | Techniques for data transmission based on irregular connection graphs |
| DE102017101848A1 (en) * | 2017-01-31 | 2018-08-02 | Gritworld GmbH | Data visualization system for industrial design |
| CN109966742A (en) * | 2019-03-21 | 2019-07-05 | 深圳市腾讯信息技术有限公司 | The method and device of rendering performance data is obtained in game running |
| CN110705219A (en) * | 2019-10-21 | 2020-01-17 | 网易（杭州）网络有限公司 | Game data processing method and device, storage medium and electronic equipment |
| CN111596903A (en) * | 2020-03-27 | 2020-08-28 | 完美世界(北京)软件科技发展有限公司 | Data processing method and device in rendering engine |
| CN111949607A (en) * | 2020-09-03 | 2020-11-17 | 网易（杭州）网络有限公司 | Method, system and device for monitoring UDT file |
| CN112883102A (en) * | 2021-03-05 | 2021-06-01 | 北京知优科技有限公司 | Data visualization display method and device, electronic equipment and storage medium |
| CN113018870A (en) * | 2021-04-17 | 2021-06-25 | 腾讯科技（深圳）有限公司 | Data processing method and device and computer readable storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 【UE4】 结构体数据转为Json的保存和读取(当存档使用);SebQuit;《https://blog.csdn.net/weixin_44052668/article/details/106784149》;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113608727A (en) | 2021-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8434062B2 (en) | Enhancing source code debugging and readability using visual symbols | |
| US11429365B2 (en) | Systems and methods for automated retrofitting of customized code objects | |
| US11966312B2 (en) | Operation logs visualization device, operation logs visualization method and operation logs visualization program | |
| JPH10307716A (en) | Visual programming device by screen flow | |
| CN105743736B (en) | Automated testing method and system | |
| US11385772B2 (en) | Attribute-based rules for displaying additional information | |
| CN113608727B (en) | Code processing method, device and system for visual programming | |
| US20140208243A1 (en) | Method for providing a user interface, computer system and computer program product | |
| US8701086B2 (en) | Simplifying analysis of software code used in software systems | |
| CN114020256A (en) | Front-end page generation method, device and equipment and readable storage medium | |
| JPH10254689A (en) | Application constitution design supporting system for client/server system | |
| US10884711B2 (en) | Code management system and code management method using a visual programming tool | |
| Baxter et al. | SPIRE: the SPIDER reconstruction engine | |
| Aljawabrah et al. | Automated recovery and visualization of test-to-code traceability (TCT) links: An evaluation | |
| JP2008198103A (en) | State transition diagram preparing device and state transition diagram preparing method | |
| Eyl et al. | Traceability in a fine grained software configuration management system | |
| EP3867746A1 (en) | User interface resource file optimization | |
| CN108628606B (en) | Method and system for generating WEB network management application program of embedded equipment | |
| CN111679983A (en) | JAVA interface static test method and device | |
| Wilkes | Advanced Python Development | |
| Freeman | Understanding Angular Projects and Tools | |
| CN115495442B (en) | Database operation file generation method, device, equipment and storage medium | |
| EP4261678A1 (en) | Generation of a technical instruction | |
| CN118349720A (en) | Method and system for automatically generating class description document based on Qt element object system | |
| Hinz | OpenOffice. org Calc automation using ooRexx |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |