#2576 Cannot replace [selection handle] command

obsolete: 8.6b2
open
5
2012-07-12
2008-12-17
Andy Goth
No

% package require Tk
% proc report {string args} {return $string}
% selection handle . {report 1}
% selection own .
% selection get
1
% selection get -type UTF8_STRING
1
% selection handle . {report 2}
% selection get
2
% selection get -type UTF8_STRING
1

When replacing the [selection handle] command, the automatically generated UTF8_STRING handler is *not* updated, only the STRING handler. The attached patch fixes Tk_CreateSelHandler() to update both. It also updates the Tk_CreateSelHandler() documentation to describe the automatic UTF8_STRING handler creation, updating, and removal. I tested the patch successfully on X11.

Workaround 1: Use [selection handle -type UTF8_STRING] to explicitly set the UTF8_STRING handler in addition to the STRING handler.
Workaround 2: Use [selection handle $win ""] to clear the handler before changing it.

Discussion

1 2 > >> (Page 1 of 2)
  • Andy Goth

    Andy Goth - 2009-01-06

    Tiny amendment to the patch: Replace "but" with "that" in the line "existing STRING handler is also being replaced but has a different" in the patch for doc/CrtSelHdlr.3 .

     
  • Donal K. Fellows

    It would be nice to be able to do this.

     
  • Donal K. Fellows

    • priority: 5 --> 8
     
  • Andy Goth

    Andy Goth - 2011-04-18

    I fixed some typos in the patch.

     
  • Andy Goth

    Andy Goth - 2012-06-08

    This has been hanging out for three to four years. Please, somebody have a look at it. I still need to manually apply this patch to get my application to work.

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-09

    committed to branch bug-2443069

    Looks good to me. The only problem with the
    patch is that it causes two test failures (see below),
    so those have to be fixed first before it can
    be merged to trunk.

    ==== clipboard-5.1 Tk_ClipboardClear procedure FAILED
    ==== Contents of test case:

    clipboard append -t TEST "test"
    set result [lsort [clipboard get TARGETS]]
    clipboard clear
    list $result [lsort [clipboard get TARGETS]]

    ---- Result was:
    {MULTIPLE TARGETS TEST TIMESTAMP TK_APPLICATION TK_WINDOW UTF8_STRING} {MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW UTF8_STRING}
    ---- Result should have been (exact matching):
    {MULTIPLE TARGETS TEST TIMESTAMP TK_APPLICATION TK_WINDOW} {MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW}
    ==== clipboard-5.1 FAILED

    ==== clipboard-5.2 Tk_ClipboardClear procedure FAILED
    ==== Contents of test case:

    clipboard append -t TEST "test"
    set result [lsort [clipboard get TARGETS]]
    selection own -s CLIPBOARD .
    lappend result [lsort [clipboard get TARGETS]]
    clipboard clear
    clipboard append -t TEST "test"
    lappend result [lsort [clipboard get TARGETS]]

    ---- Result was:
    MULTIPLE TARGETS TEST TIMESTAMP TK_APPLICATION TK_WINDOW UTF8_STRING {MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW} {MULTIPLE TARGETS TEST TIMESTAMP TK_APPLICATION TK_WINDOW UTF8_STRING}
    ---- Result should have been (exact matching):
    MULTIPLE TARGETS TEST TIMESTAMP TK_APPLICATION TK_WINDOW {MULTIPLE TARGETS TIMESTAMP TK_APPLICATION TK_WINDOW} {MULTIPLE TARGETS TEST TIMESTAMP TK_APPLICATION TK_WINDOW}
    ==== clipboard-5.2 FAILED

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-09
    • assigned_to: hobbs --> nijtmans
     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-09
    • milestone: 874758 --> obsolete: 8.6b2
     
  • Donal K. Fellows

    Those tests look like bystanders, with the thing tested for (equality of target list) being a proxy for what is interesting (TEST present in target list or not). Just update the expected test results. :-)

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-10

    Donal, Thanks! I believe you. (personally, I never used the
    selection function, so I don't consider myself an expert in this)

    So, after doing what Donal suggests, there is one more
    failure:
    ==== select-5.15 Tk_GetSelection procedure FAILED
    ==== Contents of test case:

    proc ::bgerror msg {lappend ::bgerrors $msg}
    selection handle .f1 ERROR errHandler
    list [catch {selection get ERROR} msg] $msg [update] {*}$::bgerrors

    ---- Result was:
    1 {PRIMARY selection doesn't exist or form "ERROR" not defined} {}
    ---- Result should have been (exact matching):
    1 {PRIMARY selection doesn't exist or form "ERROR" not defined} {} {selection handler aborted}
    ==== select-5.15 FAILED

    What should be done about this one?

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-20
    • priority: 8 --> 5
     
  • Andy Goth

    Andy Goth - 2012-06-20

    I don't understand it all that well, but it looks very fishy to me. Take this line:

    selection handle .f1 ERROR errHandler

    The man page says:

    selection handle ?-selection s? ?-type t? ?-format f? window command

    I see no -selection, -type, or -format options, so .f1 is window and... well, what's ERROR supposed to be? The intended command is [errHandler], since that generates the expected output string. Maybe ERROR should be the value for the -type option, but that's a guess; wouldn't that also cause the result to *not* include an error about ERROR not being defined? I'm not sure why this test ever worked, why my patch broke it, or what it's even trying to accomplish.

    Some of the other tests contain this same [selection handle] line, though select-5.15 is the only one that tests for the "selection handler aborted" failure, so if this one line of code is faulty, it'll likely only matter for select-5.15.

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-26

    It turns out that test select-5.15 is already failing for
    ages (why did no-one notice that before....). This
    test was written to test for bug 2441988, so I
    re-opened that one.
    Conclusion: the failure of select-5.15 has nothing
    to do with Andy's [selection handle] changes.

    See:
    <http://core.tcl.tk/tk/info/bd1165a06d17b3df426b97cda3e7df675656a81e>

    Donal, it appears that you know a lot more about
    selection handles than I do. If you are OK with
    merging this with trunk, I am as well. It's too
    small to let it go though the TIP process.

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-06-26
    • assigned_to: nijtmans --> dkf
    • status: open --> open-fixed
     
  • Donal K. Fellows

    Tk doesn't get tested nearly as often as Tcl does, because it's entirely practical to do a run of Tcl's test suite in parallel with something else (only async.test is intrusive at all on this system). Tk's test suite is far less of a good neighbor (for good and obvious reasons). It's also too dependent on the fonts installed and the way the window manager behaves.

     
  • Donal K. Fellows

    Digging with 'fossil annotate' indicates that the provenance of that weird [selection] syntax is "the mists of time"; it predates Tk's switch to CVS. In fact, it probably predates Tk 4.0, as I don't ever remember seeing that syntax documented *anywhere* in all the years I've used it. I also don't *think* it is mentioned in the 1st ed Ousterhout book; it's **OLD**.

    I guess that:
    selection handle .f1 ERROR errHandler
    is equivalent to:
    selection handle .f1 -type ERROR errHandler
    (That is, it's the PRIMARY selection's ERROR target fetched in STRING wire format.)

     
  • Donal K. Fellows

    And the minimal fix is to update the expected output to the real output; it's correct. We're just no longer throwing that information away completely and leaving bugs to fester.

    OSX/Aqua has a *lot* more failing tests. Don't know the significance yet.

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-07-01

    >And the minimal fix is to update the expected output to the real output;
    I don't agree. It appears that switching the "selection handle"
    command to the new synax (see bug #2441988) fixes the
    bug as well, with the output as expected.

    updated bug-2443069 to trunk now, which makes all
    select/clipboard-related test pass.

    To me it's OK to be merged to trunk, I'm convinced.

    Donal?

     
  • Donal K. Fellows

    • status: open-fixed --> closed-fixed
     
  • Donal K. Fellows

    • status: closed-fixed --> open-fixed
     
  • Jan Nijtmans

    Jan Nijtmans - 2012-07-05

    Ping!

    With everything sorted out, what's left to be
    done, apart from merging this to trunk?

     
  • Donal K. Fellows

    Whoops; meant to mention before that merging is the task that's left. :-)

     
  • Jan Nijtmans

    Jan Nijtmans - 2012-07-11
    • status: open-fixed --> pending-fixed
     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks