I am moving some control functionality from a GUI program to a console program in order to in the end being able to run it from cron. In fact I have several candidates for this migration.

Now I have run across a problem regarding Application.Processmessages which causes a compile error in the console applications. And I don't really know if it is needed or not either, but this pops up inside classes (non-visual) that I have used before and want to use now. For example in this delay function:

procedure TSSRelayControl.Delay(T: LongWord);
var
  Tnow: LongWord;
begin
  Tnow := GetTickCount;
  while (GetTickCount - Tnow) < T do //Rolls over automatically
  begin
    //Application.ProcessMessages; <== Compile error!
    Sleep(1);
  end;
end;

I tried adding the CustApp unit into uses but it does not help.

In general, is there a need for Application.Processmessages only in a GUI app and if so how can one handle this in classes that need to be used in both GUI and non-GUI programs?

I also get a warning that I should use GetTickCount64 instead of GetTickCount, but that seems strange since it would not fit into a LongWord...

I tried adding the CustApp unit into uses but it does not help.

Of course, the unit only declares TCustomApplication with no instance, which real application must extend and override its virtual methods + declare and initialize its instance. See how Forms unit does it for LCL application.

In general, is there a need for Application.Processmessages only in a GUI app

There's no message loop in console applications thus Application.ProcessMessages is meaningless there (what would be in the message loop anyway? message to repaint the console? :p).

and if so how can one handle this in classes that need to be used in both GUI and non-GUI programs?

Depends on what the code does. Sometimes it's not possible because the code is tied to GUIism. But in general, use callback method. Should be somewhat equal to having a base class with abstract method, and another two extending it with the abstract method implemented for specific platform / application type.

Bo Berglund wrote

I am moving some control functionality from a GUI program to a console program ...

As we already discussed here multiple times, in Lazarus, currently, "Event Based Programming" is only supported "out of the box" with "Widget Types" that have a GUI binding .

I still do plan to enhance the Widget Type "NoGUI" to optionally allow for this, and - as I already explained - did do a proof of concept implementation.

But for now, this is not tested decently

-Michael