Focus target determination device, focus target determination method, and focus target determination program

Abstract

To provide a focus target determination device, a focus target determination method, and a focus target determination program that can automatically determine which item on a screen is to be focused.SOLUTION: The present embodiment includes the steps of: (1) acquiring specified controls on a screen as determination targets in order; (2) determining whether or not the acquired control corresponds to a type of control for which focus can be set; (3) when it is determined that it corresponds to the type of control for which focus can be set, obtaining information on "whether focus setting is possible" in a definition management table associated with the control targeted for the determination, and determining whether or not the acquired information corresponds to "TRUE"; and (4) when it is determined that it corresponds to "TRUE", deciding the control targeted for the determination as the focus target.SELECTED DRAWING: Figure 58

Description

[Technical Field]

[0001] The present invention relates to a focus target determination device, a focus target determination method, and a focus target determination program. [Background technology]

[0002] Patent document 1 discloses an information processing device that aims to reduce the operational burden on the user by making it easier to move the focus to items on an application screen that require input or selection (see paragraph 0011 of patent document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2015-69590 Summary of the Invention [Problem to be solved by the invention]

[0004] In fields where screen operations are performed in this way, focus display is often set on the screen for the purpose of improving user visibility, etc. Focus refers to an object on the screen, such as a window, input box, icon, button, or image, being in an active (selected) state where it can be operated. For example, the cursor on a focused item will blink, as shown in Figure 47.

[0005] However, in the past, for example, when a screen was opened, the person in charge had to manually set which item on the screen to focus on by programming, which was a time-consuming and labor-intensive process. For example, as shown in the dotted square frame in Figure 50, in order to set the "Base Date Text" item on the screen to be the focus when the screen was opened, the person in charge had to program it accordingly.

[0006] The present invention has been made in consideration of the above-mentioned problems, and aims to provide a focus target determination device, a focus target determination method, and a focus target determination program that can automatically determine which item on the screen to focus on. [Means for solving the problem]

[0007] In order to solve the above-mentioned problems and achieve the object, a focus target determination device according to the present invention is a focus target determination device comprising a control unit and a storage unit, wherein the storage unit stores a table including control identification data for identifying controls that are elements constituting a screen and focus possibility identification information that is information for identifying whether or not focus can be set for the control, and the control unit comprises a determination target acquisition means that acquires controls as determination targets in order from designated controls on the screen, and a control type determination means that determines whether or not the control acquired by the determination target acquisition means corresponds to a type of control to which focus can be set, based on the control identification data for the control acquired by the determination target acquisition means. and a focusability determination means for, if the control type determination means determines that the control is applicable, acquiring the focusability identification information in the table linked to the control identification data for the control that was the subject of the determination, and determining whether the acquired focusability identification information indicates that it is possible to set focus on the control, and a focus target determination means for, if the focusability determination means determines that the control that was the subject of the determination is applicable, determining the control that was the subject of the determination as the focus target, wherein, if the control type determination means or the focusability determination means determines that the control is not applicable, the determination target acquisition means acquires the control next to the control that was the subject of the determination as a new determination target.

[0008] In addition, the focus target determination device of the present invention is characterized in that the order in which the judgment target acquisition means acquires the judgment targets is determined based on row numbers and column numbers assigned to controls on the screen.

[0009] In addition, in the focus target determination device of the present invention, the control unit further includes a focus impossible state determination means which, when the focus possibility determination means determines that the control that has been determined to be the subject of the determination is a control that can be used as the subject of the focus when viewed alone, but is in a state where it cannot be used as the subject of the focus in relation to other controls, and when the focus impossible state determination means determines that the control that has been determined to be the subject of the determination is not in the impossible state, the determination target acquisition means acquires the control next to the control that has been determined to be the subject of the determination as a new determination target when the control type determination means or the focus possibility determination means determines that the control does not correspond, or when the focus impossible state determination means determines that the control is in the impossible state.

[0010] In the focus object determination device according to the present invention, the control in the disabled state is a control in a locked state or a hidden state.

[0011] Furthermore, in a focus target determination method according to the present invention, a table including control identification data for identifying controls that are elements constituting a screen and focusable / non-focusable identification information that is information for identifying whether or not focus can be set for the control is stored in the storage unit, and the control unit executes a determination target acquisition step of acquiring designated controls on the screen in order as determination targets, a control type determination step of determining whether or not the control acquired in the determination target acquisition step corresponds to a type of control that can be focused based on the control identification data for the control acquired in the determination target acquisition step, and The method includes a focusability determination step in which, if it is determined that the control is applicable in the control type determination step, the focusability identification information in the table linked to the control identification data for the control that was the subject of the determination is acquired, and the acquired focusability identification information is determined to indicate whether or not it is possible to set focus on the control; and a focus target determination step in which, if it is determined that the control is applicable in the focusability determination step, the control that was the subject of the determination is determined to be the focus target, and in the determination target acquisition step, if it is determined that the control is not applicable in the control type determination step or the focusability determination step, the control next to the control that was the subject of the determination is acquired as a new determination target.

[0012] Further, in a focus target determination program according to the present invention, the focus target determination program is executed by an information processing device having a control unit and a storage unit, and the storage unit stores a table including control identification data for identifying controls that are elements constituting a screen and focus possibility identification information that is information for identifying whether or not focus can be set to the control, and the program is executed by the control unit by: a determination target acquisition step of acquiring controls as determination targets in order from designated controls on the screen; and a control type determination step of determining whether or not the control acquired in the determination target acquisition step corresponds to a type of control to which focus can be set, based on the control identification data for the control acquired in the determination target acquisition step. and a focusability determination step of, if it is determined in the control type determination step that the control is applicable, acquiring the focusability identification information in the table linked to the control identification data for the control that was the subject of the determination, and determining whether the acquired focusability identification information indicates that it is possible to set focus on the control; and a focus target determination step of, if it is determined in the focusability determination step that the control that was the subject of the determination is determined as the focus target, wherein in the determination target acquisition step, if it is determined in the control type determination step or the focusability determination step that the control is not applicable, a control next to the control that was the subject of the determination is acquired as a new determination target. [Effects of the Invention]

[0013] According to the present invention, it is possible to automatically determine which item on the screen is to be focused. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a focus object determination device. [Figure 2] FIG. 2 is a diagram showing the prerequisites. [Figure 3] FIG. 3 is a diagram showing the prerequisites. [Figure 4] FIG. 4 is a diagram showing the prerequisites. [Figure 5] FIG. 5 is a diagram showing the prerequisites. [Figure 6] FIG. 6 is a diagram showing the prerequisites. [Figure 7] FIG. 7 is a diagram showing the prerequisites. [Figure 8] FIG. 8 is a diagram showing the prerequisites. [Figure 9] FIG. 9 is a diagram showing the prerequisites. [Figure 10] FIG. 10 is a diagram showing the prerequisites. [Figure 11] FIG. 11 is a diagram showing the prerequisites. [Figure 12] FIG. 12 is a diagram showing the prerequisites. [Figure 13] FIG. 13 is a diagram showing the prerequisites. [Figure 14] FIG. 14 is a diagram showing the prerequisites. [Figure 15] FIG. 15 is a diagram showing the prerequisites. [Figure 16] FIG. 16 is a diagram showing the prerequisites. [Figure 17] FIG. 17 is a diagram showing the prerequisites. [Figure 18] FIG. 18 is a diagram showing the prerequisites. [Figure 19] FIG. 19 is a diagram showing the prerequisites. [Figure 20] FIG. 20 is a diagram showing the prerequisites. [Figure 21] FIG. 21 is a diagram showing the prerequisites. [Figure 22] FIG. 22 is a diagram showing the prerequisites. [Figure 23] FIG. 23 is a diagram showing the prerequisites. [Figure 24] FIG. 24 is a diagram showing the prerequisites. [Figure 25] FIG. 25 is a diagram showing the prerequisites. [Figure 26] FIG. 26 is a diagram showing the prerequisites. [Figure 27] FIG. 27 is a diagram showing the prerequisites. [Figure 28] FIG. 28 is a diagram showing the prerequisites. [Figure 29] FIG. 29 is a diagram showing the prerequisites. [Figure 30] FIG. 30 is a diagram showing the prerequisites. [Figure 31] FIG. 31 is a diagram showing the prerequisites. [Figure 32] FIG. 32 is a diagram showing the prerequisites. [Figure 33] FIG. 33 is a diagram showing the prerequisites. [Figure 34] FIG. 34 is a diagram showing the prerequisites. [Figure 35] FIG. 35 is a diagram showing the prerequisites. [Figure 36] FIG. 36 is a diagram showing the prerequisites. [Figure 37] FIG. 37 is a diagram showing the prerequisites. [Figure 38] FIG. 38 is a diagram showing the prerequisites. [Figure 39] FIG. 39 is a diagram showing the prerequisites. [Figure 40] FIG. 40 is a diagram showing the prerequisites. [Figure 41] FIG. 41 is a diagram showing the prerequisites. [Figure 42] FIG. 42 is a diagram showing the prerequisites. [Figure 43] FIG. 43 is a diagram showing the prerequisites. [Figure 44] FIG. 44 is a diagram showing the prerequisites. [Figure 45] FIG. 45 is a diagram showing the prerequisites. [Figure 46] FIG. 46 is a diagram showing the prerequisites. [Figure 47] FIG. 47 is a diagram showing an example of focus on the screen. [Figure 48] FIG. 48 is a diagram showing an example of setting "focus action at the top." [Figure 49] FIG. 49 is a diagram illustrating an example of the definition management table. [Figure 50] FIG. 50 is a diagram showing an example of the layout development screen. [Figure 51] FIG. 51 is a diagram showing an example of the master page screen. [Figure 52] FIG. 52 is a diagram showing an example of a child screen. [Figure 53] FIG. 53 is a diagram showing an example of setting a "focus action on next item." [Figure 54] FIG. 54 is a diagram showing an example of the layout development screen. [Figure 55] FIG. 55 is a diagram showing an example of the master page screen. [Figure 56] FIG. 56 is a diagram showing an example of a child screen. [Figure 57] FIG. 57 is a diagram showing another example of a child screen. [Figure 58] FIG. 58 is a diagram showing an example of a flowchart of processing according to this embodiment. [Figure 59] FIG. 59 is a diagram of an example screen showing an example of a control. [Figure 60] FIG. 60 is a diagram of an example screen showing an example of a control and the row properties assigned to it. [Figure 61] FIG. 61 is a screenshot showing an example of a control and the column properties assigned to it. [Figure 62] FIG. 62 is a diagram showing an example of a screen when item A is locked by a business rule. [Figure 63] FIG. 63 is a diagram showing an example of a screen when item B is locked by a business rule. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of a focus target determination device, a focus target determination method, and a focus target determination program according to the present invention will be described in detail with reference to the accompanying drawings. Note that the present invention is not limited to these embodiments.

[0016] [1. Overview] (1) Background In general business applications, processes that involve moving the focus are often built into the system to assist the business operator in their operations. For example, when the application is first started, the focus may be initially set to the first input-enabled item, and after input is complete, the focus may be set to the next item. If such focus setting is not performed, the business operator will have to move the focus to the next item themselves, which reduces usability.

[0017] When the screen of a business application becomes complex, the focus control also becomes complex. In particular, when the items that users want to set change dynamically depending on the situation, the setting patterns also become complex. In conventional development, it was common for developers to achieve complex focus control by manually programming.

[0018] (2) Problems However, when it comes to focus control, which requires complex settings, the programming becomes more difficult, increasing the number of steps required to complete the system. There is also the problem that resetting the settings can be difficult if there are sudden changes to the settings.

[0019] (3) Solution In a low-code development platform, focus control is achieved through action processing (hereafter referred to as a "focus set action"). In a system developed with a low-code development platform, the controls for the entire screen are centrally managed in a database, making it easy to access the controls for the entire screen within a focus set action. This has the advantage that the controls on the screen can be organized hierarchically, making them easy to understand.

[0020] Taking advantage of this advantage, the present embodiment achieves the following two actions, for example.

[0021] The first is an action that sets focus to the first focusable item. Specifically, this action automatically determines the first focusable control on the screen and sets focus to the control determined as a result.

[0022] The second is an action that sets the focus to the first focusable item after the specified control. Specifically, you specify a control in the action settings, and the action automatically determines the first focusable control after the specified control, and sets the focus to the control determined as a result.

[0023] (4) Effects In this way, in this embodiment, by centrally managing the controls on the screen, the action can automatically determine the focus destination during action processing, eliminating the need for developers to perform focus control individually.

[0024] To summarize the above, in this embodiment, the high cost of focus setting during system construction has been solved by using a low-code development platform. The specific configuration and operation will be described below.

[0025] [2. Configuration] An example of the configuration of a focus target determination device 100 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a block diagram showing an example of the configuration of the focus target determination device 100.

[0026] The focus target determination device 100 is a commercially available desktop personal computer. Note that the focus target determination device 100 is not limited to a stationary information processing device such as a desktop personal computer, but may also be a portable information processing device such as a commercially available notebook personal computer, a PDA (Personal Digital Assistant), a smartphone, or a tablet personal computer.

[0027] The focus object determination device 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. The units included in the focus object determination device 100 are connected to each other so as to be able to communicate with each other via any communication path.

[0028] The communication interface unit 104 communicably connects the focus object determination device 100 to a network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via a communication line. Here, the network 300 has a function of connecting the focus object determination device 100 and the server 200 so that they can communicate with each other, and is, for example, the Internet or a LAN (Local Area Network). Note that data such as various masters described below may be stored in the server 200, for example.

[0029] An input device 112 and an output device 114 are connected to the input / output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that cooperates with a mouse to achieve a pointing device function. In the following, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112.

[0030] Various databases, tables, files, etc. are stored in the storage unit 106. Computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes are recorded in the storage unit 106. The storage unit 106 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, etc.

[0031] The storage unit 106 includes, for example, a definition management table 106a.

[0032] As shown in FIG. 49, the definition management table 106a includes, for example, definition identification data (definition ID and definition name) and control information, which is information about controls that are elements that make up a screen.

[0033] As shown in Figure 49, the control information consists of, for example, control identification data (ID and name) for identifying the control, input requirement identification information (required) which is information for identifying whether input to the control is required, and focus availability identification information (focus setting possible) which is information for identifying whether focus can be set on the control.

[0034] The control identification data (ID and name) also includes information about the type of the control. For example, in the example of Fig. 49, the name of control element 1, "Base Date Label," includes information that control element 1 corresponds to the control type "Label," while the name of control element 2, "Base Date Text," includes information that control element 2 corresponds to the control type "Text."

[0035] The control unit 102 is a CPU or the like that performs overall control of the focus object determination device 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processes based on these stored programs.

[0036] The control unit 102 has, in terms of functional concept, for example, (1) a determination target acquisition unit 102a as a determination target acquisition means for acquiring controls designated on the screen in order as determination targets, (2) a control type determination unit 102b as a control type determination means for determining whether or not a control acquired by the determination target acquisition means corresponds to a type of control for which focus can be set, based on the control identification data for the control acquired by the determination target acquisition means, and (3) a control type determination unit 102c as a control type determination means for determining whether or not a control acquired by the determination target acquisition means corresponds to a type of control for which focus can be set, when the control type determination means determines that the control corresponds to the type of control, and for determining whether or not the acquired focusable / non-focusable identification information corresponds to the control identification data for the control that was the subject of the determination. (4) when the focusability determination means determines that the control that is the subject of the determination is a control that can be set as a focus target when viewed alone, but is in a state where it cannot be set as a focus target in relation to other controls; and (5) when the focusability determination means determines that the control that is the subject of the determination is a control that can be set as a focus target, a focusability determination unit 102e as a focus target determination means that determines that the control that is the subject of the determination is a control that can be set as a focus target when viewed alone.

[0037] The judgment target acquisition unit 102a acquires the judgment targets in order from the specified control on the screen. The acquisition order is determined, for example, based on the row numbers and column numbers assigned to the controls on the screen. Specifically, the judgment target acquisition unit 102a acquires the controls in order from the smallest row number, and if the row numbers are the same, acquires the controls in order from the smallest column number. Details of this acquisition will be explained in [5-2] below.

[0038] The control type determination unit 102b determines whether the control acquired by the judgment target acquisition unit 102a corresponds to a type of control on which focus can be set, based on the control identification data (ID and name) for the control acquired by the judgment target acquisition unit 102a.

[0039] If the control type determination unit 102b determines that the control is applicable, the focus possibility determination unit 102c acquires the focus possibility identification information (whether focus can be set) in the definition management table 106a (see Figure 49) linked to the control identification data (ID and name) for the control that was the subject of the determination, and determines whether the acquired focus possibility identification information (whether focus can be set) is TRUE, which indicates that focus can be set on the control.

[0040] If the focusability determination unit 102c determines that the control is the above, the focusability determination unit 102d determines whether the control that is the subject of the determination is a control that can be focused when viewed alone, but is in a state where it cannot be focused in relation to other controls (=according to the business rules described in [3-3] below). The above-mentioned control that is in a state where it cannot be focused is, for example, a control that is locked or hidden.

[0041] The focus target determination unit 102e determines the focus target, and may or may not take into consideration the determination result (=business rule) of the focus-unavailable state determination unit 102d at this time.

[0042] If the judgment result (= business rule) of the focus-unavailable state judgment unit 102d is not taken into consideration, the focus target determination unit 102e determines the control that was the subject of the judgment as the focus target when the focus-unavailable state judgment unit 102c judges that the above applies.

[0043] When taking into consideration the judgment result (= business rule) of the focus-unavailable state judgment unit 102d, if the focus-unavailable state judgment unit 102d judges that the focus-unavailable state is not reached, the focus target determination unit 102e determines the control that was the subject of the judgment as the focus target.

[0044] So far, we have explained the case where the control to be judged can be determined as the focus target, but as will be explained below, if the control to be judged cannot be determined as the focus target, the judgment target acquisition unit 102a acquires the control next to the control to be judged as the new judgment target.

[0045] When the judgment result (= business rule) of the non-focusable state judgment unit 102d is not taken into consideration, the judgment target acquisition unit 102a acquires the control next to the control that was the judgment target as a new judgment target when the control type judgment unit 102b or the focusable state judgment unit 102c judges that the above does not apply.

[0046] When taking into consideration the judgment result (= business rule) of the focus-unavailable state judgment unit 102d, if the control type judgment unit 102b or the focus-unavailable state judgment unit 102c judges that the above does not apply, or if the focus-unavailable state judgment unit 102d judges that the above-mentioned state is impossible, the judgment target acquisition unit 102a acquires the control next to the control that was the judgment target as a new judgment target.

[0047] [3.Prerequisites] In this section, prerequisites for explaining the processing in this embodiment will be described.

[0048] [3-1. Overview of Low-Code Development Tools] (1) What is low-code development? Low-code development is a development method for building systems. In this specification, the system refers to a general ERP system used by companies for their business operations, hereafter referred to as a "business application."

[0049] In traditional development, developers write source code themselves rather than programming, and build the entire business application, from the UI to the business logic required for processing. In contrast, low-code development generally involves the use of low-code development tools, which primarily generate the UI portion of a business application based on configuration.

[0050] In other words, developers can set up low-code development tools to build the UI portion of business applications without having to program themselves, which has the benefit of reducing the amount of work developers have to do and enabling more efficient system development.

[0051] (2) The benefits of efficient business application development and low-code development As hardware becomes more diverse, business applications are also required to run on multiple hardware platforms, such as client-server business applications that run between clients and servers, web-based business applications that require an internet connection, and mobile business applications that are intended for use on mobile devices.

[0052] While hardware is becoming more diverse, the processing required for business applications often remains largely unchanged. The processing in business applications often refers to processing specialized for a specific business (e.g., a time attendance system or a sales system), and the logic that realizes such processing will hereafter be collectively referred to as "business logic."

[0053] For example, when we consider the time-stamping process found in a time attendance application (a process that saves a user's arrival and departure times in a database), the business logic of the time-stamping process itself does not change significantly even if the business application runs on different hardware. In other words, as shown in Figure 2, it is possible to standardize the business logic that is called by simply creating the hardware-dependent UI parts separately.

[0054] In this way, the ideal situation in business application development is to be able to use common business logic for the same processes regardless of the hardware, because the cost of development, testing, and modification increases as the number of duplicated parts of business logic increases.

[0055] However, with business applications developed using traditional programming, it is often impossible to reuse common business logic across hardware platforms. For example, consider the case where development of a Web-based system begins after the development of a client-server business application. In this case, while developing the client-server business application, it is necessary to extract the business logic in a form that can be reused in the Web-based system. While it is possible to modify the business logic of an already developed client-server business application into a reusable structure, given the risk of introducing defects through modifications, many organizations incur additional development costs and create new business logic specifically for the Web-based system, as shown in Figure 3. Thus, with traditional development methods, common business logic and efficient development require business applications to be designed with future changes in mind. This is highly dependent on the skills of the designer and is therefore difficult.

[0056] On the other hand, in applications developed using low-code development, the UI portion of the business application is constructed using the low-code development tools described below. As shown in Figure 4, developers create only the business logic portion, which inevitably results in the separation of the UI and business logic portions. As a result, the duplication of business logic that occurs in development using traditional programming is eliminated, making it possible to carry out development efficiently without relying on the skills of the designer. The low-code development tools described below mainly generate the UI portion of the business application and perform the linking process to use independent business logic in the application.

[0057] (3) What are low-code development tools? The following explanation assumes two types of users: developers and business operators at client companies. The explanation is divided into two stages: the development stage, where developers use low-code development tools to create UI settings and business logic for business applications, and the usage stage, where business operators actually use the applications.

[0058] The development stage is when developers use the low-code development platform to register business application configuration information in a database. The usage stage is when the low-code execution platform analyzes the configuration information registered in the development stage and converts it into an actual business application, allowing business operators to execute the business. In this specification, the low-code development platform and the low-code execution platform are collectively referred to as the "low-code development tool."

[0059] Here, we will explain how to manage the data generated at each stage. From a control perspective, it is necessary to clearly separate the database in which developers manage application settings during development from the database in which business operators manage application settings referenced during business use. This is to prevent developers from directly operating the business database. In the following explanation, the database for managing application settings used by developers will be referred to as the "development application DB," and the database for managing application settings used by business operators will be referred to as the "business application DB."

[0060] (3-1) Development stage As shown in the upper half of Figure 5, the development stage is where developers use low-code development tools (the low-code development platform) to develop business applications. Low-code development mainly involves setting up the layout of the application screen and the series of event processes (actions, logic flow) that occur when the layout is operated. Finally, by linking the layout and logic flow, the UI portion of the business application can be generated. The main settings during the development stage are as follows (A) to (D).

[0061] (A) Layout development Configure the screen layout of the business application.

[0062] (B) Logic flow development and action development This sets the processing part of the business application. With low-code development tools, the processing in the business application can be set in units called actions (the linking of the UI part and business logic mentioned above is also done through these actions). Furthermore, by connecting actions with flows, the order in which a series of actions are processed can be set. This setting of the processing order of actions is called a "logic flow."

[0063] This section explains the special action settings for calling business logic. In low-code development, developers only create the business logic portion through individual programming tasks, while the UI portion is generated by operating the low-code development tool. Therefore, in order to call business logic from the UI side, developers must convert the created business logic into an API and register it in the API master. Business logic can be executed by calling the API registered in the API master from the API call action.

[0064] (C) Combining layout and logic flow Set the logic flow (B) to be assigned to the layout set in (A).

[0065] (D) Business rule development In complex applications, there is a need for dynamic control, such as making control input mandatory (or optional) or locking it depending on the screen state. For this reason, in addition to the settings (A) to (C) above, dynamic control such as switching controls under certain conditions is necessary. In this way, a mechanism for setting certain rules (called "conditions") for controls on a screen and controlling the controls when those rules are met is called a "business rule."

[0066] The above application setting information can be shared among multiple application screens. Specifically, a template screen (hereafter referred to as a "master page") is created that extracts the common parts of the application screens, and multiple child screens can inherit this master page, allowing the child screens to use the master page setting information. This mechanism is called "master page inheritance."

[0067] (3-2) Usage stage As shown in the lower half of Figure 5, the usage stage is when the low-code development tool (on the low-code execution platform) analyzes the registered business application settings, converts them into a business application, and then the business operator operates the business application. Operational tests performed before delivery are also performed on the created business application.

[0068] [3-2. Layout, Logic Flow and Actions] This section explains the basic operations of low-code development tools used by developers. As explained in [3-1], low-code development forcibly separates the UI and business logic within a business application. By configuring a low-code development tool, developers can generate parts other than the business logic without having to program them themselves. In the following explanation, application configuration using a low-code development tool is referred to as "UI definition."

[0069] The registered UI definition is saved in the definition management table (see Figure 6) of the application DB. The definition management table manages the control information, logic information, and information linking the layout and logic within the definition. The meanings of the terms in the definition management table are as follows: · Definition ID··· A Guid string that is automatically assigned when creating a UI definition. · Definition name···Named by the developer when creating the UI definition. ·Control Information···See "(1) Layout Development" below. Action Information: See "(2) Logic Flow and Action Development" below. ·Logic flow information···See "(2) Logic flow and action development" below. Linking information: See "(3) Combining layout and logic" below.

[0070] (1) Layout development During the development stage, developers register control information in the development application DB by operating the layout development screen (see Figure 7). For example, in the example screen shown in Figure 8, a text box for entering a base date has been selected from the date text and placed. Clicking on the placed control allows you to set properties according to the type of control clicked. For example, date text has a required property that indicates whether its input is required by the application. In the example screen shown in Figure 8, the required property is ON, so the base date text is a control that must be entered by the application.

[0071] In the usage stage, an application is generated based on the settings. In the example shown in Figure 8 in the previous paragraph, the base date is required, so if the business operator attempts to proceed without entering the base date, an error will be displayed as shown in Figure 9.

[0072] Here, as a supplement, we will explain the positional information of each control in low-code development tools. Low-code development tools clarify the positional relationship of each control by internally assigning row and column information to controls placed by the developer. For example, in the screen example shown in Figure 10, the card panel displays the following information: base date (label + text box), client CD (label + text box), and display button. For placed controls, low-code development tools automatically set row and column property information, as shown in Figure 10. When converting the layout information set on the low-code development platform into a business application, this matrix property information can be used to identify the positional relationship of controls.

[0073] (2) Logic flow and action development (2-1) Action settings During the development stage, developers register logic flow information and action information in the development application DB by operating the logic flow and action development screen (see Figure 11). The initial state of logic flow settings in low-code development tools is a state in which the flow is connected between the start action that starts the process and the end action that ends the process, as shown in Figure 12. The settings are made by incorporating the necessary actions between these two actions, as shown in Figure 13.

[0074] By clicking on an action and editing it, you can make detailed settings for each action. The settings that can be made vary depending on the action. For example, for a message display action, you can set the type of message and the message content. In the example of message action settings shown in Figure 14, a Yes / No type message box is set to display the message "Displaying business partners, is this OK?"

[0075] When a Yes or No type message box is selected in the action settings, the logic flow processing can be branched depending on whether Yes or No is selected. In the example shown in Figure 15, if Yes is selected in response to the message (Displaying customer information, is this OK?), processing will be performed to obtain the customer information using the API call action, and if No is selected, the processing will end.

[0076] (2-2) Special action settings for linking business logic In the example shown in Figure 16, after selecting Yes in the message, the API call action is executed. As mentioned above, low-code development tools can only generate the UI portion of a business application, and developers must develop business logic such as retrieving and updating business data through programming. In other words, the business logic itself is external logic independent of the low-code development tool. An API call action is a special action that can link and execute UI information created with a low-code development tool and business logic created by a developer. As preparation, developers convert the business logic they want to call from the UI created with the low-code development tool into an API (see Figure 17) and register it in the API master (see Figure 18).

[0077] We will now explain how to turn business logic into an API. As shown in Figure 17, an API is created in advance in a module that is loaded when the business application is executed. In other words, it manages the actual processing of the business logic to be executed and key information that will be required when calling the API later. In the example in Figure 17, an API is registered that, when a base date (date) is specified as an argument, returns a list of customer information (customer CD, customer name, etc.) registered as of that date.

[0078] The following explains how to register the API information in the API master. The created API information is registered in the API management table as shown in Figure 18.

[0079] Then, on the editing screen for the API call action, as shown in Figure 19, the developer selects the required API from the API master that stores the APIs previously registered by the developer, and sets the arguments and return values ​​for that API.

[0080] The action information will now be explained. As shown in Figure 20, the action information in the definition management table contains information set for each action (ID, name, action type, and each setting, etc.). In the example of a message display action, the message type is registered as 3 (Yes, No) and the message content is "Displaying the customer, is this OK?". In the example of an API call action, the value of the argument (base date) passed to the API is set to the value of the base date text on the screen, and the values ​​of the returned values ​​(customer CD and customer name, etc.) are set to the customer CD text cell and customer name text cell on the screen.

[0081] The logic flow information will now be explained. As shown in FIG. 21, the logic flow information in the definition management table contains information set for each logic flow (such as ID, name, and flow group connecting actions). The previous action ID is the ID of the action that will be processed first, and the next action ID is the ID of the action that will be executed after the previous action is executed. The callback key is a key used to determine the result of a selection made by the user when they select an action during action execution. In the example of FIG. 21, if the user selects Yes in the message box, the callback key identifies the flow with Yes, and the action set in the next action ID is executed.

[0082] (3) Combining layout and logic During the development stage, the developer assigns a logic flow to each control on the layout development screen, thereby registering the linking information in the development application DB (see Figure 22). The controls and flows created in "(1) Layout development" and "(2) Logic flow and action development" are assigned. As shown in Figure 23, the control properties include an event item (click event in the case of a button control), where the flows previously registered are displayed in a pull-down list.

[0083] The following explains the linking information. As shown in Fig. 24, the logic flow information in the definition management table registers three pieces of information linked together: the control (display button) ID, the event type, and the ID of the logic flow (logic flow 1). For controls that can be assigned to multiple events, the linking cannot be specified using only the control ID, so the event type must be included in the linking information (e.g., text box validation processing and exit processing).

[0084] In the usage stage, when the business operator presses the display button, the low-code execution platform executes the logic flow assigned to the display button (see Figure 25). In the example in Figure 25, when Yes is selected, the API (customer acquisition process) linked to the API call action is executed, the customer is acquired, and the process ends. In contrast, when No is selected, the process jumps to the end action and ends there.

[0085] [3-3. Business Rules] This section explains how developers can set business rules. In typical business applications, even for the same field, there are cases where the fields that you want business operators to enter or not enter dynamically change depending on the situation. For example, on the customer master maintenance screen, if you have transactions with both individual and corporate customers, you need to manage whether the registered customer is an individual or a corporation. Generally, for corporate customers, the corporate number is often managed as information. For this reason, there is a need to dynamically control the input of fields, such as requiring the entry of a corporate number if the customer is a corporation, but not allowing it to be entered if the customer is an individual (locking or hiding the corporate number input field).

[0086] To achieve this kind of dynamic screen control, it is first necessary to set the conditions (hereafter referred to as "conditions") required for screen control. In the example mentioned in the previous paragraph, if the corporate classification is 1 (individual), the corporate number must be locked, as shown in Figure 26.

[0087] In addition to the above-mentioned action information, the definition management table stores condition information and business rule information, as shown in Fig. 27. For details about the condition information and business rule information, see (1) and (2) below.

[0088] (1) Condition information (condition settings) Condition settings are constructed as a single formula by setting the elements on the screen as values ​​on the left and right sides and combining them with equal (or inequality) signs for comparison. Examples of values ​​that can be set in the formula include constant information such as numbers and strings, as well as the value of a control on the screen (you can specify the type of value to set for each formula). The left and right sides of the formula are compared, and if the comparison result is true, the screen information is updated based on the business rules described below. An example of the condition development screen is shown in Figure 28, and an example of a definition management table for setting conditions is shown in Figure 29.

[0089] Furthermore, multiple expressions and conditions can be included within a single condition, and by linking each condition with AND or OR, it is possible to specify more complex conditions. Buttons are provided for adding expressions and conditions. An example of the condition development screen is shown in Figure 30, an example of condition information is shown in Figure 31, and an example of when the condition becomes true is shown in Figure 32.

[0090] (2) Business rule information (business rule settings) A business rule defines what updates will be dynamically made to the set control when the set condition is true. Three types of business rules can be selected: "Lock," "Hidden," or "Required." When the condition is true, the set control will be locked, hidden, or required. The business rule setting screen displays a matrix table with a list of controls on the vertical axis and a list of conditions on the horizontal axis, and cells can be checked. The setting is completed when the developer specifies the business rule type (the process to be performed when the condition is met) and checks the matrix table.

[0091] In this way, a low-code development platform makes it easy to set up dynamic screen updates, which can often be complex, without programming, minimizing the burden of setting up and the occurrence of unintended bugs. The following four are some of the features of business rule setting using a low-code development platform:

[0092] One of its features is that dynamic screen updates that can be determined by values ​​can be completed simply by setting conditions and business rules. If you try to achieve control by setting logic flow, the settings are complicated, and if values ​​are rewritten after a decision is made, it can cause problems depending on the order in which actions are processed.

[0093] The second feature is that the separation of conditions and business rules simplifies settings that tend to become complicated. This is because conditions and states are managed in the database as separate items within the definition.

[0094] The third feature is that business rules can be set in a matrix format, allowing complex business rules to be set on a single screen.

[0095] The fourth feature is that in addition to the matrix format settings, the information required for the settings can be easily checked as shown in 1 to 3 below, which helps to minimize the setup costs even when developing large-scale applications. 1. Clicking on a condition (horizontal axis) will take you to the corresponding condition setting screen. 2. Clicking on the control (vertical axis) will highlight the displayed layout screen. 3. Clicking on a control on the layout screen selects (focuses on) the row in the matrix.

[0096] Conventional large-scale application screens have an issue with the enormous number of conditions and controls, which makes the setup work burdensome. However, features 1 to 4 above make it easier to check conditions and layouts, reducing the burden.

[0097] Examples of settings when setting business rules are shown in Figures 33 and 34. Also, an example of a definition management table when setting a lock as a business rule is shown in Figure 35.

[0098] With these settings, if the business operator changes the value of the corporation classification to 1 (individual), the corporation number (text) will be locked as shown in FIG.

[0099] [3-4. About inheritance] This section explains how developers can configure master page inheritance. A "master page" is a screen that serves as a template for each screen in a business application. By inheriting and using a master page that matches the characteristics of each screen, such as for registration processing and report output processing, development costs for each screen can be reduced. For example, in [3-1], we explained the configuration settings that developers must make using a business partner master maintenance application, a business partner registration application. However, similar to business partner master maintenance, other master maintenance applications share the same business application purpose: displaying, adding, modifying, and deleting master information required by business operators. Therefore, by creating a master page that combines the functions common to all master maintenance screens (displaying, adding, modifying, and deleting data), and then inheriting the master page for each master maintenance screen, the configuration costs for each master maintenance application can be reduced.

[0100] Master pages allow you to set placeholders, which are areas where settings can be added on the child screen side. By adding settings to the placeholders set on the master page on the child screens that inherit the master page, you can develop business applications with a minimum of individual settings. Also, areas where no placeholders are set cannot be changed on the child screen side, so as long as the same master page is inherited, behavior is consistent between screens. As a result, development can be carried out with quality guaranteed. There are two types of placeholders: "1. Placeholders (controls) that can be set during layout development" and "2. Placeholders (actions) that can be set during logic flow and action development."

[0101] First, we will explain "1. Placeholders (controls) that can be set during layout development." Figure 37 is an example of a screen when layout settings are made for a master page for a master maintenance screen. A special control called a placeholder can be used on the layout setting screen for a master page. Then, as shown in Figure 38, on a child screen that inherits the master page, you specify the master page to inherit. If a placeholder is set on the specified master page, you can place a control on the child screen in the corresponding location. For information on control placement, see [3-2]. In the registered data, the child screen controls placed on the placeholder are registered as child elements of the placeholder, as shown in Figure 39.

[0102] Next, we will explain "2. Placeholders (Actions) that can be set when developing logic flows and actions." Figure 40 is an example of a screen when logic flows and actions are set for a master page for a master maintenance screen. A special action called a placeholder can be used on the logic flow setting screen for a master page. The logic flows set on a master page are displayed in a list as master page flows (cannot be edited). If a placeholder action is included in the logic flow set on the master page, a logic flow linked to the placeholder action is automatically generated on the child screen side and displayed in a list as a flow for (child screen name) (can be edited). When a placeholder action is executed, the logic flow on the linked child screen side is executed recursively, so that the necessary processing can be set on the child screen side. See Figures 41 to 43.

[0103] Please note the following points regarding the areas enclosed in dotted square frames in Figures 42 and 43. That is, when a placeholder action is set, a logic flow ID is assigned on the master page side. On the child screen side, this logic flow ID is used to register logic flow information (even if there are multiple child screens that inherit from it, this logic flow ID is used in common).

[0104] [3-5. Flowchart] The flowcharts of the processing explained in [3-1] to [3-4] are shown in Figs. 44 to 46. Fig. 44 is a flowchart from application operation by the client to completion of the end action of the relevant action. Fig. 45 is a flowchart when a placeholder action is used in the logic flow executed in the flowchart of Fig. 44. Fig. 46 is a flowchart up to completion of business rule determination.

[0105] [4. Pre-settings] In this section, the pre-settings required to perform the processing according to this embodiment will be described.

[0106] There are two types of focus set actions: 1. The first is an action that sets focus to the first focusable item (focus to top action). 2. The second is an action that sets focus to the first focusable item after the specified control (action to focus on the next item).

[0107] Below, in [4-1], the pre-settings required to perform the action of focusing on the top will be explained, and in [4-2], the pre-settings required to perform the action of focusing on the next item will be explained.

[0108] [4-1. Pre-settings required to perform the action of focusing on the top] Figure 48 is an example of a logic flow in which a "focus at the beginning action" is placed between a start action and an end action. When this logic flow is executed, the "focus at the beginning action" is executed.

[0109] The control information registered in the low-code development platform is registered in the definition management table in order from the top, as shown in Figure 49. Then, as shown in Figure 50, the identification name, whether it is required, and whether it can be focused are set for each control on the layout development screen.

[0110] Combining this focus set mechanism with inheritance can further reduce the setup load. Specifically, as shown in Figure 51, by creating a logic flow that uses a focus action at the beginning on the master page screen and assigning it to the screen's startup event, as shown in Figure 52, there is no need to write focus set processing on the child screen that inherits the master page, and a general-purpose focus set can be achieved.

[0111] [4-2. Pre-settings required to perform the action to focus on the next item] Figure 53 is an example of a logic flow in which a "Focus on next item action" is placed between a start action and an end action. When this logic flow is executed, the "Focus on next item action" is executed. In the "Focus on next item action", the reference control (in Figure 53, "Reference date text") is selected on the edit screen.

[0112] When "Reference Date Text" is selected as the reference control, the focus will be placed on "Customer Code From Text", which is the next focusable control after "Reference Date Text", as shown in Figure 54, surrounded by a dotted square frame.

[0113] Combining this focus set mechanism with inheritance can further reduce the setup load. As shown in Figure 55, on the master page screen, a logic flow that uses a focus action for the next item is created and assigned to the validation event of the set control. This means that, as shown in Figures 56 and 57, child screens that inherit the master page do not need to implement their own logic flow, and can simply use the master page's base date text and the logic flow assigned to the base date text's validation event. As a result, on the child screen side, simply placing a control in a placeholder makes it possible to achieve a general-purpose focus set without having to configure the child screen side.

[0114] In [4-1] and [4-2] above, we have explained the pre-settings required to automatically determine which controls can be focused even in situations where there is a large number of controls that can and cannot be focused. Furthermore, by using the inheritance mechanism in combination, the pre-settings required for focus setting can be significantly reduced, making it easy to develop a mechanism that is highly convenient for application users.

[0115] [5. Specific examples of processing] In this section, a specific example of the processing in this embodiment will be described.

[0116] Below, [5-1] explains the flowchart of the processing in this embodiment, [5-2] explains the rearrangement of controls, etc., and [5-3] explains how to determine the focus target taking business rules into consideration.

[0117] [5-1. Flowchart of processing in this embodiment] In this section, the flow for determining the focus target will be explained with reference to the flowchart in Fig. 58. The key point in this flow is that whether or not each control can be focused is determined mainly by a determination based on the type of control, which will be explained in step S9 below, and a determination based on properties, which will be explained in step S10 below.

[0118] When processing begins (START in FIG. 58), the logic flow is executed first (step S1 in FIG. 58). Details of the logic flow execution process are as explained in [3-5] using FIG. 44 and FIG. 45. At this time, a flag is set when the focus set action is executed. If multiple flags are set for one logic flow, the flag of the later action takes priority.

[0119] Next, updating is performed according to business rules (step S2 in FIG. 58). Details of the updating process according to business rules are as explained in [3-5] using FIG. 46. By updating according to business rules, the lock control, display control, etc. of the control are reflected.

[0120] Next, it is determined whether or not the focus action flag is set (step S3 in FIG. 58). If the focus action flag is not set (step S3 in FIG. 58: No), the processing ends (END in FIG. 58).

[0121] On the other hand, if the focus action flag is set (step S3 in FIG. 58: Yes), the controls on the screen are rearranged in the order of row property and column property (step S4 in FIG. 58). Details of the rearrangement will be explained in [5-2] below.

[0122] Next, it is determined whether a flag to set focus to the top or a flag to set focus to the next item is set (step S5 in FIG. 58). If a flag to set focus to the top is set (step S5 in FIG. 58: Focus on Top flag), the judgment target acquisition unit 102a acquires the top control (step S6 in FIG. 58) and proceeds to the next step S8. On the other hand, if a flag to set focus to the next item is set (step S5 in FIG. 58: Focus on Next Item flag), the judgment target acquisition unit 102a acquires the control next to the control set as the reference control (step S7 in FIG. 58) and proceeds to the next step S8.

[0123] Then, as will be described below, it is determined in order by loop processing whether or not the control acquired by the determination target acquisition unit 102a is a focusable control (step S8 in FIG. 58).

[0124] First, the control type determination unit 102b determines whether the control acquired in step S6 or S7 corresponds to a type of control for which focus can be set (step S9 in FIG. 58).

[0125] Specifically, the control type determination unit 102b refers to the definition management table 106a, and if the control being determined is, for example, a text box, determines that the control being determined is a type of control for which focus can be set (step S9 in FIG. 58: Yes). If the determination is Yes, the process proceeds to the next step S10.

[0126] In response to this, the control type determination unit 102b refers to the definition management table 106a, and if the control being determined is, for example, a label, determines that the control being determined is a type of control on which focus cannot be set (step S9 in FIG. 58: No). If the determination is No, the process returns to step S8, and the determination target acquisition unit 102a acquires the next control in the definition management table 106a as the determination target.

[0127] Next, the focusability determination unit 102c determines whether the control being determined is a control on which focus can be set, in other words, whether the "focusable" property for the control being determined is "TRUE" (step S10 in FIG. 58).

[0128] Specifically, the focusability determining unit 102c refers to the definition management table 106a, and if the property of "focusable" for the control being determined is "TRUE", it determines that the control being determined is a control on which focus can be set (step S10 in FIG. 58: Yes). If the determination is Yes, the process proceeds to the next step S11.

[0129] In response to this, the focusability determination unit 102c refers to the definition management table 106a, and if the property of "focusable" for the control being determined is "FALSE", it determines that the control being determined is a control for which focus cannot be set (step S10 in FIG. 58: No). If the determination is No, the process returns to step S8, and the determination target acquisition unit 102a acquires the next control in the definition management table 106a as the determination target.

[0130] Next, the focus-unavailable state determining unit 102d determines whether the control being determined is in a state where focus cannot be set (locked state or non-display state) (step S11 in FIG. 58).

[0131] Specifically, the focus-unavailable state determination unit 102d refers to the definition management table 106a, and if the control being determined is not in a locked state or a hidden state, determines that the control being determined is not in a state where focus cannot be set (step S11 in FIG. 58: Yes). If the determination is Yes, the process proceeds to the next step S12.

[0132] In response to this, the focus-unavailable state determination unit 102d refers to the definition management table 106a, and if the control being determined is in a locked state or a hidden state, determines that the control being determined is in a state where focus cannot be set (step S11 in FIG. 58: No). If the determination is No, the process returns to step S8, and the determination target acquisition unit 102a acquires the next control in the definition management table 106a as the determination target.

[0133] Details of determining the focus target in consideration of the business rules as explained in step S11 will be explained in [5-3] below.

[0134] Finally, the focus target determination unit 102e determines, as the focus target, the control for which the focus unavailable state determination unit 102d has determined that the control is not in a state in which focus cannot be set (step S11 in FIG. 58: Yes).

[0135] This completes the focus target determination process (end of FIG. 58).

[0136] [5-2. Rearrangement of controls] This section explains in detail the rearrangement of controls described in step S4 of [5-1]. It also explains how to determine the focus target based on the rearranged controls.

[0137] (1) Rearranging controls As shown in Figure 59, when there are multiple controls on one screen, the focus set cannot be determined unless the context of each control is clearly defined. In the low-code development platform, when controls are placed, row and column property information is assigned to each control, and this information is used to rearrange the controls.

[0138] Row properties are assigned 0, 1, etc. from the top of the screen as shown in Figure 60. Column properties are assigned 0, 1, etc. from the left of the screen as shown in Figure 61.

[0139] Then, controls are registered in definition management table 106a in order from the control with the lowest row number, or, if the row numbers are the same, from the control with the lowest column number. In the case of the controls in the screen examples of Figures 59 to 61, the controls are registered in definition management table 106a in the following order: label of item A, text box of item A, label of item B, text box of item B, label of item C, and text box of item C.

[0140] Here, in the case of the "Focus on top action", which item is the focus target in the example screens of Figures 59 to 61 will be explained. The control at (row number: 0, column number: 0) is a label (label of item A), so it cannot be focused. In contrast, the control at (row number: 0, column number: 1) is a text box (text box of item A), so it can be focused (the focus target).

[0141] Also, in the case of the "Focus on the next item of the control (text box of item B) at (row number: 0, column number: 3)" action, we will explain which item will be the focus target in the screen examples of Figures 59 to 61. The control at (row number: 1, column number: 0), which is the next item, is a label (the label of item C), so it cannot be focused. In contrast, the control at (row number: 1, column number: 1) is a text box (the text box of item C), so it can be focused (the focus target).

[0142] [5-3. Deciding what to focus on based on business rules] This section explains in detail how to determine the focus target taking into account the business rules described in step S11 of [5-1].

[0143] By using the business rule mechanism described in [3-3], it is possible to dynamically switch between locked, hidden, and required states for controls on the screen. As a result of updates based on business rules, an item that could be focused before the logic flow was executed may become locked or hidden, making it impossible to set the focus. For this reason, in this embodiment, the focus target is not immediately reflected when a focus action is executed, but is instead determined after the business rules are reflected, as described in [5-1].

[0144] As an example, as shown in Figure 62, if item A is locked by the business rules and the "Focus on top action" is set, the top item, item A, is locked and cannot be focused, so the focus is set to item B.

[0145] As another example, as shown in Figure 63, if item B is locked by business rules and the "Focus action on next item of item A" is set, item B, which is the next item of item A, is locked and cannot be focused on, so the focus is set on item C.

[0146] In order to perform control that takes into account the judgment of such business rules, when a focus action is executed, only a flag is set as explained in [5-1], and the actual focus set processing itself is performed after the business rules are updated. This flag mechanism allows developers to set the focus to the top item that takes into account the final updated results of the business rules, regardless of where in the logic flow the "focus at top action" is set. In other words, even if the value on the screen is changed after the focus at top action is executed, the result will not change, allowing for a high degree of freedom in setting up logic flows.

[0147] [6. Summary of this embodiment] As described above, the focus object determination device 100 according to this embodiment can automatically determine which item (control) on the screen is to be the focus object. This eliminates the need for developers to manually perform complex focus control.

[0148] Furthermore, according to the focus target determination device 100 of this embodiment, even when the state of a control changes dynamically due to business rules, it is possible to automatically determine which item (control) on the screen to focus on, taking into consideration the state of the control after the change.

[0149] Conventionally, focus control has been performed through programming, making it difficult to build a system unless the developer accurately understands the screen item to be focused on for each pattern. As a result, complex focus control has led to problems such as increased costs for configuration and testing. Furthermore, complex programming increases the likelihood of defects, increasing the risk of reduced user satisfaction.

[0150] Therefore, in this embodiment, for example, it is possible to automatically determine which controls can be focused from among the controls on the screen.

[0151] This simplifies focus control settings, which tend to be complicated. Furthermore, because focus control is a setting required for almost all system screens, the mechanism of this embodiment, which can simplify focus settings, reduces the man-hours required for setting and testing, and contributes to early system operation. Furthermore, since the focus control settings are simplified, system malfunctions can be minimized, which is expected to have the effect of increasing user satisfaction.

[0152] [7. Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

[0153] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of SDGs Goals 12, 13, and 15.

[0154] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0155] 8. Other Embodiments The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

[0156] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

[0157] Furthermore, the processing procedures, control procedures, specific names, information including parameters such as registered data and search conditions for each process, screen examples, and database configurations shown in this specification and drawings can be changed as desired unless otherwise specified.

[0158] Furthermore, with regard to the focus object determination device 100, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.

[0159] For example, all or any part of the processing functions of the focus object determination device 100, particularly the processing functions performed by the control unit, may be implemented by a CPU and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the focus object determination device 100 as needed. That is, a computer program for providing instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). This computer program is executed by being loaded into RAM, and cooperates with the CPU to form the control unit.

[0160] This computer program may also be stored in an application program server connected to the focus object determination device 100 via any network, and all or part of it may be downloaded as needed.

[0161] Furthermore, the program for executing the processes described in this embodiment may be stored in a non-transitory computer-readable recording medium or configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) disc.

