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

[tomsell]

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?

[Anonymous Monk]

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

[tomsell]

(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!";
    }
}

[Athanasius]

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,

[Anonymous Monk]

the following strategy might provide an acceptable workaround

Or patch Richedit.xs so selchange works :)