Nп/п : 28 из 100
 От   : et99                                2:5075/128        04 сен 23 14:59:55
 К    : All                                                   04 сен 23 01:01:04
 Тема : small inconsistencies in the 3 texting widgets
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 1@dont-email.me> d0760fd2
@REPLYADDR et99 <et99@rocketship1.me>
@REPLYTO 2:5075/128 et99
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@TZUTC: -0700
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.6.1
@TID: FIDOGATE-5.12-ge4e8b94
 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
 which results in calls to several different procs.

 Note that more specific bindings, such as  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

 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.6.1
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх