Page 1 of 2

ScaleRichView caret visibility problem BCB2007 Win7

Posted: Sun Jan 10, 2010 12:29 pm
by theAntiELVIS
USING: Unregistered RichView v. 12, RichView Actions, ScaledRichView, etc. with Embarcadero C++ Builder 2007 Professional and Windows 7

I have the unregistered version of ScaleRichView on a form, but the caret only blinks (one blink) when the cursor enters/hovers over an active control - a toolbar button or scrollbar arrow, for example. The caret is set to be visible with blink rate = 500 (all default when dropped on a form).

I have tried to explicitly call Focussed() on the ScaleRichEdit, ShowCaret() on the form handle, the ScaleRichEdit handle, and the internal RichViewEditor handle. I've tried to explicitly call Format() - but the behavior is always the same, just ONE blink when the mouse enters an active control, or clicks the ScaleRichEdit. But there is never a continuously blinking caret.

I've started to wonder if this is some kind of limitation of the unregistered version?

Posted: Mon Jan 11, 2010 5:56 pm
by Sergey Tkachenko
Does this problem occurs with the compiled demo
( http://www.trichview.com/resources/acti ... ontest.zip )?

Posted: Mon Jan 11, 2010 6:24 pm
by theAntiELVIS
The FIRST time I ran the demo I had the same problem - the caret is only visible for a blink or two when the mouse cursor passes over or hovers on an active control.

BUT - the next five times I ran the demo the caret worked correctly!

Unfortunately my application (which at this point is very similar to your demo - just a scaled rich view, external RVStyle, two rulers, and toolbars hooked to RVActions) always fails.

Also any test I build fails (create a new Windows Forms app, drop a scaled rich view and run under debug or release - same peoblem with the caret)

If I build a test with just a "standard" TRichViewEdit the caret behaves correctly - it only seems to be a problem with ScaledRichView.

Remember this is C++ Builder 2007, under Windows 7 64-bit.

Posted: Mon Jan 11, 2010 6:47 pm
by theAntiELVIS
Ahhhh - I just gave your demo another five runs - the caret problem happened on every one of them.

This is really strange - it must be something here on my machine taht causes such an unpredictable problem with the demo, but a consistent one with my app - unless it has to do with the demo being built with the registered version?

I need to find a machine that doesn't have Windows 7 and see what happens there....

Posted: Mon Jan 18, 2010 1:00 pm
by theAntiELVIS
Okay - Scale Rich View DOES NOT play nice with Aero. If I select Properties on the app icon and check "Disable Desktop Composition" on the "Compatibility" tab, Aero is shut down when the app runs and the caret works normally.

A bummer - but not a show-stopper.

Posted: Mon Jan 18, 2010 7:27 pm
by Sergey Tkachenko
We will check this problem as soon as we get Win7.

Posted: Thu Apr 29, 2010 7:32 pm
by EvRenesse
Hi,

is this problem under investigation? I have the same problem using ScaleRichView 3.1.1. I hope, you got Windows 7 in the meantime. I cannot implement this component, if it is not compatible with the current Windows version.

Ekkehart v. Renesse

Posted: Thu Apr 29, 2010 8:01 pm
by Sergey Tkachenko
Yes, we tested it with Windows 7, however we cannot reproduce this problem.
Does it occur under some specific settings, or with the default settings?

Posted: Fri Apr 30, 2010 8:28 am
by EvRenesse
Hi,

now i tested again with the following configuration:

Windows 7 Home Premium (German edition, 32 bit). I created a new user account to ensure the default settings. Design: Aero "Windows 7". 96 dpi.

ScaleRichView application: I used your demo application PM_StretchToFit from ScaleRichView 3.1.1, compiled under Windows XP SP3, Delphi 2006 for Win32.

Starting the application, in the left editor window the caret appears only one single time. When entering text, the caret appears one single time just after entering each letter. Additionally, the caret appears one single time at each mouse click inside the editor. When entering letters or clicking with the mouse quickly, the caret appears in the same frequency, that means, the following trigger passes the previous trigger; this is the standard behaviour, but the repeating is missing.

When clicking another component outside the editor, the caret appears one single time too. For example, first entering text in the editor, and following a click on the Landscape radio button, the caret appears one single time. Clicking in the editor, the caret appears one single time. Then clicking the Portrait radio button, the caret appears one single time again.

Just as theAntiELVIS wrote in January, the error does not occur if the design Basic is used, for eample by changing the design in the control panel or by changing the properties of the application icon on the compatibility tab.

Additionally i tested under Windows 7 Home Premium 64 bit: The same result.

Any idea, how to get it running well?

Ekkehart v. Renesse

Posted: Fri Apr 30, 2010 12:34 pm
by Sergey Tkachenko
I still cannot reproduce the problem (using Win7 32bit Prof).
We will prepare some tests.

Posted: Sat May 01, 2010 2:45 pm
by EvRenesse
Hi,

maybe i found a possible solution for this problem:

In this procedure

Code: Select all

procedure TSRichViewEdit.UpdateCaret(LockRepaint: Boolean; PaintRect : TRect);
.....
      // paint rectangle
      if (FActiveEditor.TopLevelEditor.Focused) or (ScrollBarH.Focused) or
        (ScrollBarV.Focused) then
        if not (FViewProperty.FShowScrollHint and fHintScroll) then
        begin

//Repaint;
//Refresh;
Invalidate; // <<<------------ Repaint OR Refresh OR Invalidate helps

          Canvas.MoveTo(p.X, p.y);
          Canvas.LineTo(p.X, p.y + dY);

//Repaint; // <<<------------ In this psoition it does NOT help
//Refresh;

        end;
.....
end;
i inserted Repaint OR Refresh OR Invalidate before calling MoveTo/LineTo. With this, the caret is blinking permanently also under Windows 7.

Calling Repaint OR Refresh after calling MoveTo/LineTo does not help.

Please check this solution. Maybe a condition "if Windows 7..." might be necessary.

Ekkehart v. Renesse

Posted: Sat May 15, 2010 5:15 am
by proxy3d
Check the new version of the SRV 3.2

Posted: Sat May 15, 2010 4:37 pm
by EvRenesse
Hi,

thanks for the new version. Unfortunately, the caret problem under Windows 7 is not solved.

I tried my solution (Invalidate) again, but now it does not help any more. Even under Windows XP, this Invalidate causes the caret to disappear under all circumstances.

May be, i have to reinstall the old versions later, but now i can spend some time to wait for your instructions for further tests.

Ekkehart v. Renesse

Posted: Sat May 15, 2010 7:30 pm
by Sergey Tkachenko
Try calling Update instead of Invalidate.

Posted: Sun May 16, 2010 8:53 am
by EvRenesse
Hi,

calling Update doesn't help. I tested Invalidate, Update, Refresh and Repaint in 4 different positions A..D in the code of TSRichViewEdit.UpdateCaret:

Code: Select all

...
  if not(ReadOnly and (rvoHideReadOnlyCaret in RVEditorOptions)) and FCaretVisible then
    if IntersectRect(tmp, Bounds(p.x, p.y, CaretBitmap.Width, FCaretHeight), PaintRect) and
       fShowCaret and ShowCaret then
    begin
      Canvas.Brush.Color := FPageProperty.FCaretPen.Color;
      // remember old background
      CaretRect := Rect(p.X - FPageProperty.FCaretPen.Width, p.y,
        p.X + FPageProperty.FCaretPen.Width,
        p.y + dY + FPageProperty.FCaretPen.Width);
      CaretBitmap.Canvas.CopyRect(Rect(0, 0,
        FPageProperty.FCaretPen.Width shl 1,
        dY + FPageProperty.FCaretPen.Width),
        Canvas, CaretRect);
      // paint new background
      Canvas.Brush.Color := FPageProperty.FCaretPen.Color;
      Canvas.Pen.Assign(FPageProperty.FCaretPen);
      // paint rectangle
      if (FActiveEditor.TopLevelEditor.Focused) or (ScrollBarH.Focused) or
        (ScrollBarV.Focused) then
        if not (FViewProperty.FShowScrollHint and fHintScroll) then
        begin

// Position A:
//Invalidate;
//Update;
//Refresh;
//Repaint;  

          Canvas.MoveTo(p.X, p.y);
          Canvas.LineTo(p.X, p.y + dY);

// Position B:
//Invalidate;
//Update;
//Refresh;
//Repaint;

        end;
    end
    else
      // restore background

// Position C:
//Invalidate;
//Update;
//Refresh;
//Repaint;

      Canvas.CopyRect(CaretRect, CaretBitmap.Canvas,
        Rect(0, 0,
        CaretRect.Right - CaretRect.Left,
        CaretRect.Bottom - CaretRect.Top));

// Position D:
//Invalidate;
//Update;
//Refresh;
//Repaint;

  fBusyCaret := FALSE;
Results for Windows XP:
Invalidate: A, B, C, D nok (not ok).
Update: A, B, D: ok, C nok.
Refresh: A ok, B, C, D nok.
Repaint: A ok, B, C, D nok.

Results for Windows 7:
Invalidate: A, B, C, D nok.
Update: A, B, C, D nok.
Refresh: A ok, B, C, D nok.
Repaint: A ok, B, C, D nok.

I don't know the code changes you implemented since previous version, but may be, this results will help you a little bit. It is very confusing, that the caret problem under Windows 7 doesn't appear on all machines. I have two machines running Windows 7, and only one machine shows the problem; this machine has installes both Windows 7 32 bit and 64 bit, and both with the caret problem.

Now i can use Repaint in position A. If you want further tests, please let me know.

Ekkehart v. Renesse