Set local run-time options

Syntax1 - set option

opt option [value]

 

Syntax2 - save/restore options

opt save|restore

 

Parameters

option - one of words specified in the table.

value - one of values specified in the table.

option When QM uses it value
    0 other
hidden When in macro commands is specified only window name (class is not specified). Search only visible windows. 1 - Search all windows. Hidden windows are always searched when class is specified, also with hid-.
clip Clipboard commands (paste/outp, str.getsel, str.setsel). Preserve (restore) clipboard text. 1 - Do not preserve clipboard text.
err On run-time error. End macro. Show error. 1 - Continue macro. Don't show error.
waitmsg When waiting (wait, autodelay, etc). Read more in remarks. Completely block thread execution.

1 - Allow to receive Windows messages and COM events.

2 - The same as 1, but sets this option for current thread (not only for current function).

waitcpu Autodelay. Apply only simple autodelay. 1 - Also wait for CPU. See RtOptions waitcpu_time and waitcpu_threshold. Read more in remarks.
slowmouse Mouse commands (mou, lef, rig, mid, dou). Move mouse immediately. 1 - move mouse slowly. The speed depends on macro speed (spe) and on the distance.
slowkeys key Don't wait between keys. 1 - Wait a little after each key event. The speed depends on macro speed (spe).
keymark (QM 2.2.0) key. Read more in remarks. Use correct scancodes.

1 - Use modified scancodes.

 

QM 2.3.3. This is default in autotext lists.

keysync (QM 2.2.1) key. Use to make it either faster or more reliable.

Use default synchronization method.

 

The macro waits when sent keys are actually received by the target window. Since there is no completely reliable way to know this, it waits only for a limited time period. It also waits while the window is busy. This method is fast and reliable in most cases. However in certain conditions it may be slower.

 

In exe, uses method 2 instead. Waiting until the target window actually receives sent keys is not supported in exe, because it is too expensive (uses hooks in dll).

 

Here "in exe" actually means "in exe, if QM is not running". If QM is running, all synchronization methods work in exe like in QM.

 

A special synchronization method is used if the target window belongs to the same thread.

1 - Don't use synchronization. The keys are sent without waiting until the window actually receives them. Fastest. Should not be used if not using low level hooks (unless in exe), because it can create problems with keyboard triggers.

 

2 - Use minimal synchronization. This method is used by default in exe. The macro only waits while the target window is busy. The synchronization does not work well (keys may be sent too fast) with some windows and in stress conditions (low memory, busy CPU, etc). Slowest in most cases (about 20-100 %). Should not be used if not using low level hooks (unless in exe), because it can create problems with keyboard triggers.

 

3 - Use maximal synchronization. The macro indefinitely waits until the key is received by the target window. Since there is no completely reliable way to know this, in some windows this can force the macro to wait indefinitely. Therefore this method should not be used in macros designed to work in any window. Exe uses method 2 instead.

hungwindow (QM 2.3.0) With key and clipboard functions, when the active window is hung. While the window is hung, waits and shows a message box with Abort and Ignore buttons. On Abort the macro would end (error). On Ignore the macro would continue (don't wait).

Don't show a message box.

 

1 - wait indefinitely while the window is hung.

 

2 - abort. Same as if the user would click Abort.

 

3 - ignore. Same as if the user would click Ignore.

keychar

(QM 2.3.3)

With key, when using "text" or string variable. Use to type exact text.

Send normal keys. The active window receives WM_KEYx messages with usual virtual-key codes. In some rare conditions the typed text may be not exactly the same as in macro, because it depends on keyboard state. Send keys as characters. The active window receives WM_KEYx messages where virtual-key code is VK_PACKET. The typed text will always be as in macro. However in some windows it may not work.

nowarnings

(QM 2.3.3)

On run-time warning. Warnings can be generated by some QM functions and user-defined functions (end). Show warnings. 1 - don't show warnings.

nowarningshere

(QM 2.3.5)

On run-time warning. Show warnings as usually. 1 - pass warnings to the caller. In warning text will be a link to the caller, not to this function.

noerrorshere

(QM 2.3.5)

On run-time error. Show errors as usually.

1 - pass errors to the caller. Unhandled errors will be in the caller, not in current function.

 

This option works only if there is direct caller.

 

Other way to pass errors to the caller - handle errors with err and rethrow with end: err+ end _error. Can be used in all QM versions.

 

Remarks

Syntax1: Changes a run-time option locally (only for current instance of running function or macro).

 

If used as function, opt is identical to getopt (returns current value).

 

Initially all options are 0, except keymark in autotexts. Some initial options can be changed with RtOptions.

 

opt waitmsg 1 should be used if you use wait commands (explicit or implicit, e.g. autodelay or clipboard commands) in thread (running macro) that has a window (or dialog). While waiting, window must process messages. Without this option, it cannot process messages. This causes various anomalies, such as window not responding, etc. This option also is often necessary when working with COM, especially with events.

 

Macros that contain opt waitcpu 1 sometimes may run very slowly, because some programs constantly use CPU. To see CPU usage, use Windows Task Manager or perfmon.exe. You can also use GetCPU function.

 

About opt keymark 1: For keyboard triggers and some other features, QM uses keyboard hooks to intercept keyboard events. QM processes QM-pressed (injected) keys differently than user-pressed (real) keys. For example, a macro cannot trigger a hotkey macro using the key command. However, when the user presses or releases a key simultaneously with the key command, QM processes the key event like generated by the key command (there is no reliable way to distinguish real and injected keys, unless you use low level hook). If it is a trigger-key, the trigger will not work. If it is a wait-key (wait 0 K), the macro will not stop waiting. Also, user-pressed keys may be inserted (typed) between QM-pressed keys. There are two ways to avoid all these problems: 1. Use low level keyboard hook. 2. Insert opt keymark 1 before key. However then in some windows some keys may not work as expected. When using low level keyboard hook, opt keymark 1 does not change anything (everything works well with or without it).

 

QM 2.4.1. Added Syntax2 for saving/restoring current opt and spe settings:

 

QM 2.4.3. Disabled opt end. Not error if used, but now it does nothing.

 

See also: getopt, RtOptions, err, end, Errors, wait, wait for, key, paste, str.getsel.

 

Examples

 set local run-time option "search hidden windows"
opt hidden 1

 save/change/restore local run-time options
opt save
opt slowkeys 1; spe 10
out "%i %i" getopt(slowkeys) spe
opt restore
out "%i %i" getopt(slowkeys) spe