[0162] Furthermore, a "program" is a data processing method written in any language or description method, regardless of the format, such as source code or binary code. Note that a "program" is not necessarily limited to a single structure, but also includes a structure that is distributed as multiple modules or libraries, or a structure that achieves its function by cooperating with a separate program, such as an OS. Note that the specific configuration and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known configurations and procedures.

[0163] The various databases stored in the memory unit are storage means such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and providing websites.

[0164] The focus target determination device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. The focus target determination device 100 may be realized by installing software (including programs, data, etc.) that causes the device to perform the processing described in this embodiment.

[0165] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit depending on various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Industrial Applicability]

[0166] The present invention is useful, for example, in the field of screen development. [Explanation of symbols]

[0167] 100 Focus target determination device 102 Control section 102a Judgment target acquisition unit 102b Control type determination section 102c Focus possibility determination unit 102d Unfocusable state determination unit 102e Focus target determination unit 104 Communication interface unit 106 Storage section 106a Definition management table 108 Input / Output Interface Section 112 Input Device 114 Output Device 200 servers 300 Network

Claims

1. A focus target determination device including a control unit and a storage unit, which is disposed in an application provision system configured on a low-code platform, The storage unit includes: A table is stored that includes control identification data for identifying controls that are elements that make up a screen, action identification information for identifying actions to be performed by an application, logic flow information that is a setting of the processing order of the actions, and focusability identification information that is information for identifying whether or not it is possible to set a focus on the control, The control unit a determination target acquisition means for acquiring the control(s) as a determination target in order from the specified control(s) on the screen; a control type determination means for determining whether the control acquired by the determination target acquisition means corresponds to a type of control for which focus can be set, based on the control identification data for the control acquired by the determination target acquisition means; a focus possibility determination means for, when the control type determination means determines that the control is applicable, acquiring the focus possibility identification information in the table associated with the control identification data for the control that is the subject of the determination, and determining whether the acquired focus possibility identification information indicates that the control is applicable; a focus target determination means for determining, when the focus possibility determination means determines that the control is applicable, as a focus target; Equipped with The determination target acquisition means acquires a determination target when a logic flow is executed due to an event occurrence and a focus action is set in the logic flow when the client performs a screen operation in the application, when the control type determination means or the focusability determination means determines that the control is not applicable, the determination target acquisition means acquires a control next to the control that was determined as the determination target as a new determination target; A focus object determination device comprising:

