Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Win32::GUI::Richedit strange results for deselecting a selection

by tomsell (Acolyte)
on Feb 06, 2013 at 19:24 UTC ( #1017490=perlquestion: print w/ replies, xml ) Need Help??
tomsell has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

I wonder if people could confirm an observation I made when interacting with a Win32::GUI::Richedit control.

To deselect selected text, one can click outside of the selection or within the selection. Strangely though, a handler for the MouseUp event will see different values when querying the Richedit control upon clicking the control:

  • outside of the selected text: selection start and end are the same, ie. an insertion point, which is OK.

  • within the selection: although the text ist deselected, querying the control still returns the values of the old selection, which is NOT OK!

Note that the Textfield control behaves correctly.

Here's the runnable code for Richedit and Textfield which prints to STDERR

use Win32::GUI(); my $mw = Win32::GUI::Window->new(-title => "Richedit / Textfield desel +ecting differences", -size => [500,200]); my $re = $mw->AddRichEdit(-name => "re", -pos => [0,0], -size => [500 +, 100], -text => "RichEdit\r\ndouble click to select, then single cli +ck _outside of_ selection: \$start == \$end,\r\ndouble click to selec +t, then single-click _within_ selection: \$start != \$end"); my $tf = $mw->AddTextfield(-name => "tf", -pos => [0,101], -size => [ +500, 99], -text => "Textfield\r\ndouble click to select, then single +click _outside of_ selection: \$start == \$end,\r\ndouble click to se +lect, then single-click _within_ selection: \$start == \$end", -multi +line => 1); $mw->Show(); Win32::GUI::Dialog(); exit(0); sub re_MouseUp { my ($start, $end) = $re->GetSel(); print STDERR "RichEdit MouseUp selection: $start, $end\n"; 1; } sub tf_MouseUp { my ($start, $end) = $tf->GetSel(); print STDERR "TextField MouseUp selection: $start, $end\n"; 1; }

Background to this: I'd like to to enable/disable a "Copy Selected Text" toolbar button based on the presence of selected text. Is this the right approach or might there be a workaround for the RichEdit behaviour?

Comment on Win32::GUI::Richedit strange results for deselecting a selection
Download Code
Re: Win32::GUI::Richedit strange results for deselecting a selection (events)
by Anonymous Monk on Feb 07, 2013 at 08:56 UTC

    within the selection: although the text ist deselected, querying the control still returns the values of the old selection, which is NOT OK!

    I see that too, but it doesn't seem to strange to me, since your mouse handler (callback) is being called before the selection change is registered, before the selection range is updated, before the selchange event is generated

    You should be binding to a "SelChange" event , but you can't
    Rich Edit (Windows)
    EN_SELCHANGE notification code (Windows)
    I would use Wx

      (just now came across my post through a Google search, ... here's the solution for completeness sake)

      "SelChange" event: quite right! That's what hooks are for.

      $myRichEdit->Hook(EN_SELCHANGE, \&SelChangeEvents_Handler); sub SelChangeEvents_Handler { my ($object, $wParam, $lParam, $type, $msgcode) = @_; return unless($type == WM_NOTIFY); return unless($msgcode == EN_SELCHANGE); my ($hwndFrom, $idFrom, $code, $cpMin, $cpMax, $seltyp) = unpack("LLLLLL", unpack("P24", pack("L", $lParam))); return unless($hwndFrom == $object->{-handle}); my $haveSelection = ($cpMin != $cpMax); if($haveSelection){ print STDERR " we have a selection!"; } }
Re: Win32::GUI::Richedit strange results for deselecting a selection
by Athanasius (Monsignor) on Feb 07, 2013 at 14:37 UTC

    I suspect that Anonymous Monk’s reply is the best advice. However, if you need to persevere with Win32::GUI, the following strategy might provide an acceptable workaround:

    • Create an additional read-only text box to display the text selected in the RichEdit control (by calling $re->GetSelText()).
    • Update this on every MouseUp event.
    • Also provide a “Cancel” button to allow the user to set the RichEdit control text selection to the empty string.
    • When the “Cancel” button is pressed, blank-out the read-only text box and reset the RichEdit control.
    • Implement the “Copy Selected Text” button as originally intended.

    The advantage is that the user can see the current selection, so knows when it’s necessary to press the “Cancel” button. The main disadvantage is the provision of an extra widget.

    I haven’t attempted to implement this idea. Just a thought, and I hope it helps,

    Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

      the following strategy might provide an acceptable workaround

      Or patch Richedit.xs so selchange works :)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1017490]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2014-12-21 01:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (101 votes), past polls