CN111930374B

CN111930374B - Formatting method for graphic code component combination and related equipment

Info

Publication number: CN111930374B
Application number: CN202010997873.XA
Authority: CN
Inventors: 陈刚; 林锋; 王苗苗
Original assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Current assignee: Beijing Yizhen Xuesi Education Technology Co Ltd
Priority date: 2020-09-21
Filing date: 2020-09-21
Publication date: 2024-01-26
Anticipated expiration: 2040-09-21
Also published as: CN111930374A

Abstract

The formatting method of the graphic code component combination and the related equipment comprise the following steps: obtaining a graphic code component combination; each graphic code component included in a graphic code component combination is represented as formatted data over a plurality of data dimensions to form formatted data for the graphic code component combination. According to the method, the formatting data are generated by considering the formatting mode of the context of the graphic code component, so that the situations of the isomerization of the linked list data format and the building block format of original codes in the existing graphic programming education software are changed, and the difficulty of code analysis is reduced; in addition, a more flexible work inspection mechanism may be implemented by formatting the data.

Description

Formatting method for graphic code component combination and related equipment

Technical Field

The embodiment of the application relates to the technical field of programming teaching, in particular to a formatting method of a graphic code component combination and related equipment.

Background

Based on the current demands for logic thinking training in education, electronic teaching tools of various logic thinking classes continue to emerge. Especially in the case of the high degree of dependence of today's society on computer network technology, the age of the users facing programming lessons is also getting smaller and smaller.

For this reason, some graphic programming teaching software which is more visual and interesting has appeared, such as simple graphic programming tools (Scratch) of the millboard college, and provides a programming mode of building blocks, i.e. a user can combine the graphic code building blocks through operations such as clicking and dragging, so as to complete programming works.

The Scratch has evolved to version 3.0. However, the user interface of Scratch 3.0 has a clear functional section, and the user code is clear due to the modular programming method. However, the whole source code of the Scratch 3.0 data layer is stored in a JSON data format, in the JSON file, each building block in the character script area is distributed with a random unique building block identifier (key), the building blocks are connected by using a linked list mode, and when nesting is generated, codes are more complex, so that the source code of the work is difficult to read and cannot be directly developed for the second time. In addition, when the Scratch works run, each building block is independently analyzed, and the data formats of different building blocks have large differences.

In summary, under the dual influence of the linked list data format adopted by the Scratch and the building block format isomerism, it is very difficult to directly analyze the plaintext of the work source code of the Scratch.

Disclosure of Invention

In view of this, the embodiments of the present application provide a method and related apparatus for formatting a graphic code component assembly, which solve the technical problems in the prior art.

The embodiment of the application provides a formatting method of a graphic code component combination, wherein the graphic code component combination consists of graphic code components; the method comprises the following steps:

obtaining a graphic code component combination;

each graphic code component included in a graphic code component combination is represented as formatted data over a plurality of data dimensions to form formatted data for the graphic code component combination.

Optionally, the plurality of data dimensions includes: executing roles, events, sequential logic, and types; in the case of a graphic code component having parameters, the plurality of data dimensions further includes parameters.

Optionally, the formatting manner includes:

acquiring execution role information of each graphic code component in the graphic code component combination; wherein, each graphic code component forms each execution role group according to each execution role group;

acquiring the related event information of each graphic code component under the execution role group; wherein, each graphic code component under each execution role group forms each event group according to each related event information group;

Extracting the type of each graphic code component under the event group, the depth information representing the nesting relation of the graphic code components and the parameters of the graphic code components with the parameters according to the arrangement sequence;

and forming the formatted data of each graphic code component according to the extracted information of each graphic code component, and forming the formatted data of the corresponding graphic code component combination according to the arrangement sequence.

Optionally, the extracting, according to the order, the type of each graphic code component under the event group, the depth information representing the nesting relationship, and the parameters of the graphic code component with the parameters, includes:

accessing each graphic code component one by one;

adding the graph code component which is judged to be subjected to recursive processing into a first recursive queue;

extracting information from each graphic code component outside the first recursion queue and placing the information into corresponding formatted data;

information is extracted from each graphic code component in the first recursion queue and placed into corresponding formatted data.

Optionally, the extracting information from each graphic code component outside the first recursion queue includes:

screening the effective parameters of each graphic code component one by one;

and placing the graph code component judged to need recursive processing into a second recursive queue.

Optionally, the second recursion queue recursion processes have a higher priority than the first recursion queue.

Optionally, the graphic code component requiring recursive processing includes at least one of the following: graphic code components that have nested relationships; there are graphical code components of selectable parameters.

The embodiment of the application also provides a formatting device of the graphic code component combination, wherein the graphic code component combination consists of graphic code components; the device comprises:

the acquisition module is used for acquiring the graphic code component combination;

and the formatting unit is used for representing each graphic code component contained in the graphic code component combination as formatted data in a plurality of data dimensions so as to form the formatted data of the graphic code component combination.

The embodiment of the application also provides a graphic programming system, which comprises:

a graphic programming unit for providing a graphic programming interface for a user, for receiving user operations to combine the operated graphic code components into a graphic programming work;

and the formatting unit is realized by the formatting device of the graphic code component combination and is used for formatting the graphic programming work or the related graphic code component combination thereof to obtain corresponding formatted data.