2. 2. The focus target determination device according to claim 1, wherein the focus action is an action of setting focus to a top item or an action of setting focus to a top focusable item after a specified control.

3. The order in which the determination object acquisition means acquires the determination objects is It is determined based on the row and column numbers assigned to the controls on the screen; The focus object determining device according to claim 1 ,

4. The control unit When the focusability determining means determines that the control is applicable, a focusability determining means determines whether the control that is the subject of the determination is a control that can be focused when viewed alone, but is in a state where it cannot be focused in relation to other controls. Further provided with the focus target determination means, when the focus impossible state determination means determines that the control is not in the impossible state, determines the control that is the object of the determination as the focus target; the determination target acquisition means acquires a control next to the control that was the determination target as a new determination target when the control type determination means or the focus possibility determination means determines that the control is not applicable, or when the focus impossible state determination means determines that the control is in the impossible state; The focus object determining device according to claim 1 ,

5. The control in the disabled state is a control in a locked state or a hidden state; The focus object determining device according to claim 4 ,

6. A focus target determination method executed by an information processing device having a control unit and a storage unit, which is disposed in an application provision system configured on a low-code platform, The storage unit includes: A table is stored that includes control identification data for identifying controls that are elements that make up a screen, action identification information for identifying actions to be performed by an application, logic flow information that is a setting of the processing order of the actions, and focusability identification information that is information for identifying whether or not it is possible to set a focus on the control, The control unit executes a determination target acquisition step of acquiring the control(s) as a determination target in order from the specified control(s) on the screen; a control type determination step of determining whether the control acquired in the determination target acquisition step corresponds to a type of control on which focus can be set, based on the control identification data for the control acquired in the determination target acquisition step; a focus possibility determination step of acquiring the focus possibility identification information in the table associated with the control identification data for the control that is the subject of the determination in the control type determination step, and determining whether or not the acquired focus possibility identification information indicates that it is possible to set a focus on the control; a focus target determination step of determining, when it is determined that the control is applicable in the focus possibility determination step, the control that is the subject of the determination as the control to be focused; Including, The determination target acquisition step includes, when the client performs a screen operation in the application, an event occurs, a logic flow is executed, and a determination target is acquired when a focus action is set in the logic flow; In the determination target acquisition step, if it is determined that the control does not correspond in the control type determination step or the focusability determination step, a control next to the control that was determined as the determination target is acquired as a new determination target; A method for determining a focus target, comprising:

7. A focus target determination program executed by an information processing device having a control unit and a storage unit, which is disposed in an application provision system configured on a low-code platform, The storage unit includes: A table is stored that includes control identification data for identifying controls that are elements that make up a screen, action identification information for identifying actions to be performed by an application, logic flow information that is a setting of the processing order of the actions, and focusability identification information that is information for identifying whether or not it is possible to set a focus on the control, The control unit executes a determination target acquisition step of acquiring the control(s) as a determination target in order from the specified control(s) on the screen; a control type determination step of determining whether the control acquired in the determination target acquisition step corresponds to a type of control on which focus can be set, based on the control identification data for the control acquired in the determination target acquisition step; a focus possibility determination step of acquiring the focus possibility identification information in the table associated with the control identification data for the control that is the subject of the determination in the control type determination step, and determining whether or not the acquired focus possibility identification information indicates that it is possible to set a focus on the control; a focus target determination step of determining, when it is determined that the control is applicable in the focus possibility determination step, the control that is the subject of the determination as the control to be focused; Including, The determination target acquisition step includes, when the client performs a screen operation in the application, an event occurs, a logic flow is executed, and a determination target is acquired when a focus action is set in the logic flow; In the determination target acquisition step, if it is determined that the control does not correspond in the control type determination step or the focusability determination step, a control next to the control that was determined as the determination target is acquired as a new determination target; A focus target determination program featuring:

Images