This is definitely NOT a dumb question. It's new syntax as of 0.96.0 and I don't know the answer.

Someone will have to add an example here once we get it to work.

IDK the codebase very well, but This is the API doc

def send_keys(self, key_string, send_mode: typing.Union[
        autokey.model.phrase.SendMode, int] = autokey.model.phrase.SendMode.KEYBOARD):

I found this in phrase.py

class SendMode(enum.Enum):
    """
    Enumeration class for phrase send modes

    KEYBOARD: Send using key events
    CB_CTRL_V: Send via clipboard and paste with Ctrl+v
    CB_CTRL_SHIFT_V: Send via clipboard and paste with Ctrl+Shift+v
    SELECTION: Send via X selection and paste with middle mouse button
    """
    KEYBOARD = "kb"
    CB_CTRL_V = Key.CONTROL + "+v"
    CB_CTRL_SHIFT_V = Key.CONTROL + "+" + Key.SHIFT + "+v"
    CB_SHIFT_INSERT = Key.SHIFT + "+" + Key.INSERT
    SELECTION = None


SEND_MODES = {
    "Keyboard": SendMode.KEYBOARD,
    "Clipboard (Ctrl+V)": SendMode.CB_CTRL_V,
    "Clipboard (Ctrl+Shift+V)": SendMode.CB_CTRL_SHIFT_V,
    "Clipboard (Shift+Insert)": SendMode.CB_SHIFT_INSERT,
    "Mouse Selection": SendMode.SELECTION
}  # type: typing.Dict[str, SendMode]

It looks like those may be integers from 0..4 or 1..5 representing the mode you want to use as listed above. It depends on whether a Python enum is zero- or one-based.

As far as the complaint about number of arguments, I'm guessing that send mode has to be a keyword=value parameter, not just a value.

I'm a Python newbie. Someone who actually knows Python will have to clarify this, but until they do, you can try some integer values like SendMode=1 or SendMode=KEYBOARD and see what happens.

My failed attempts:

All efforts to add an argument to keyboard.send_keys() fail here:

keyboard.send_keys("foo", SendMode=1) # TypeError: Keyboard.send_keys() got an unexpected keyword argument 'SendMode'

and:

keyboard.send_keys("foo", send_mode=1) # TypeError: Keyboard.send_keys() got an unexpected keyword argument 'send_mode'

and:

keyboard.send_keys("foo", 1) # TypeError: Keyboard.send_keys() takes 2 positional arguments but 3 were given

and:

keyboard.send_keys("foo", send_mode=engine.SendMode.CB_SHIFT_INSERT) # AttributeError: 'Engine' object has no attribute 'SendMode'

and:

keyboard.send_keys("foo", send_mode=engine.send_mode.CB_SHIFT_INSERT) # AttributeError: 'Engine' object has no attribute 'send_mode'

Best guess:

I believe this is a documentation error rather than a new feature.

Possible explanation:

@josephj11 is right that it comes from the phrase.py file. The keyboard.send_keys() API call takes only two positional arguments. Since send_keys is a method in the keyboard instance of the Keyboard class, the first one is self. The second one is the string you're sending ("foo" in my examples above). If it's given a third argument, it will fall over every time.

I believe that the send_mode argument is handled internally by AutoKey. Specifically, by the value given to SendMode in the engine.py file after it fetches it from the phrase.py file, which provides either its default KEYBOARD setting or the choice that you made when you created a phrase and configured it to use the clipboard or the keyboard in the phrase settings beneath the phrase window in the AutoKey GUI.

Possible work-around 1:

Pick one:

• Send with the keyboard:

  keyboard.send_keys(clipboard.get_clipboard())

• Send with the clipboard:

  keyboard.send_keys(clipboard.get_clipboard())

Possible work-around 2:

1. Create a phrase.
2. Configure the phrase to use the clipboard or the keyboard in the phrase settings beneath the phrase window.
3. Run the phrase from a script.

Possible work-around 3:

1. Create a phrase.
2. Configure the phrase to use the clipboard or the keyboard in the phrase settings beneath the phrase window.
3. Run the phrase instead of a script.

I created an issue for it in the documentation repository.

@Elliria I distinctly remember this being added as a feature, possibly by @BlueDrink9 . If it doesn't work or we can't figure out how to invoke it, it's a bug.

Ah, okay. In that case, I changed the tag from documentation to bug for this discussion and I'll close the PR I created in the documentation repository for it. This should probably get turned into an issue.

@Elliria Until now, we haven't been labelling discussions. It's fine if you want to though.