The embodiment of the application also provides a computer device, which comprises a memory and a processor, wherein the memory stores a computer program capable of running on the processor, and the processor executes the steps of the formatting method of any graphic code component combination when running the computer program.

Embodiments of the present application also provide a computer readable storage medium having stored thereon a computer program which, when run, performs the steps of the formatting method of any of the graphical code component combinations described.

Compared with the prior art, the technical scheme of the embodiment of the application has the following beneficial effects:

in the embodiment of the application, the formatting data is generated by considering the formatting mode of the context of the graphic code component, so that the situations of the isomerism of the linked list data format and the building block format of the original codes in the conventional graphic programming education software are changed, and the difficulty of code analysis is reduced; in addition, a more flexible work inspection mechanism may be implemented by formatting the data.

Drawings

Fig. 1 is a graphical user interface schematic of Scratch.

Fig. 2 is a schematic view of a block combination in Scratch.

FIG. 3 is a flow chart of a method of formatting a graphical code component assembly in an embodiment of the present application.

FIG. 4 is a flow diagram of a formatting method for executing a graphical code component assembly in a specific data dimension in an embodiment of the present application.

Fig. 5 is a schematic diagram of formatted data according to an embodiment of the present application.

FIG. 6 is a flow diagram of a formatting method for executing a combination of graphical code components using a recursive queue in an embodiment of the present application.

Fig. 7 is a flow chart of formatting of the actual code corresponding to fig. 6 in an embodiment of the present application.

Fig. 8 is a flowchart of a specific implementation of S708 in fig. 7.

FIG. 9 is a schematic diagram of a formatting device for graphical code component assembly in an embodiment of the present application.

FIG. 10 is a schematic diagram of a formatting module in a formatting device for graphical code component assembly in an embodiment of the present application.

FIG. 11 is a schematic diagram of a graphical programming system in an embodiment of the present application.

Fig. 12 is a schematic structural diagram of a computer device in the embodiment of the present application.

Detailed Description

Graphic programming teaching software has been applied to the programming teaching of children and teenagers. For example, a simple graphical programming tool, scratch, from the university institute of technology, the user may operate various "programming blocks" in the graphical user interface of Scratch and combine to form a graphical programming.

As shown in fig. 1, a graphical user interface schematic of Scratch is shown.

In the graphical user interface schematic of the Scratch shown in fig. 1, the left column 101 shows code blocks that can be selected for use, for example, various types of code blocks such as "sports", "appearance", "sound", "event", "control", etc., and various appearance-related code blocks shown by selecting the "appearance" option are shown in the figure; the programming area 102 in the middle of the drawing shows a graphic programming work constituted by combining selected code blocks, exemplarily showing that "when a flag (graphically shown in the drawing) is clicked," the execution character "moves 100 steps" to "bounces upon hitting an edge," the rotation manner of the execution character is set to "flip left and right" (the inverted triangle in the drawing represents a pull-down list in which an action can be selected by operating), the execution character "turns right 15 degrees" says "hello-! "play sound" mew "and show the next build; the right column in the figure shows a lower right execution character area 103 and an upper animation display area (generally referred to as "stage area") 104, in which animation results corresponding to the execution of the code of the graphic programming can be displayed, and the execution character may be "majordomo" of a cartoon cat, which corresponds to the sound of "majordomo" described above. Of course, the execution roles may be multiple, for example, the execution role area 104 on the right side may be displayed separately, for example, the execution roles have a cat and a dog, the user may select the corresponding execution roles, and the programming area 102 in the middle may program the code building blocks corresponding to the selected execution roles, where the pattern of the role "cat" is different from the pattern of the role "dog" in the figure, indicating that it is selected.

In Scratch, there are various types of bricks, the forms of which are different. Most of the writing programs start with event blocks, for example, the code blocks of the uppermost block shown in fig. 1, i.e., the code blocks of the "when flag is clicked", are event blocks.

In some examples, the "graphic code component" referred to herein may be code blocks in the Scratch, the graphic code component combination may be a combination of blocks resulting from splicing blocks in the Scratch, and the graphic programming may be a work formed from one or more combinations of blocks, such as that illustrated in fig. 1. It should be noted that the graphic programming of one building block set shown in fig. 1 is merely an example, and the graphic programming is not limited to the number of building blocks, for example, there are one or more executing roles (e.g. cat, dog, etc.), and each executing role may execute one or more events, so that one or more building blocks related to the events are correspondingly formed, and each building block set starts with one event building block.

In fig. 2, a building block combination is shown, functioning as follows: when the flag is clicked, the character walks forward 10 steps, and if the character enters the area after the step 10, the character can say "hello".

In the Scratch 3.0, the whole source code is stored in JSON data format, and JSON (JavaScript Object Notation) is a lightweight data exchange format.

Illustratively, the JSON code corresponding to the building block combination of fig. 2 is shown in code segment 1 as follows:

{

"building block 1": {

"opcode" ("event_wshenflag click",// event)

"next" means "building block 2",// next "building block 2"

"parent": null,// no parent building blocks exist

"inputs":{

},

"fields":{

}

},

"building block 2": {

"opcode" ("motion_motion",// move action)

"next" means "building block 3",// next "building block 3"

"parent" means "building block 1",// father building block is "building block 1"

"inputs":{

"STEPS": 1, [4, [ 10 ]// number of STEPS of movement is "10"

},

"fields":{

}

},

"building block 3": {

"opcode": "control_if",// if

"next":null,

"parent" means "building block 2",

"inputs":{

"CONDITION": 2, "building block 4" ]// CONDITION: if building block 4"

"SUBSTACK": 2, "building block 5" ]// branch: then "building block 5"

},

"fields":{

}

},

"building block 4": {

"opcode": "sending_touch color",// touch color

"next":null,

"parent" means "building block 3",

"inputs":{

"COLOR" [1, [ 9, "#a3cc33" ] ]// COLOR is "#a3cc 33".

},

"fields":{

}

},

"building block 5": {

"opcode": "cookies_save",// appearance: "say"

"next":null,

"parent" means "building block 3",

"inputs":{

"MESSAGE": 1, [ 10, "hello ]! "]// say: "hello"

},

"fields":{

}

Wherein, each code building block is allocated with a random unique building block identification (called key), for clarity of viewing, the building block identification is expressed in the codes simply through ' building block 1 ' -building block 5 ', etc., if in actual implementation, the building block identification can be a random character string composed of a series of letters, numbers and symbols; it can be seen that in the data structure body corresponding to each current code building block, the next building block adjacent to the current building block is marked by the key in the next field, and meanwhile, the previous building block of the current building block is marked by the key in the parent field, so that the sequence of the building blocks is determined; if the value of the forward building block "parent" is "null", it indicates that the building block is the first building block of the combination, which may be, for example, an event building block.

It can be seen that the "opcode" field is the name of the block (i.e., the "type" of block), and the parent records the block identification of the last block. The parameters of the blocks are distributed in the "inputs" and "fields, for example the" COLOR hit "block has the parameter name COLOR and the" move "block has the parameter name step.

In addition to the sequential relationship to each other, the above building block combinations also exist in more complex "nested" relationships, such as "if …" there are two nested relationships in the building block: "touch color" is a conditional building block "if …," say "is a building block to be executed when a condition is satisfied. In the original JSON file, the blocks with the "opcode" being "connector_if" represent the "if …" blocks of the user interface, two random block identifications appear in the array corresponding to the "CONDITION" and "SUBSTACK" in the "inputs" field of the blocks, and the blocks with the "opcode" being "sending_touch color" and "look_sky" are found in the code through the two block identifications, and the two blocks are the "touch color" and the "say" blocks on the user interface, representing that the two blocks are nested in the "if …".

As can be seen from comparing the description of the parameters in the two sections, in the original JSON of the building block, the nesting relationship is very similar to the parameters in code format, is easy to confuse, and is not beneficial to the plaintext analysis of the codes.

In embodiments of the present application, a scheme may be provided for formatting a combination of graphic code components (e.g., a building block combination).

As shown in fig. 3, a flow diagram of a method for formatting a graphic code component assembly in an embodiment of the present application is shown. The formatting method of the graphic code component combination is used for formatting the graphic code component combination formed by the graphic code components; the formatting method of the graphic code component combination comprises the following steps:

step S301: a combination of graphical code components is obtained.

Step S302: each graphic code component included in a graphic code component combination is represented as formatted data over a plurality of data dimensions to form formatted data for the graphic code component combination.

In some examples, the formatting refers to representing each building block contained by a combination of building blocks as formatted data over multiple data dimensions. In a specific implementation example, the plurality of data dimensions includes: executing roles, events, sequential logic and types; wherein, in the case of a building block having parameters, the plurality of data dimensions further includes parameters.

Wherein, the executing roles are cat 'can' in figure 1 or other executing roles in the executing role library, and the building blocks in the embodiment of figure 1 can be taken as executing roles from 'can' in figure 1.

For another example, in the embodiment of fig. 1, it can be seen that the first block is an event block, and the code blocks after the first block are all attributed to the event block, so that the event to which the subsequent code block belongs can be determined through the event block, and the information of the event to which the code block belongs can be determined uniquely to determine the block combination related to the event to which the code block belongs.

As another example, the name "opcode" of a code building block represents its name (i.e., type), e.g., "motion_motion" indicates motion.

The sequential logic includes the sequence and nesting relationship of code building blocks.

With respect to the sequence relationship, it refers to the sequence of code blocks in the block combination, for example, the sequence of blocks from top to bottom in fig. 2, which also corresponds to the code sequence of the block combination, for example, as shown in the code segment 1.

Regarding nesting relationships, for example, "if..then" code blocks in FIG. 2, code blocks of "touch color" and "say" are nested.

Alternatively, the nesting position of each building block can be represented by the depth information of each building block, and the value of the depth information of each building block can be represented by adding 1 from the outer layer to the inner layer of the nesting. For example, assume that each code building block without nested relation is represented by a value of "1" of the depth information, such as "1" of the depth information of "when the flag is clicked", "moved" in fig. 2; the values of the depth information of the nested building blocks with the color and the say can be set to be 2 which is deeper than 1, and if the color is replaced by other nested building blocks, the value of the depth information of the building blocks nested by the nested building blocks can be 3 which is deeper than 1.

As another example, as shown in FIG. 2, where some of the bricks have no parameters, such as "when a flag is clicked" is not a no parameter brick, and "move" bricks are parametric bricks, which can be included in the formatted data for the corresponding bricks.

In the Scratch, the user performs the assembly of code blocks in the execution role area opened corresponding to the execution role, so that the corresponding code blocks are all under the execution role, the blocks of the block combination are generally event blocks, which represent an event under the execution role, and then down to other blocks which belong to, and the pattern code blocks may have a nested relationship, wherein some of the pattern code blocks are parameter blocks and some of the pattern code blocks are non-parameter blocks.

In some examples, corresponding to such a context, a method corresponding to the formatted flow diagram shown in fig. 4 may be performed, which specifically includes:

step S401: acquiring execution role information of each graphic code component; wherein, each graphic code component forms each execution role group according to each execution role group.

For example, if a graphical programming comprises a first combination of graphical code components that perform as a "can" cat, then each graphical code component in this first combination of graphical code components would fall into the "can" cat group of performing roles; similarly, if the graphic programming also includes a second graphic code component combination taking the puppy as an execution role, each graphic code component is classified as the execution role group of the puppy.

Step S402: acquiring the related event information of each graphic code component under the execution role group; wherein, each graphic code component under each executing role group forms each event group according to each related event information group.

For example, the execution role of the graphic code component combination in fig. 2 is "can be multiple" by a cat, and the graphic code component combination belongs to the "can be multiple" execution role group of the cat, further, the first graphic code component of the graphic code component combination is of an event type, and when the flag is clicked, an event group is formed by taking the flag as an event, and the subsequent graphic code components belong to the event group.

Step S403: the type of each graphic code component under the event group, the depth information representing its nesting relationship, and the parameters of the graphic code component with the parameters are extracted in the order of arrangement.

The arrangement sequence is the sequence of each graphic code component in the graphic code component combination.

As in the previous embodiments, the type is represented by a name extracted from "opcode"; the nesting relationship is represented by depth information, for example, the value of the depth information of "when a flag is clicked", "moved", "if..then" may be set to "1", and the value of the depth information of "nested building block nested" encountering color "and" say "may be" 2 "if..then; the parameters include, for example, a parameter "10" in "movement" in fig. 2, a color code "#a3cc33" in "touch color", and the like.

Step S404: and forming the formatted data of each graphic code component according to the extracted information of each graphic code component, and forming the formatted data of the corresponding graphic code component combination according to the arrangement sequence.

The graphic code component combination of fig. 2 corresponds to the previous code segment 1, and after formatting, the formatted data of each graphic code component in the graphic code component combination is represented as [ name, [ parameter list ], depth information ], and the formatted data of the graphic code component combination is integrated with the formatted data, and may be represented as a plurality of groups. For example, code segment 1 may be formatted in the form of code segment 2:

{

"event_whenflagclicked":

[

["event_whenflagclicked", 1],

["motion_movesteps",["10"], 1],

["control_if", 1],

["sensing_touchingcolor", ["#a3cc33"], 2],

[ "logs_save", [ "hello |" ], 2]

]

}

The meaning of the formatted data of the individual blocks in the above-mentioned code segment 2 is specified.

For example, "event_flag clicked" indicates that the event block of the group of block combinations is "when a flag is clicked". Each element in the array shown below "event_Whenflag click" is the formatted data of one building block.

The format data of the building blocks are in the form of [ names, [ parameter list ] and depth information ], the names correspond to the opcodes of the building blocks, the parameter list contains various parameters of the building blocks, and the depth information is used for representing nesting relations of the building blocks.

In the example of code segment 2, the arrangement of the formatted data of each graphic code component (i.e., building blocks) is consistent with the arrangement of the corresponding graphic code components in FIG. 2, i.e., the information of the arrangement of the graphic code components in the graphic code component combination is restored in the corresponding formatted data.

It will be appreciated that in this arrangement, changes in the nested relationship, such as the occurrence or exit of a nested relationship, may be correspondingly derived from changes in the depth information. For example, the depth information of the outermost layer of the graphic code components is "1", the depth is increased by "1" after the nesting relationship occurs according to the arrangement order of the graphic code components in the graphic code component combination, the nesting depth is increased by "1" every further layer, and the depth is reduced by "1" every time one layer of nesting is released; if the depth information is restored to be 1, the nesting relation of the outermost layer is withdrawn; for example, from "if..then" to "hit color" and "say," the depth information changes from "1" to "2," indicating that nesting of "if..then" is exited if depth information for a subsequent graphical code component in the graphical code component combination appears to be "1. Similarly, if the depth information of the graphic code components in the combination is increased later, a new nesting relationship is shown.

More specifically, the first element in the array is the formatted data of the formatted event block, which in this example is "when the flag is clicked", without parameters, with a depth of 1.

The second element in the array corresponds to the formatted data of the "move" block, which has a parameter of 10, and is in a spliced relationship with the event block, so the depth information is also 1.

The third element in the array is the formatting data of the "if …" building block that contains nested building blocks without its own parameters, and the compactness of the "if …" building block format is maintained because the nested relationship is expressed only by the adjacency + depth information. The depth information of the third element being 1 indicates that the second building block is still in a spliced relationship.

The fourth element in the array is the formatting data of the "touch color" building block, which contains a parameter "a3cc33", which is the color in RGB format. The block depth information is 2 and the next last block depth information is 1, indicating that the "hit color" block is the nested inner block of the "if …" block.

The fifth element in the array is the formatting data for the "say" building block, containing a parameter "hello-! ", depth of 2 indicates that both the" say "block and the" hit color "block are nested internal blocks of the" if … "block. If there are other bricks later, if the depth becomes 3, this indicates that a further nesting has been entered, if the depth becomes 1, this indicates that the nesting of the bricks "if … is ended, and returns to the same depth of the bricks" if … ".

For a more visual illustration of the principles of the method of fig. 4, reference may be made to fig. 5, wherein the right side shows the executive role group "kitten" (e.g., "kitten" s ")," puppy "," kitten "executive role group next to the event group" when a flag is clicked ", the event group next to the flag when clicked next to the formatted data of the various graphical code components, such as" when a flag is clicked "," moved "," if..then "," hit color ", and" say ".

Shown on the left side of FIG. 5 is a more detailed data structure diagram of the formatted data of the graphical code components "when a flag is clicked" and "moved". The graphic code component "when the flag is clicked" is parameter-free, which contains the operation code "event_while flag click" (i.e., "event_when the flag is clicked") and depth information "1"; while "move" is parametric, including the operation code "motion_motion steps" (i.e., "action_move_steps"), parameters (move steps "10"), and depth information "1".

As shown in fig. 6, the actual processing flow of step S403 in a possible implementation is shown, including:

step S601: accessing each graphic code component one by one;

Step S602: adding the graph code component which is judged to be subjected to recursive processing into a first recursive queue;

step S603: extracting information from each graphic code component outside the first recursion queue and placing the information into corresponding formatted data;

step S604: information is extracted from each graphic code component in the first recursion queue and placed into corresponding formatted data.

In some examples, the graphical code components requiring recursive processing may include at least one of: graphic code components that have nested relationships; there are graphical code components of selectable parameters.

For example, bricks having a nested relationship such as the "if..then" bricks in fig. 2; there are graphical code components of selectable parameters, such as drop down list blocks, such as the "set rotation to" block in fig. 1.

In the following, in connection with the previous embodiment, the JSON code of the existing Scratch, namely code segment 1, and the code segment 2 of the formatted data after conversion, a flow chart of an actual implementation of the above-mentioned processing procedure is shown in the embodiment of fig. 7.

In the Scratch, the first building block of the effective building block combination must be an event building block, so that an event building block event in a linked list is found as a starting building block, and each current building block is sequentially formatted; after each current building block is processed, reading the next building block pointed by next in the current building block, and continuing formatting; upon encountering a building block requiring recursive processing, a recursive task is generated for insertion into a "recursive queue", e.g., a first recursive queue, i.e., recursive queue 1, and a second recursive queue, i.e., recursive queue 2, in the following procedure, and processing before processing the next building block pointed to by next; if the task exists in the recursion queue, the task in the recursion queue is processed preferentially, a new flow is started in the processing recursion, and the depth information in the whole processing process is +1.

Taking the formatting of code of Scratch as an example, in fig. 7, a flow of formatting an actual code is shown, which specifically includes:

step S701: a start step.

Step S702: inputs are formatted for the first time.

For example, it is determined whether the current building block includes a building block identifier (key) to be assigned to the recursion queue, and if so, the current building block is added to the recursion queue 1; for blocks with a drop down list included in the Scratch, the blocks of the drop down list may be spliced from a plurality of blocks, which may be spliced into a block process in step S702. For example, the "play sound" block in fig. 1 and the "cat" therein are selected by the drop-down list, and it seems that the "cat" is a parameter of the "play sound" block, but in reality the "cat" may be a parameter in another block other than the "play sound" block, so that the two blocks may be spliced together in step S702.

Step S703: field formatting.

For example, both fields of inputs and fields in the Scratch may carry data, for example, when two blocks with a drop-down list are spliced into one block in S702, parameters selected by the drop-down list may be stored in fields spliced into one block; for unified processing, fields may be incorporated into inputs, i.e., parameters are incorporated into inputs in S703.

Step S704: inputs are formatted a second time.

After the fields are merged, the inputs are formatted a second time, and this process is mainly for special handling of the parameters of the event building blocks and "custom building blocks".

Step S705: judging whether inputs are empty or not; if not, go to step S706; if yes, go to step S708;

step S706, generating formatting data of the building blocks without parameters.

If the input list is judged to be empty through S705, the building block is free of parameters, formatting data of the building block without parameters is generated according to the format, and the formatting data is added into an array of formatting results.

S707 and S712 process recursion queue 1: recursion queue 1 is a globally shared queue, that is, recursion queue 1 may already contain tasks to be processed when parsing the current building block. In S702, if the inputs are found to contain blocks that need to be recursively processed, then the blocks key and depth to be processed are combined into a "recursion task" that is added to the tail of recursion queue 1. The advantage of using "queue+recursion" is that nested building blocks and nested building blocks are adjacent in the final output array, preserving context, while nested hierarchical relationships can be inferred from depth information.

The recursion queue 1 is mainly used for processing known recursion blocks, such as 'repeatedly executing' and 'if..then..otherwise' are obvious nested blocks, and the judgment is that the nested blocks key will appear in the inputs field of the blocks. For example, when traversing the input list of repeatedly executing blocks, the internal value must be the key of the nested block when the field "SUBSTACK" is found, "if. However, the nested blocks are found earlier, but the parameters of the current blocks may not be processed at this time, so the key in the SUBSTACK needs to be added to the recursion queue 1 in advance, and after the current blocks are completely processed, whether the recursion queue 1 has blocks to be processed or not is checked.

S708, inputs are formatted a third time.

The main purpose of this step is to screen each group of data in inputs of each building block for the required parameters, and add the data to the parameter list, and if building blocks requiring recursive processing are encountered in this flow, add the building blocks to the second recursive queue, i.e. recursive queue 2; the function of the recursion queue 2 to be screened is to collect blocks which are not particularly obvious and need to be recursively processed, and other blocks are usually put in the blocks, for example, the 10 parameter in the 10-step block is replaced by other blocks, for example, loudness and the like; optionally, the priority of the recursion queue 2 is higher than that of the recursion queue 1, i.e. when processing the recursion queue, the blocks in the recursion queue 2 are processed first and then the blocks in the recursion queue 1 are processed.

In some embodiments, in step S708, the valid parameters of each graphic code component may be screened one by one, and the graphic code components determined to need the recursive processing are placed in the second recursive queue.

As shown in fig. 8, a process flow diagram of S708 in an embodiment is shown.

Step S801: starting;

step S802: sorting the inputs in the inputs and traversing the inputs one by one;

in implementations, the ordering of inputs is because: blocks containing multiple groups of parameters in the Scratch, sometimes the order of the identification keys in the parameters is not fixed; the results obtained by the two blocks connected by the AND, either of which is performed first, will be different, so that a sort is determined here and then processing is continued. The individual inputs therein need to be ordered.

During the traversal of each input:

step S803: judging whether the input length is 3; if not, entering S804; if yes, go to S805;

in a specific implementation, input is the value corresponding to each field in inputs. Since some blocks can be nested with other blocks, for example, a 10-step position of a "move 10-step" block is a circular frame, called a digital frame in the Scratch, other circular blocks can be placed in addition to the placement parameters, for example, a "loudness" block is inserted into a 10-step position in a "move 10-step" block, which changes the inputs of the "move 10-step" block, and a key of the "loudness" block is inserted into the STEPS field in the "move 10-step" inputs, and in this case, the corresponding data length becomes 3.

Specifically, the input of "move 10 STEPS" corresponds to "stem": 1, [4, [ 10 ] ], and assuming that the key of the loudness building block is "abc", the input of "move" loudness "STEPS" corresponds to "stem": 3, [ abc ], [4, [ 10 ] ], and the data length in the visible [ ] becomes 3, so that special judgment is required.

Step S804: and removing a null value in the input, and marking the last element last of the input.

Step S806: judging whether last is a character; if yes, the description may be a key or character form parameter, then proceed to S807; if not, then go to S808;

step S807: judging whether last is a mark (key) of a building block; if yes, it is indicated that last needs recursive processing (there may be nesting), then S809 is entered; if not, the last is the only common parameter, then S810 is entered;

step S809: adding the building blocks corresponding to the marks to the recursion queue 2; after that, the process proceeds to S811;

in implementations, the end element of input is chosen because the parameters that need to be extracted are typically just at the end of input, e.g., "#a3cc 33". In COLOR ":1, [ 9," #a3cc33 "]; for another example, in a building block of a drop-down list, such as "hit" mouse pointer ", which is a parameter of drop-down selection, where the" hit "building block related to splicing is the key of the other building block, and the other building block storing the" mouse pointer "parameter, the last element of input in the" hit "building block is the key of the other building block, and the other building block can be skipped by performing recursion processing in the recursion queue, and the" mouse pointer "parameter is stored in the fields of the other building block, where in JSON code, the" mouse pointer "parameter is represented as" _mouse_ ", and the corresponding field is represented as: "TOUCHINGOBJECTMENTU"; the "mouse pointer" parameter can be extracted from this other building block by extracting the end of input element from inputs after the fields and inputs are merged or directly from the fields before merging.

Step S811: whether the inputs traversal ends; if yes, ending; if not, returning to step S802;

step S810: splicing last into the parameter list; after that, the process proceeds to S811;

step S808: identifying whether it is a broadcast; if yes, go to S812; if not, the process proceeds to S813:

among them, broadcasting is a special kind of building blocks in Scratch, for example, a "broadcast message" building block, and its structure is different from other building blocks, so special treatment is required.

Step S812: adding a first element last 1 of last into a parameter list, namely broadcasting parameters of the type building blocks; after that, the process proceeds to S811;

step S813: adding the last element of last to the parameter list; after that, the process proceeds to S811;

step S805: whether the first element input 1 of input is a key of other building blocks; if the input has a key, which may be related to recursion, indicating that the native variable is placed in the digital box, then S814 is entered; if not, entering S815;

step S814: adding input [1] to the recursion queue 2; then, the process proceeds to step S811;

step S815: whether input [1] is an array; if yes, go to step S816; if not, the process proceeds to S804, where the parameters are identified.

Step S816: indicating that a custom variable (located in an array) is placed in the digital box and input 1 is added to recursive queue 2.

In some cases, input [1] and last [1] may be the same, for example, "STEPS": 1, [4, [ 10 ] ], where 1, 4 are internal values in Scratch and may be omitted, then in "STEPS": [ "10" ], the parameters obtained by last [1] and input [1] are both "10", and if the data length of input obtained as in the aforementioned S803 is 3, for example, "STEPS": 3, "abc", [4, ", and" 10"], then last [1] and input [2] are both" 10 "and" abc "may represent the key of other blocks placed in the mobile block.

Returning to the flow of fig. 7, after S708, further includes:

step S709, generating formatting data of the current building blocks with parameters: and S708, after finishing, generating a parameter list of the current building block, combining the formatted data [ name, parameter list ] and depth ] of the building block with the parameters according to the format, and adding the formatted data [ name, parameter list ] and depth ] into the finally-to-be-output array.

Step S710, processing the recursive queue 2.

Step S711: the recursive queue 1 is processed.

Because the context of the recursion queue 2 is tighter than that of the original building block, the recursion queue 2 is processed first and then the recursion queue 1 is processed.

As shown in fig. 9, a schematic structural diagram of a formatting device for graphic code component combination provided in an embodiment of the present application is shown. The formatting device of the graphic code component combination is used for formatting the graphic code component combination composed of the graphic code components. The formatting device 900 of the graphic code component assembly in this embodiment corresponds to the formatting method of the graphic code component assembly in the embodiment of fig. 3, so specific implementation details in this embodiment may refer to the above-mentioned embodiments, and the technical details are not repeated here.

The formatting device 900 of the graphic code component combination includes:

an acquisition module 910 for acquiring a combination of graphic code components;

a formatting unit 920, configured to represent each graphic code component included in the graphic code component combination as formatted data in multiple data dimensions, so as to form formatted data of the graphic code component combination.

Optionally, as shown in fig. 10, the formatting unit 920 may specifically include:

a first extraction module 921, configured to obtain execution role information of each graphic code component in the graphic code component combination; wherein, each graphic code component forms each execution role group according to each execution role group;

a second extraction module 922, configured to obtain event information related to each graphic code component under the execution role group; wherein, each graphic code component under each execution role group forms each event group according to each related event information group;

a third extraction module 923 extracts the type of each graphic code component under the event group, depth information representing the nesting relationship thereof, and parameters of the graphic code components having the parameters according to the arrangement order;

And the generating module 924 is configured to form the formatted data of each graphic code component according to the extracted information of each graphic code component, and form the formatted data of the corresponding graphic code component combination according to the arrangement sequence.

Optionally, the third extracting module 923 may include:

a processing control module 9231, configured to control processing of each graphic code component one by one, and add the graphic code component determined to be processed recursively to the first recursion queue;

a first processing module 9232, configured to extract information from each graphic code component outside the first recursion queue and place the information into corresponding formatted data;

the second processing module 9233 is configured to extract information from each graphic code component in the first recursion queue and place the information into corresponding formatted data.

Optionally, the second processing module 9233 may further include:

a parameter screening submodule 92331, configured to screen valid parameters of each graphic code component one by one;

the processing control sub-module 92332 is configured to put the graphic code component determined to need the recursive processing into the second recursive queue.

In this embodiment, functional modules that may be optionally implemented are marked by virtual boxes, which are not limited to the illustration.

As shown in fig. 11, a schematic structural diagram of a graphics programming system in an embodiment of the present application is shown. The graphics programming system 110 may include:

a graphic programming unit 111 for providing a graphic programming interface to a user for receiving user operations to combine the operated graphic code components into a graphic programming work;

the formatting unit 112 is implemented by the formatting device 900, for example, shown in fig. 9, and is configured to format the graphic programming work or the related graphic code component combination thereof to obtain corresponding formatted data.

In some examples, the graphical programming system may be a Scratch-based implementation, containing the graphical programming units for interacting with a user to effect programming of the building block combination; the formatting device of the graphic code component combination in the foregoing embodiment may be integrated into the graphic programming system as a component, a module, or the like, for formatting the graphic code component combination in the graphic programming work or the related reference answer, the comparison module, or the like.

As shown in fig. 12, a schematic structural diagram of a computer device in an embodiment of the present application is shown.

The computer device 120 comprises a memory 121 and a processor 122, the memory 121 having stored thereon a computer program executable on the processor 122, the processor 122 executing the steps of the aforementioned formatting method of a graphical code component combination, or sub-flow thereof (fig. 6, 7, 8, etc.), e.g. of the embodiment of fig. 3 or 4, when the computer program is executed.

In some examples, the processor 122 may be a combination that implements computing functionality, e.g., including one or more microprocessor combinations, digital signal processing (Digital Signal Processing, DSP), ASIC, etc.; the Memory 121 may include a high-speed RAM Memory or may further include a Non-volatile Memory (Non-volatile Memory), such as at least one magnetic disk Memory.

In some examples, the computer device 120 may be implemented in, for example, a server bank, a desktop computer, a notebook computer, a smart phone, a tablet computer, a smart bracelet, a smart watch, or other smart device, or a processing system formed by communicatively connecting these smart devices.

Embodiments of the present application may also provide a computer readable storage medium having stored thereon a computer program which, when run, performs the steps in a formatting method or sub-flows thereof (fig. 6, 7, 8, etc.) of the graphical code component combinations, e.g., in the embodiments of fig. 3 or 4.

That is, the formatting method of the graphic code component combination in the above-described embodiments of the present invention is implemented as software or computer code storable in a recording medium such as a CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine-readable medium and to be stored in a local recording medium downloaded through a network, so that the method described herein can be stored on such software process on a recording medium using a general purpose computer, a special purpose processor, or programmable or special purpose hardware such as an ASIC or FPGA. It is understood that a computer, processor, microprocessor controller, or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the formatting methods for the graphical code component combinations described herein. Furthermore, when a general purpose computer accesses code for implementing the formatting method for the graphical code component combinations shown herein, execution of the code converts the general purpose computer into a special purpose computer for executing the formatting method for the graphical code component combinations shown herein.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer programs. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer program may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium.

For example, each of the functional modules in the foregoing fig. 9, 10 embodiments, etc. may be a software implementation; or may be implemented by combining software and hardware, for example, by a computer program running in memory by a processor in an embodiment of the computer device; alternatively, the circuit may be realized by a hardware circuit.

In addition, each functional module in each embodiment of the present application may be integrated in one processing component, or each module may exist alone physically, or two or more modules may be integrated in one component. The above-mentioned integrated components may be implemented in hardware or in software functional modules. The integrated components described above, if implemented in the form of software functional modules and sold or used as a stand-alone product, may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic or optical disk, or the like.

For example, in the foregoing embodiments shown in fig. 9 and 10, each functional module and sub-module may be implemented by an independent and single program, or may be implemented by different program segments in a program, and in some implementation scenarios, the functional modules may be located in one physical device, or may be located in different physical devices but are communicatively coupled to each other.

In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.

Any process or method description in a flowchart or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process. And the scope of the preferred embodiments of the present application includes additional implementations in which functions may be performed in a substantially simultaneous manner or in an opposite order from that shown or discussed, including in accordance with the functions that are involved.

Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

For example, the foregoing formatting method of the graphic code component combination in the embodiments of fig. 3, 4, etc., where the sequence of the steps may be changed in a specific scenario, and is not limited to the foregoing description.

Although the embodiments of the present specification are disclosed above, the present invention is not limited thereto. Various changes and modifications may be made by one skilled in the art without departing from the spirit and scope of the embodiments of the present invention, and the scope of the invention is therefore intended to be limited only by the appended claims.

Claims

1. A method of formatting a combination of graphical code components, wherein the combination of graphical code components consists of graphical code components; the method comprises the following steps:

Obtaining a graphic code component combination;

representing each graphic code component contained by a graphic code component combination as formatted data over a plurality of data dimensions to form formatted data for the graphic code component combination; the plurality of data dimensions includes: executing roles, events, sequential logic, and types; in the case of a graphic code component having parameters, the plurality of data dimensions further includes parameters; the sequence logic comprises a sequence relation and a nesting relation of code building blocks; the arrangement sequence of the formatting data of each graphic code component is consistent with the arrangement sequence of the graphic code components in the graphic code component combination, and the value of the depth information in the formatting data of each graphic code component represents the nesting position of the graphic code component in the graphic code component combination.

2. The method of formatting a graphical code component assembly of claim 1, wherein the means of formatting comprises:

3. The method of formatting a combination of graphic code components according to claim 2, wherein the sequentially extracting the type of each graphic code component under the event group, the depth information representing the nesting relationship thereof, and the parameters of the graphic code component having the parameters, comprises:

accessing each graphic code component one by one;

4. A method of formatting a combination of graphical code components as claimed in claim 3, wherein said extracting information from each graphical code component outside the first recursive queue comprises:

screening the effective parameters of each graphic code component one by one;

5. The method of formatting a combination of graphical code components of claim 4, wherein the second recursive queue recursively processes more preferentially than the first recursive queue.

6. A method of formatting a combination of graphical code components according to any of claims 3 to 5, characterized in that the graphical code components requiring recursive processing comprise at least one of the following: graphic code components that have nested relationships; there are graphical code components of selectable parameters.

7. Formatting means for a combination of graphic code components, wherein said combination of graphic code components consists of graphic code components; the formatting device of the graphic code component combination comprises:

a formatting unit for representing each graphic code component included in a graphic code component combination as formatted data in a plurality of data dimensions to form formatted data of the graphic code component combination; the plurality of data dimensions includes: executing roles, events, sequential logic, and types; in the case of a graphic code component having parameters, the plurality of data dimensions further includes parameters; the sequence logic comprises a sequence relation and a nesting relation of code building blocks; the arrangement sequence of the formatting data of each graphic code component is consistent with the arrangement sequence of the graphic code components in the graphic code component combination, and the value of the depth information in the formatting data of each graphic code component represents the nesting position of the graphic code component in the graphic code component combination.

8. A graphical programming system, comprising:

A formatting unit implemented by the formatting device of the graphic code component combination according to claim 7, for formatting the graphic programming work or its related graphic code component combination to obtain corresponding formatted data.

9. A computer device comprising a memory and a processor, the memory having stored thereon a computer program executable on the processor, characterized in that the processor, when executing the computer program, performs the steps of the formatting method of the graphical code assembly combination of any of claims 1 to 6.

10. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when run, performs the steps of the formatting method of a graphical code component combination according to any of claims 1 to 6.