1
Send to the shared area
When one item or a multi-selection is active, the shared-area button can copy the selected part from the workspace, group, true/false action branch, dialog, and variables surfaces into the device-local library.
No-Code Workspace — Block Reference
Flow ControlBlock usage recipeComing soonv1.0.51
Workflow Cycle (WORKFLOW_CYCLE)
Selects and runs one workflow group per invocation
Documented for app version 1.0.51 (not on Google Play yet)Updated:
Block Preview
Captured from the in-app Visual Builder block card in the English UI.
English UI
What Does It Do?
Prepare up to 64 workflow groups inside one block. Sequential mode selects the next group on each invocation; random mode selects one group. Marker mode keeps the current group until the chosen block actually executes and completes, then advances on the next invocation. This block does not start a repeat loop or run workflows in parallel by itself.
When to Use?
1
Use it to alternate workflows, choose one random task per iteration, or keep retrying a workflow until a specific step completes.
How to Use?
1
Add Workflow Cycle from the Flow category.
2
Use Add workflow group to create 1–64 groups and add actions inside each group. In the Logic workspace, open the block and then a group to edit its actions.
3
Choose the Selection mode: Sequential, Random or Advance after marker.
4
In Advance after marker mode, choose a completion marker for every group.
5
Use an outer loop when repeated invocations are needed.
Parameters
Selection mode
Sequential (default): the next group on each invocation. Random: a random group on each invocation. Advance after marker: the current group is kept until its marker actually completes, and the switch happens on the next invocation.
Workflow groups
1–64 enabled groups, each containing at least one executable action. Actions belong inside the groups, not on the block’s own branches.
Completion marker
In Advance after marker mode, choose an executable block inside each group, also on condition branches. Flow blocks such as Break or Group and disabled blocks cannot be markers; a Click or Swipe marker counts only when its gesture was actually dispatched.
Avoid repeating the previous group
In Random mode with at least two groups, leaves the previous group out of the next pick; on by default.
| Parameter | Description |
|---|---|
| Selection mode | Sequential (default): the next group on each invocation. Random: a random group on each invocation. Advance after marker: the current group is kept until its marker actually completes, and the switch happens on the next invocation. |
| Workflow groups | 1–64 enabled groups, each containing at least one executable action. Actions belong inside the groups, not on the block’s own branches. |
| Completion marker | In Advance after marker mode, choose an executable block inside each group, also on condition branches. Flow blocks such as Break or Group and disabled blocks cannot be markers; a Click or Swipe marker counts only when its gesture was actually dispatched. |
| Avoid repeating the previous group | In Random mode with at least two groups, leaves the previous group out of the next pick; on by default. |
Example Usage
1
Group A: IMAGE detection with a completion LOG in its true branch. Group B: a second task. Select Advance after marker and use the true-branch LOG as the marker for A. If detection fails, the LOG is skipped and the next invocation stays on A. Once the LOG completes, the next invocation selects B.
Combinations / Used With
1
Use GROUP to repeat invocations, IMAGE or COMPARE branches to check success, and LOG to make the completion step observable.
Tip
Mark an action inside the success branch, not the condition block itself, when advancement must depend on success.
Warnings / Cautions
1
Empty or disabled workflow groups and deleted markers are invalid and must be corrected. A skipped, event-disabled, or failing marker does not advance the cycle. Selection state resets when the macro restarts. Unlike marker mode, sequential mode advances after the invocation completes.
Step-by-Step Mastery: Basic → Advanced → Pro
The same block at three levels: a quick start, the real options, and professional techniques.
Basic
Create two workflow groups with one LOG each. In sequential mode, the first outer-loop invocation runs only the first group and the second invocation runs only the second group. Selection wraps after the final group. Workflow Cycle does not repeat itself.
Advanced
In Advance after marker mode, choose a completion marker for every group. If the marker is a LOG in an IMAGE true branch, an unsuccessful detection skips the marker and keeps the current group. Completion changes selection only on the next invocation. In Random mode, Avoid repeating the previous group is on by default and leaves the previous group out when at least two groups exist; with it off, every invocation picks from all groups.
Pro
Each Workflow Cycle block has selection state scoped to the current macro run; nested cycle blocks keep independent state. Restarting the macro resets it. Marking a condition block does not distinguish its true and false outcomes: put an explicit completion action at the end of the success branch when success is required. A marker that throws or is skipped by Event State does not advance selection.
Real-World Scenarios — Step-by-Step Recipes
Small, reproducible examples that combine several blocks — build them straight into your own macro.
Alternate two tasks
- 1Set a bounded repeat count on an outer GROUP.
- 2Add Workflow Cycle inside it and choose Sequential mode.
- 3Create two workflows, each with a different LOG or action sequence.
- 4Check that the log order is A, B, A, B: each invocation runs one group.
Stay on a task until detection succeeds
- 1Add IMAGE to the first workflow and a LOG to its true branch.
- 2Add the next task and a completion LOG to the second workflow.
- 3Choose Advance after marker and select the corresponding LOG in each group.
- 4Invoke repeatedly from an outer loop. A false detection must stay on the first group; the invocation after the true-branch LOG completes must run the second group.
Pick a random task on every round
- 1Create three workflow groups that each hold one task, and choose Random as the Selection mode.
- 2Keep Avoid repeating the previous group on so the same task never runs twice in a row.
- 3Put Workflow Cycle inside a bounded outer loop with a short Wait between rounds.
- 4Every group is equally likely; with exactly two groups and this option on, the groups simply alternate after the first random pick, so turn it off for independent picks.
Advance only after a tap was actually sent
- 1In the first workflow group, add IMAGE for the button and a Click block on its true branch.
- 2Choose Advance after marker as the Selection mode and make that Click block the group’s completion marker.
- 3If the image is not found or the tap cannot be dispatched, the next invocation stays on the first group.
- 4Once the tap has been dispatched, the next invocation moves on to the second group.
Which Blocks to Pair With — Pro Combinations
This block is useful on its own — but it shines when paired with the right partners.
+ GROUP
A bounded outer loop invokes workflow selection across multiple iterations.
+ IMAGE / COMPARE
A marker inside a conditional branch prevents advancement until that branch executes.
+ LOG
An explicit completion marker makes the selected workflow and completed step observable during testing.
Common Mistakes and Fixes
Do not expect all groups to run concurrently: each invocation selects only one group.
Choosing the condition itself as a marker is not equivalent to choosing its success branch. Select an action inside that branch to require success.
An empty or disabled group, or a deleted marker, is not a valid configuration. Add an enabled action to every group and reselect missing markers.
Trying to use a flow block as the completion marker. Comment, Break, Continue, Return Value, Error Handler, Group, Workflow Cycle and Time/Repeat gate blocks, an empty Custom Code block and disabled blocks cannot be markers; choose an action that actually runs inside the group, such as a Click or a Wait.
Pro Tips
Start with LOG actions and a bounded two- or three-iteration test; add clicks and swipes after confirming selection order.
Copying the block remaps marker identities to the copied actions. After deleting or replacing a marked action, recheck the selection in every group.
Nested Workflow Cycle blocks keep their own selection: the inner cycle advances only when the outer cycle runs the group that contains it. In Sequential mode the order advances only after the selected group has finished; if an error inside the group is caught by a surrounding Try-Catch block, the same group is selected again on the next invocation.
This Block's Code (Editor View)
LuaThe Lua below is what the Code Editor generates for this block with sample settings. Adding cases, branches, actions or loops, or changing settings, extends the generated code accordingly. Study it to see what the block does under the hood, to learn Lua, or to copy and adapt it. Use the Copy button (top-right) to paste it into the Code Editor, or “Try in Editor →” to run it in the live editor.
local __mh_workflow_cycle_state = {}
do
__mh_workflow_cycle_state["00000000-0000-4000-8000-000000000001"] = __mh_workflow_cycle_state["00000000-0000-4000-8000-000000000001"] or {index = 1, advance = false}
local _mh_workflow_1 = __mh_workflow_cycle_state["00000000-0000-4000-8000-000000000001"]
if _mh_workflow_1.index == 1 then
_mh_workflow_1.active = "00000000-0000-4000-8000-000000000002"
System.log("workflow A")
elseif _mh_workflow_1.index == 2 then
_mh_workflow_1.active = "00000000-0000-4000-8000-000000000003"
System.log("workflow B")
end
_mh_workflow_1.active = nil
_mh_workflow_1.index = _mh_workflow_1.index % 2 + 1
endNote: generated code can evolve across versions; helper names (e.g. _reg1, m1) and internal optimizations may change. The logic and the called APIs reflect the block’s behavior.
Shared Controls for This Block Family
The guidance below is not identical for every block. It summarizes the professional controls that most often repeat in the selected block family.
🔀Branch and Exit Rules
Define TRUE/FALSE, try/catch, and loop exit behavior before chaining more blocks.
📦Results and Scope
Keep it explicit where group, dialog, and loop variables are created and where they are consumed.
🛑Safety Bounds
Long flows become brittle quickly without timeouts, ASSERT blocks, BREAK logic, or explicit guards.
🧩Modularity
Moving repeated steps into GROUP and GROUP_CALL improves readability in larger projects.
Builder vs Lua Boundary
Raw touch pointer lifecycle stays code-first
TOUCH and TOUCH_BREAK cover recipe-style touch flows. Raw pointer choreography such as Touch.down, Touch.move, Touch.up, Touch.dispatch, Touch.reset, Touch.breakAll, and Touch.releaseAfter is not exposed as a first-class builder block.
Touch.downTouch.moveTouch.upTouch.dispatchTouch.resetTouch.breakAllTouch.releaseAfterBounded dialog design is builder-backed; freer composition stays code-first
The DIALOG block and dialog designer cover a bounded field set in the builder: Info Text, Text Input, Checkbox, Description, Radio Group, Dropdown, Multi Select, Tab Group, Date Time, Number Range, Slider, Image Picker, Color Picker, File Picker, Recorder Picker, Tag, Signature, and Spacer. The buttons are designed too: the Positive button and Negative button tabs set each button’s text, background, and border color, corner radius, and minimum height next to a preview. Freer Setting.builder composition, multi-step wizard flows, and mixed HUD/dialog choreography still do not map 1:1 into the builder.
Coming soonv1.0.51Two more fields: Agent Detect references (agent_detect_editor) lets the user pick a saved reference set or add and edit references, and Save confirms the selection; Navigation setup editor (navigation_editor) edits a saved map, marker and route from the Dialog and returns the setup and route selection without moving the character.
Setting.builderDialogHudTextViewAgentDetectEditorNavigationEditorAdvanced HTTP request chaining stays code-first
HTTP_GET, HTTP_POST, and HTTP_PUT cover common fixed-method flows; HTTP_REQUEST covers one bounded request with method, header lines, body, content type, query parameters (GET and DELETE), timeout, and a bounded retry. These blocks never throw; they write the status code (-1 on a network failure). Cookie handling, chained request objects, and lower-level client flows still need the code editor.
Request()Request.setCookieRequest.getCookiesCUSTOM_CODEGeneral programming surfaces stay code-first
The MAP, LIST, JSON_PARSE, REGEX_MATCH, and METRICS blocks cover the everyday cases: map actions, a static list, reading a value from a JSON path, regex match, find, replace, and split, and metrics actions. The rest of the Map, Array, JSON, Regex, and Metrics APIs (for example Array sort, filter, and map) is broader than the builder recipe model and stays on the CUSTOM_CODE and code editor side.
MapArrayJSONRegexMetricsLow-level runtime and Lua composition stays code-first
Runtime helpers, raw Request objects, Lua built-ins such as print/pcall/xpcall, and free-form object chaining patterns are represented through CUSTOM_CODE or the code editor.
RuntimeRequestprintpcallxpcallCUSTOM_CODEDebug Mode and Breakpoints
Each block card now exposes an independent breakpoint toggle. When enabled, the breakpoint preference is stored with the block.
Breakpoints are only emitted into runtime code when Debug Mode is enabled from Visual Builder settings. When Debug Mode is off, breakpoints stay saved but do not pause execution.
Use ASSERT for fail-fast validation, and use breakpoints for step-by-step tracing and controlled pauses in the same flow.
Variable Scope
1
Variables defined with SET_VARIABLE are accessible throughout the macro (global scope). All blocks can read/write the same variable.
2
However, a variable defined inside a GROUP will be 'nil' (undefined) until the GROUP executes. Blocks outside the GROUP using this variable may produce unexpected results.
3
FOR_EACH loop variables (item and index) only carry valid values inside the loop body. Outside the loop they are outside local scope and should not be used.
4
TRY_CATCH error variable is only valid within the catch block. If the try block succeeds, the catch branch is not entered and the error variable remains undefined.
5
TIP: Before using a variable inside a GROUP, assign a default value with SET_VARIABLE outside the GROUP. This way the variable won't be nil even if the GROUP has not run.
Inline Expressions
You can embed variable values and calculations into text fields using {{ expression }} syntax. Expressions inside double curly braces are evaluated as Lua code and the result is inserted into the text.
Syntax
{{ expression }}Examples
Skor: {{ score + 1 }} → "Skor: " .. tostring(score + 1){{ name }} kazandı! → tostring(name) .. " kazandı!"X:{{ x }} Y:{{ y }} → "X:" .. tostring(x) .. " Y:" .. tostring(y)Supported Blocks
SET_VARIABLELOGCOMPARECLIPBOARD_WRITENOTIFY_TOASTKV_SET
Security Note
Expressions are checked by the sandbox policy. Security-sensitive calls like loadstring, require, debug are automatically blocked.
General Tips
1
Keep scan regions as small as possible — improves speed, reduces false matches.
2
Always add an exit condition when using infinite loops (BREAK, timeout, or conditional exit).
3
Use network operations and error-prone steps inside TRY_CATCH.
4
If you need global error handling, use the Error Handler (ERROR_HANDLER) block as a singleton in the project.
5
Small coordinate offsets (CLICK/SWIPE) improve tap accuracy across different DPI and screen scales.
6
Customize macros with Dialog block — different parameters each run.
7
Define repeating steps once with GROUP_CALL, call from many places.
Cross-macro local library
Local Shared Macro Area
The Local Shared Macro Area moves blocks, variables, dialog fields, gallery assets, and imported media dependencies between macros on the same device. It is device-local, not cloud sync, not Firebase sharing, and not a replacement for public macro sharing.
Professional usage model: put a reusable login flow, common scan region, shared dialog form, variable group, template image, color profile, replay recording, or imported PLAY_SOUND media file into the shared area from one macro, then import it from the relevant + menu in another macro.
VISUAL_BLOCKSVARIABLESDIALOG_FIELDSTEMPLATE_IMAGECOLOR_SWATCHREPLAY_RECORDMEDIA_FILE2
Import into another macro
The shared-area entry under the + menu imports the selected item into the surface that opened it. Main workspace, group, action branch, dialog, and variables each receive the compatible item type.
3
Share gallery assets
Gallery items include template images, color swatches, replay records, and imported audio/media files. They can move between macros on the same device so repeated templates, colors, recordings, and PLAY_SOUND media assets do not need to be captured again.
4
Keep it clean
The shared area is not a permanent dumping ground. Delete stale shared items from the shared-library panel; imports create a copy in the target macro and do not rewrite the source macro flow.
Checkpoint: after importing, review block names, linked template/image/color/record/media assets, and variable names in the target macro. The shared area creates a copy; delete stale shared items from the shared-library panel to keep the library clean.
AI assistant
Build a block chain with MH AI in natural language
Tell MH AI what you want in plain language; it proposes the right block sequence and lands it in the workspace after you approve. In the current release it works with cloud providers such as Gemini, Claude, and OpenAI; on-device local models are on the roadmap.