[HeDiBo]

The OnValidateError event is thrown twice.
Once in this:

procedure TsCustomNumEdit.CMExit(var Message: TCMExit);
begin
  try
    CheckRange;
    UpdateData;
  except

and immediately after that in here:

procedure TsCustomNumEdit.UpdateData;
var
  s: string;
  Minus: integer;
begin
  s := Text;
  if pos(CharMinus, s) = 1 then begin
    Delete(s, 1, 1);
    Minus := -1
  end
  else
    Minus := 1;

  FValue := CheckValue(StrToFloat(TextToValText(ZeroChar + s)) * Minus);
end;

Maybe the CheckRange in CMExit should go?

[HeDiBo]

Timing is only a big problem if HandleDisabledCtrls is True.
Especially the timing problem shown at #69251 goes away if this property is set to False.

[HeDiBo]

Changing the code to:

    Manager.KillTimer;
    if Manager.Active then
      Text := AHint
    else
      Caption := AHint;
(****** DB ********)
    Application.ProcessMessages; // Patch for refresh of columns in cxGrid
(******************)

seems to circumvent the AV.
But as I said, Application.ProcessMessages may cause all kind of problems.

[HeDiBo]

I found a way to prevent the bug. The bug stays I think, but it is not visible anymore.

In acAlphaHints is a procedure TacCustomHintWindow.ActivateHint. On roughly 1/3 of its code, I found:

    Manager.KillTimer;
//    Application.ProcessMessages; // Patch for refresh of columns in cxGrid
    if Manager.Active then
      Text := AHint
    else
      Caption := AHint;

If I remove the comment (execute Application.ProcessMessages) the problem goes away. However it introduces a possible Access Violation on the Text := AHint statement. I could not repeat the error, because Application.ProcessMessages is very timing dependent. Also it’s an extremely dangerous statement, making it possible to send messages totally out of context.

My problem indeed has a cxGrid, that is repopulated and resized during the panel visibility change. This find may allow you to narrow down the cause (I could imagine it is in acLFPainter).

[HeDiBo]

Since it is clearly a timing problem, even if I could reproduce this very complicated setup as a demo project, it would probably not repeat itself in your environment. It may even be unrepeatable in my own environment.

The endless repetition of WM_SETCURSOR in the SPY++ trace (they come during the idle time, when waiting for the controls to complete painting) means that a mouse message is not handled. This is the explanation of Microsoft about the WM_SETCURSOR message:

The DefWindowProc function passes the WM_SETCURSOR message to a parent window before processing. If the parent window returns TRUE, further processing is halted. Passing the message to a window’s parent window gives the parent window control over the cursor’s setting in a child window. The DefWindowProc function also uses this message to set the cursor to an arrow if it is not in the client area, or to the registered class cursor if it is in the client area. If the low-order word of the lParam parameter is HTERROR and the high-order word of lParam specifies that one of the mouse buttons is pressed, DefWindowProc calls the MessageBeep function.

As you can see: if not returning TRUE, the message keeps repeating.

[HeDiBo]

In the OnValidateError event, I cannot get to the value entered. It returns the previous value.

Also the string ‘The value is out of min/max bounds’ should be localizable.

When a record is inserted, the control is no longer prefilled with the minimum value. It is cleared in stead. And this cleared field is considered an acceptable value!!

[HeDiBo]

The OnValidateError event occurs too many times. In particular it occurs in the creation phase of the control. I think the error is in the overridden SetValue procedure. Not every time a value is posted to the TsDBCalcEdit control, that value is entered by the user. The following change makes it work, I think.

procedure TsDBCalcEdit.SetValue(AValue: Extended);
begin
  if Modified then FTextChangedByUser := True;   (**** DB ****)
{ FTextChangedByUser := Modified;  } // *** DB *** This may actually work better
  inherited SetValue(AValue);
end;

Again, using the Modified property i.s.o. FTextChangedByUser may do the trick.

• This reply was modified 4 years, 2 months ago by HeDiBo.

[HeDiBo]

I analyzed the changes you made and many of them involved setting or testing FTextChangedByUser. Apparently you didn’t know of the public property Modified of TCustomEdit. It does exactly that. It circumvents a lot of coding, I think. And the setters and getters also send you a message (EM_GETMODIFY / EM_SETMODIFY).

[HeDiBo]

If HandleDisabledCtrls is False, the problem disappears. That’s remarkable, because the button that comes into view is a TsSpeedButton, which will show the hint also if disabled.
That narrows the problem to AC’s specific code for hints on disabled controls.

[HeDiBo]

Because clicking the Next Record button to reach the last record did not produce this bug, I added a TDBNavigator to the frame. It shares the OnClick event with the TsDBNavigator. Clicking the Last Record button on that navigator does not produce the error 😲

I already had the suspicion that it was the Last Record click itself that caused it. The Spy++ trace also goes in that direction.

Then I added a TsDBNavigator in stead. And now the problem does not occur. Which means it must be related to the specific place of the original TsDBNavigator. Notice that the original TsDBNavigator moves up to make room for the panel made visible. The difference between the Next Record and Last Record buttons is: the specific Hint shown!! And indeed, when I’m quick in clicking the Last Record, before the Hint would be shown, the problem does not occur.

What then is the significant difference between Next and Last record (apart from the slightly different text of their hints)?

If the navigator moves up to make room for the panel made visible, the buttons in the panel are shown each with their own hints. And sure enough, if I disable the hint for the button below the Last Record button, the problem goes away. But why does it go OK on the Next Record button? The hint that appears on the button below the Next Record button is a short one. The one below the Last Record button is a longer two line hint.

Bringing us to the cause of the problem: timing!! If the hint which appears immediately below the navigator button is long enough to cause a bit of time to paint, the click handling of the navigator button goes haywire.

It’s ironic to conclude that the bug of showing the hint without any pause to speak of, causes this bug (it’s still a bug) to appear.

• This reply was modified 4 years, 3 months ago by HeDiBo.

[HeDiBo]

Thanks to Spy++ from the MS Visual Studio package, I was able to generate another trace, that shows quite clearly where the problem is.
There is an endless repetition of

<002618> 001F0650 S WM_SETCURSOR hwnd:007C0BA4 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<002619> 001F0650 R WM_SETCURSOR fHaltProcessing:False

which, I think, is an event that is not shown as completed. Therefore it repeats itself.

• This reply was modified 4 years, 3 months ago by HeDiBo.

Attachments:

You must be logged in to view attached files.

[HeDiBo]

I managed to capture a list of Windows Messages starting right after the bottom panel was made visible.
Remarkable are the countless WM_USER+41216 (0xA100) messages. There are two sets of them marked in the file.

Attachments:

You must be logged in to view attached files.

[HeDiBo]

Is there any way to start a log in code at a certain moment, to show the Windows messages being sent? It should not involve any user action: that would cancel the problem immediately.

[HeDiBo]

This is a very nasty problem to debug. As soon as I type Alt-Tab to Pause the running program in the IDE it has already disappeared.
It happens in all windows configurations (Win 32 / 64 with or without debugging).

[HeDiBo]

If I set the Active property of the SkinManager to False, the problem disappears. So, it’s definitely an AC problem.

[HeDiBo]

A whole panel with buttons appears at the bottom causing all other controls to move up or resize.

There are more ways to make this panel appear. In the navigator I could press the Next Record button. If that would bring me to the last record also, the panel with buttons would appear also.

The strange thing is, that only pressing the Last Record button produces the effect shown. I’m going to make a trace, to see what the difference between these two is.

[HeDiBo]

In the test program, I could not repeat the bug. Although that program mimics the offending program.
A close look at the MemoryManager event list may show you more than it does me.

[HeDiBo]

Thank you Stephane. I thought of it as an alternative to RefreshAcceptedDates. It would do all you describe, but more elegantly.

• This reply was modified 4 years, 3 months ago by HeDiBo.

[HeDiBo]

HintPause (the timing before a hint appears) becomes almost none. You can see that in the GIF of #69251
HintHidePause (the timing of the hint showing if mouse doesn’t move) should really be depending on the time needed to read the hint. Because your hints can be quite complex, this is more necessary than ever.
HintShortPause should really be a published property of TsAlphaHints. Hints come in rapid succession if a hint follows another one. To temper that, the HintShortPause timing is used.

By publishing the timing properties in TsAlphaHints one can easily adjust the timing carefully and it looks nice and logical.

[HeDiBo]

The problem occurs when a form is created and shown modal. If the mouse hovers over a control until the hint is shown and then, while the hint is shown, the modal form closes, the problem occurs every time.

[Author]

Posts