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
SearchBlock usage recipe
Multi Detection (MULTI_DETECTION)
Combines multiple scan targets into one condition
Documented for app version 1.0.50Updated:
Block Preview
Captured from the in-app Visual Builder block card in the English UI.
English UI
What Does It Do?
Combines IMAGE, TEXT, COLOR and nested MULTI_DETECTION targets in one block and produces decisions such as all found, any found, all missing or any missing.
Shared Mechanics for Search Blocks
Multiple search regions and excluded regions
IMAGE, TEXT, COLOR and the other search blocks that use the Search Regions editor can define several search regions with + Add Region; OCR_VALUE tries its read regions in order. Inside a search region, Exclude Region skips noisy areas such as a HUD or a badge, and it applies only to the search region it belongs to. From 1.0.51 one search region can hold several excluded regions, each with its own shape and its own variable or Dialog binding.Coming soonv1.0.51
Sticky anchors for edge-aware scaling
You can now assign a sticky anchor to each search region. This brings Region.sticky into the no-code surface so the region can stay aligned to anchors such as top_left, bottom_right, or center when screen geometry changes.
Scan rate, duration, and retry behavior
Search Duration (ms) defines one search window; 0 means a single look. Retry Mode in the Retry & Wait section is Off, Infinite Loop, Retry On True, Retry On False, Wait Until Found, or Wait Until Gone, so a block becomes a one-shot check, a controlled polling step, or a step that waits for a target to appear or to disappear. Retry Timeout (ms, 0 = unlimited) bounds the loop; Scan Rate (Hz) sets scans per second.
Match tuning and device variance
mScore, scale, and scan engine choices matter across themes, display sizes, and rendering differences. Smaller regions plus the right engine dramatically improve builder stability.
When to Use?
1
Use it when one visual, text, or color signal is not enough and the screen state must be confirmed by multiple signals.
How to Use?
1
Add MULTI_DETECTION
2
Add IMAGE, TEXT, COLOR or nested MULTI_DETECTION blocks to Detector Conditions
3
Choose the Detection Logic: All Must Match, Any Must Match, All Must Fail, Any Must Fail, Always True or Always False
4
Configure TRUE/FALSE branches from the result
Parameters
Detector Conditions
IMAGE, TEXT, COLOR or nested MULTI_DETECTION blocks used by the combined scan; scanned top to bottom
Detection Logic
All Must Match (all_success), Any Must Match (one_success), All Must Fail (all_fail), Any Must Fail (one_fail), Always True / Always False (a fixed result regardless of the targets)
Short-circuit
"Skip remaining checks once the result is known" (on by default): remaining targets are skipped once the decision is settled
Result Action
No Action or Click First Match
Score Variable (Advanced)
Writes the 0.0–1.0 confidence to the variable named in Advanced; COMPARE it to drop weak matches (same as IMAGE)
Match Position (matchX/Y/W/H) (Advanced)
Writes the match box into your own variables such as matchX/Y/W/H; CLICK {matchX},{matchY} to act there (same as IMAGE)
| Parameter | Description |
|---|---|
| Detector Conditions | IMAGE, TEXT, COLOR or nested MULTI_DETECTION blocks used by the combined scan; scanned top to bottom |
| Detection Logic | All Must Match (all_success), Any Must Match (one_success), All Must Fail (all_fail), Any Must Fail (one_fail), Always True / Always False (a fixed result regardless of the targets) |
| Short-circuit | "Skip remaining checks once the result is known" (on by default): remaining targets are skipped once the decision is settled |
| Result Action | No Action or Click First Match |
| Score Variable (Advanced) | Writes the 0.0–1.0 confidence to the variable named in Advanced; COMPARE it to drop weak matches (same as IMAGE) |
| Match Position (matchX/Y/W/H) (Advanced) | Writes the match box into your own variables such as matchX/Y/W/H; CLICK {matchX},{matchY} to act there (same as IMAGE) |
Example Usage
1
Scenario: Verify the right page with two signals
2
Add MULTI_DETECTION
3
Add the header text (TEXT) and button image (IMAGE) targets
4
Detection Logic = All Must Match
5
TRUE: Continue, FALSE: WAIT and retry
Combinations / Used With
1
COMBINATIONS:
2
MULTI_DETECTION + CLICK: Click after multiple signals are confirmed
3
MULTI_DETECTION + WAIT: Wait until the page is ready
4
MULTI_DETECTION + LOG: Record the detected screen state
Tip
Using two different signals makes the flow more stable when a single target could false-positive. Put the fastest, most distinctive target first.
Warnings / Cautions
1
WARNING:
2
Too many targets or very large regions slow scanning down
3
Validate each target threshold separately
4
Unnecessary targets add decision latency
Step-by-Step Mastery: Basic → Advanced → Pro
The same block at three levels: a quick start, the real options, and professional techniques.
Basic
The MULTI_DETECTION block combines multiple scan targets (image/text/color-like) into one condition. With logic like "all found" or "any found" it produces a single TRUE/FALSE decision. Simplest use: confirm a screen is the right page not with one visual but with both a header text and a button; TRUE only if both exist. This reduces the false-positive risk of a single target.
Advanced
Detector Conditions hold IMAGE, TEXT, COLOR or nested MULTI_DETECTION blocks (the validator rejects other blocks); you define each separately and validate their thresholds individually. Logic has six options: all_success (ALL must be found — AND), one_success (any one suffices — OR), all_fail (NONE must be found — is the screen clean?), one_fail (at least one must be missing), plus always_success / always_fail (a fixed result regardless of the targets, useful to temporarily disable a branch or for testing). "all vs one" sets how many targets count, "success vs fail" sets whether a match counts as TRUE or FALSE; reason about them together. Result Action has two options: No Action (nothing) or Click First Match (click_first). Short-circuiting and ORDERING are the heart of performance: child targets are scanned top-to-bottom in list order, and the "Skip remaining checks once the result is known" switch is on by default (turn it off when every target must be scanned). Under all_success the decision is settled at the first failing target and the rest are skipped; under one_success it stops at the first succeeding target. So putting the fastest, most distinctive target (e.g. a single small COLOR or a crisp icon) at the top often skips expensive OCR/IMAGE scans without ever running them.
Pro
Think of MULTI_DETECTION as a verification gate: on transition screens where a single signal can deceive, two independent signs (header text + icon) guarantee you are truly on the right screen. For performance keep the target count low and the regions narrow; every unnecessary target adds decision latency. Write the combined match's confidence with scoreVar and use COMPARE to reject a weak detection even when multiple signals pass. contextX/Y/W/H spread the first/combined match's position into variables, so you can CLICK {matchX},{matchY} on the element in the confirmed screen state. The one_success logic is powerful for collecting various signs of the same state across languages/versions into one block.
Real-World Scenarios — Step-by-Step Recipes
Small, reproducible examples that combine several blocks — build them straight into your own macro.
Verify the right page with two signals
- 1Add MULTI_DETECTION
- 2Target 1 = header text, Target 2 = button image
- 3Logic = all_success
- 4TRUE: proceed to the next step
- 5FALSE: WAIT and retry
Catch any one of several error signs
- 1Add MULTI_DETECTION
- 2Add the error icon, red colour, and "Error" text as targets
- 3Logic = one_success
- 4Action = do nothing
- 5TRUE: start a recovery flow with SYSTEM; FALSE: continue normally
Which Blocks to Pair With — Pro Combinations
This block is useful on its own — but it shines when paired with the right partners.
+ CLICK (first match)
Once multiple signals are confirmed, Action = click first match lets you safely tap the element in the verified screen state.
+ WAIT
WAIT until the page is fully ready (all signs settle), then re-verify.
+ COMPARE (score)
Compare the scoreVar confidence to a threshold to reject a weak detection even when multiple signals pass.
+ LOG
LOG which screen state was caught to debug complex flows.
Common Mistakes and Fixes
Adding too many targets or wide regions; scanning slows and the decision lags. Fix: keep only the necessary, distinctive targets and narrow the regions.
Choosing the wrong logic (e.g. all_success when one_success was intended) and rejecting valid screens. Fix: pick the all/one and success/fail combination that fits the scenario.
Not validating each target's threshold (mScore) separately; one chronically failing target breaks the whole decision. Fix: test targets one by one.
Pro Tips
Put the most distinctive and fastest target at the top of the list; short-circuit logic then skips needless scans early.
Use all_fail logic as a "is the screen clean?" check: proceed safely only when no error sign is present.
Under all_success, put the fastest/most distinctive target first: it short-circuits on the first failure and never runs the expensive OCR/IMAGE scans behind it; this single choice cuts the block's latency manyfold.
Use always_success / always_fail logic to temporarily force a gate open/closed or to test a flow; you pin the block's result without deleting its targets.
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 _mdFirst1 = nil
local _mdSuccess1 = 0
local _mdDone1 = false
if not _mdDone1 then
_lastMatch = nil
Snap.screenRefresh()
local _reg3 = Region():noScale()
local m2 = (function()
local _imageOk, _imageValue = pcall(function() return _reg3:find(Asset.image("btn_play"):mScore(0.8), {engine="balanced_image"}) end)
if not _imageOk then
_lastMatch = nil
error(_imageValue, 0)
end
return _imageValue
end)()
_lastMatch = m2
local _mdMatch1_0 = _lastMatch
if _mdMatch1_0 ~= nil then
_mdSuccess1 = _mdSuccess1 + 1
if _mdFirst1 == nil and _mdMatch1_0 ~= nil and _mdMatch1_0 ~= true then _mdFirst1 = _mdMatch1_0 end
end
if _mdMatch1_0 == nil then _mdDone1 = true end
end
if not _mdDone1 then
_lastMatch = nil
Snap.screenRefresh()
local _reg5 = Region():noScale()
local m4 = (function()
local _scanOk, _scanValue = pcall(function() return _reg5:find(Asset.color("#00FF00"):mScore(0.8), {engine="tolerant_color"}) end)
if not _scanOk then
_lastMatch = nil
error(_scanValue, 0)
end
return _scanValue
end)()
_lastMatch = m4
local _mdMatch1_1 = _lastMatch
if _mdMatch1_1 ~= nil then
_mdSuccess1 = _mdSuccess1 + 1
if _mdFirst1 == nil and _mdMatch1_1 ~= nil and _mdMatch1_1 ~= true then _mdFirst1 = _mdMatch1_1 end
end
if _mdMatch1_1 == nil then _mdDone1 = true end
end
local _mdOk1 = _mdSuccess1 == 2
local _mdBranch1 = nil
if _mdOk1 then _mdBranch1 = _mdFirst1 or true end
_lastMatch = _mdFirst1Note: 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.
🔎Scan Region
Keep the search close to the target. Smaller regions are faster and more stable.
🚫Exclude Region
Exclude static noise, badges, animations, or reflective areas to reduce false matches.
⏱Timeout and Scan Rate
Timeout and scan rate define whether the block acts as a single check or controlled polling step.
🎯Match Tuning
mScore, scale, and engine choice must be tuned together for theme, resolution, and rendering differences.
🧭Result Variables
OCR_VALUE writes the number it reads to its result variable (default ocr_val); TEXT writes the text it passed through its find/replace step to the Save Read Value variable (default ocr_val). In Match Variables, the score variable (0.0–1.0 confidence) and the X/Y/W/H variables carry the match confidence and position into later blocks: branch on the score with COMPARE, and in CLICK bind the coordinates to them with {x} or turn on Click on match. _lastMatch is the last match that Click on match uses; _lastOcrText is kept only for older CUSTOM_CODE scripts.
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.