Menu

#11 merge window issues TK errors !

V5.5.3
closed
merge (1)
1
2022-11-09
2022-10-30
shraga
No

Ever since 5.5 I am having trouble with merge.
Failing version: 5.5.3
last verison worked fine: 5.4

When doing "show merge window" I get a TK error window. After closing the window, it reappers onevery merge operation (next/previous...).

This is the error message:

cat tkdiff.log
expected floating-point number but got "0.0074731794669007125.0"
expected floating-point number but got "0.0074731794669007125.0"
while executing
"$Real $cmd {*}$args"
("default" arm line 4)
invoked from within
"switch -glob $cmd {
ALLOW { if {$a1 == "see" && $a2 in {1 0}} {
# Fictitious command "ALLOW"s widget to permit 1 'see' to WORK..."
(procedure ".merge.top.text" line 28)
invoked from within
"$w(mergeText) yview moveto [expr {($firstline + $difflines / 2) / $totallines - $ywindow / 2}].0"
(procedure "merge-center" line 21)
invoked from within
"merge-center "
(procedure "do-show-merge" line 19)
invoked from within
"do-show-merge 1"
invoked from within
".#menubar.#menubar#merge invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 50)
invoked from within
"tk::MenuInvoke .#menubar.#menubar#merge 1"
(command bound to event)

Discussion

  • michael-m

    michael-m - 2022-10-30
    • status: open --> accepted
    • assigned_to: michael-m
     
  • michael-m

    michael-m - 2022-10-30

    Hmmm. That's not good at all.
    I was able to duplicate the problem (a GOOD thing) and after a QUICK look at the error message, I can see WHY it complains (0.12345.0 is NOT a well formed number). Now all that's required is to find what allowed that to happen. Off the top of my head it LOOKS like some equation was EXPECTED to return an integer - but DIDN'T; I just have to find out why! Sounds easy.... we will see....standby...
    P.S. - probably should have been written as a BUG ticket (Support is more for questions about operations than hard errors) - but nevertheless, I am on it!

     
  • michael-m

    michael-m - 2022-10-30

    Mostly good news.
    It definitely is a INTEGER .vs. REAL problem, but it was introduced IN V5.4 (which you reported as working). It appears it was intended to fix the very problem that is now occurring, but failed because it was applied in an incorrect physical location. That it worked (for you) is likely why it worked for me when it was originally fixed - purely on the inconsistencies of data used to test. Just need to reposition the fix properly and push it out the door. Thanks for bringing it to our attention.

     
  • michael-m

    michael-m - 2022-11-09
    • status: accepted --> closed
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.