Application.ProcessMessages 挂起？

Question

我的单线程 delphi 2009 应用程序（尚未完成）已经开始出现 Application.ProcessMessages 挂起的问题。我的应用程序有一个 TTimer 对象，每 100 毫秒触发一次以轮询外部设备。我使用 Application.ProcessMessages 在发生变化时更新屏幕，以便应用程序仍然响应。

其中之一是网格 OnMouseDown 事件。在那里，它有一个本质上挂起的 Application.ProcessMessages 。删除它没有问题，只是我很快发现另一个同样阻塞的 Application.ProcessMessages 。

我认为我身上可能发生的情况是，TTimer（在我当前正在调试的应用程序模式下）可能需要很长时间才能完成。我已阻止 TTimer.OnTimer 事件处理程序重新输入相同的代码（见下文）：

procedure TfrmMeas.tmrCheckTimer(Sender: TObject);
begin
  if m_CheckTimerBusy then
    exit;

  m_CheckTimerBusy:=true;
  try
    PollForAndShowMeasurements;
  finally
    m_CheckTimerBusy:=false;
  end;
end;

在哪些地方调用 Application.ProcessMessages 是不好的做法？ OnPaint 例程在我的脑海中浮现出一些没有意义的东西。

有什么一般性建议吗？

我很惊讶地看到在开发的这个阶段出现了这种问题！

Answer 1

我对 TApplication.ProcessMessages 的建议是永远不要使用它 - 根本没有放置它的好点。

想象一下调用它会做什么：您的应用程序运行一个消息循环 - 其中 Windows 消息（由操作系统、其他应用程序、您的应用程序等生成）被顺序处理 - 并且在其中一个消息处理的中间，您只需再次重新运行整个消息循环，无法控制将处理哪些消息、将有多少消息、是否有任何消息将进入其自己的消息循环......以及它们是否有任何重入问题。这就是我所说的自招麻烦。

有时有很好的理由来处理一些窗口消息（特别是不挂起其他线程），或者处理所有定向到的消息一个特定的窗口，但这可以通过更微妙的方式和更多的控制来完成。

如果您必须在主 GUI 线程中进行任何处理，并且您只想更新界面，您可以使用 TWinControl.Repaint 方法重绘 GUI 元素。
如果您想让应用程序响应用户输入，您基本上必须使用后台/工作线程。

注意：在Delphi中，当在主线程中进行任何长时间的处理时，特别是如果涉及等待，您应该定期调用CheckSynchronize，以允许任何其他线程与主线程同步 - 它们可能（并且可能会）否则挂起。
VCL 仅在应用程序空闲时以及处理 WM_NULL 消息时调用此函数（假设不​​执行任何操作，这也可能会导致一些有趣的副作用）。

Answer 2

谢谢大家的意见/建议。

在这里，我制作了一个测试应用程序，它有一个计时器例程，该例程花费的时间比设置的时间间隔更长。当我按下button1时，Application.ProcessMessages挂起。我现在的解决方案是在计时器例程中禁用计时器。

稍后我们计划将“设备通信”放在一个线程中。

谢谢你！
议员

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ExtCtrls, StdCtrls;

type
  TForm1 = class(TForm)
    Timer1: TTimer;
    Button1: TButton;
    Memo1: TMemo;
    procedure Timer1Timer(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  memo1.Lines.Add('text 1');

  // this call blocks
  Application.ProcessMessages;

  memo1.Lines.Add('text 2');
end;

procedure TForm1.Timer1Timer(Sender: TObject);
var
  iTime:cardinal;
begin
  // fix by adding this:  timer1.Enabled:=false;

  iTime:=GetTickCount;
  while GetTickCount-iTime<200 do
    ;

  // fix by adding this:  timer1.Enabled:=true;
end;

end.

object Form1: TForm1
  Left = 0
  Top = 0
  Caption = 'Form1'
  ClientHeight = 286
  ClientWidth = 426
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object Button1: TButton
    Left = 8
    Top = 56
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
    OnClick = Button1Click
  end
  object Memo1: TMemo
    Left = 112
    Top = 8
    Width = 297
    Height = 233
    Lines.Strings = (
      'Memo1')
    TabOrder = 1
  end
  object Timer1: TTimer
    Interval = 100
    OnTimer = Timer1Timer
    Left = 200
    Top = 144
  end

Answer 3

使用 madExcept 你就会看到死锁在哪里。

Answer 4

严重依赖基于计时器的逻辑似乎很糟糕，并且您明白，正如您所说，您计划在将来使用线程。

以下是代码的进展：

1. 您有一条计时器窗口消息。它的作用很小。
2. 六个月后，您的计时器正在运行大量代码。
3. 您认为通过添加 Application.ProcessMessages 可以让事情变得更好。

让我们放大一点，在间隔为 100 毫秒的计时器上，考虑最坏的情况：

09:00:00.000 - timer event fires
09:00:00.100 - we are half way through our Timer Event code. We hit an Application.ProcessMessages.
09:00:00.101 - timer event fires again, but the first time into it, has not yet completed.
09:00:00.200 - we are half way through our timer event code, the second time,
and hit APplication.ProcessMessages again.

你能看到... 你能看到... 你能看到... 这里的问题吗？

瓦