1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • small inconsistencies in the 3 texting widgets

    From et99@21:1/5 to All on Mon Sep 4 14:59:55 2023
    In the below examples, I am wondering if this is a Tk bug, or a user bug. One could argue that a programmer should not (by program) create a selection where the cursor is not also placed in or adjacent to the selection. So, I'm wondering if a ticket
    should be created for this.

    Each of the 3 texting widgets,

    entry
    ttk::entry
    text

    say in the manual:

    "If any normal printing characters are typed (in an entry), they are inserted at the point of the insertion cursor."


    However, this is not always the case. The below 5 example programs demonstrate that when the program creates a selection, moves the insertion cursor outside the selection (or just leaves it where it was), and gives focus to the widget, typed characters (
    e.g. 123) will sometimes replace the selection, and sometimes not. If it replaces the selection, the inserted characters are not where the cursor was.

    Note that interactive selections (user does the selection, not the program) don't apply since the cursor will always end up adjacent to the selection. I believe this is why this behavior may not have been noticed before.

    The reason for these behaviors can be seen in the binding for <Key> which results in calls to several different procs.

    Note that more specific bindings, such as <Key-BackSpace> take precedence and also have inconsistent results. The 2 entry's will delete the selection, but in ttk::entry the cursor is also moved. In text, it will delete 1 char at a time until it gets to
    the selection. Then it deletes the entire selection. However, the manual for text says:

    "Backspace and Control-h delete the selection, if there is one in the widget. If there is no selection, they delete the character to the left of the insertion cursor."

    And in addition, Control-h never deletes the full selection only 1 character at a time.

    Examples (run each separately - I paste them into a windows console or rlwrap of wish):

    ttk::entry .te -textvariable tevar ;# will delete selection
    pack .te
    set tevar "abc def ghi"
    .te selection range 0 3
    .te icursor end
    focus -force .te

    entry .te -textvariable tevar ;# will not delete selection
    pack .te
    set tevar "abc def ghi"
    .te selection range 0 3
    .te icursor end
    focus -force .te

    entry .te -textvariable tevar ;# will delete selection
    pack .te
    set tevar "abc def ghi"
    .te selection range 0 3
    .te icursor 0
    focus -force .te

    text .t ;# will not delete selection
    pack .t
    .t insert 0.0 "abc def ghi"
    .t tag add sel 1.0 1.3
    .t mark set insert end
    focus -force .t

    text .t ;# will delete selection
    pack .t
    .t insert 0.0 "abc def ghi"
    .t tag add sel 1.0 1.3
    .t mark set insert 1.3
    focus -force .t

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Wed Sep 6 19:52:05 2023
    Am 04.09.2023 um 23:59 schrieb et99:
    In the below examples, I am wondering if this is a Tk bug, or a user
    bug. One could argue that a programmer should not (by program) create a selection where the cursor is not also placed in or adjacent to the selection. So, I'm wondering if a ticket should be created for this.

    Each of the 3 texting widgets,

    entry
    ttk::entry
    text

    say in the manual:

    "If any normal printing characters are typed (in an entry), they are
    inserted at the point of the insertion cursor."


    However, this is not always the case. The below 5 example programs demonstrate that when the program creates a selection, moves the
    insertion cursor outside the selection (or just leaves it where it was),
    and gives focus to the widget, typed characters (e.g. 123) will
    sometimes replace the selection, and sometimes not. If it replaces the selection, the inserted characters are not where the cursor was.

    Note that interactive selections (user does the selection, not the
    program) don't apply since the cursor will always end up adjacent to the selection.  I believe this is why this behavior may not have been
    noticed before.

    The reason for these behaviors can be seen in the binding for <Key>
    which results in calls to several different procs.

    Note that more specific bindings, such as <Key-BackSpace> take
    precedence and also have inconsistent results. The 2 entry's will delete
    the selection, but in ttk::entry the cursor is also moved. In text, it
    will delete 1 char at a time until it gets to the selection. Then it
    deletes the entire selection. However, the manual for text says:

    "Backspace and Control-h delete the selection, if there is one in the
    widget. If there is no selection, they delete the character to the left
    of the insertion cursor."

    And in addition, Control-h never deletes the full selection only 1
    character at a time.

    Examples (run each separately - I paste them into a windows console or
    rlwrap of wish):

    ttk::entry .te -textvariable tevar ;# will delete selection
    pack .te
    set tevar "abc def ghi"
    .te selection range 0 3
    .te icursor end
    focus -force .te

    entry .te -textvariable tevar ;# will not delete selection
    pack .te
    set tevar "abc def ghi"
    .te selection range 0 3
    .te icursor end
    focus -force .te

    entry .te -textvariable tevar ;# will delete selection
    pack .te
    set tevar "abc def ghi"
    .te selection range 0 3
    .te icursor 0
    focus -force .te

    text .t ;# will not delete selection
    pack .t
    .t insert 0.0 "abc def ghi"
    .t tag add sel 1.0 1.3
    .t mark set insert end
    focus -force .t

    text .t ;# will delete selection
    pack .t
    .t insert 0.0 "abc def ghi"
    .t tag add sel 1.0 1.3
    .t mark set insert 1.3
    focus -force .t


    Thank you, Eric, for the great analysis.
    Test hint: past the test scripts for setup and then press:
    - a key
    or backspace
    or ctrl-backspace

    Could you open a bug report for this?
    At least, the documentation may be changed.
    And a unified approach for all entry widgets would be great.

    Take care,
    Harald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)