Recent

Author Topic: Does Application.ProcessMessages work only within the app itself, or wider?  (Read 557 times)

egsuh

  • Hero Member
  • *****
  • Posts: 1371
I have two questions here.

First is as the title imply, if I insert Application.ProcessMesssages e.g. in a loop, does this have effects only on other forms of the same application, or does it help other apps running simultaneously on the same PC?

Second, is this usable in a unit which does not contain form?

cdbc

  • Hero Member
  • *****
  • Posts: 1230
    • http://www.cdbc.dk
Hi
"Application.ProcessMesssages" is a method of the global Application object, so it'll only work within your program, /not/ in other applications / programs.
If your program is a gui-app i.e.: 'with forms', then the 'Application' object should be available, in the units that include "Forms" in the uses clause.
Mind you: It's sound programming to keep "A clear separation of concerns", meaning: don't mix gui-stuff and program-logic/data
...and the 'Forms' unit, means gui-stuff  :D
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE5 -> FPC 3.2.2 -> Lazarus 2.2.6 up until Jan 2024 from then on it's: KDE5/QT5 -> FPC 3.3.1 -> Lazarus 3.0

TRon

  • Hero Member
  • *****
  • Posts: 2768
First is as the title imply, if I insert Application.ProcessMesssages e.g. in a loop, does this have effects only on other forms of the same application, or does it help other apps running simultaneously on the same PC?
Though cdbc is correct in his answer it is (was) possible to have a loop that is such processor intensive that it could lockup the rest of the PC's performance (thus also other programs besides your own). In this days and age (with multicore/multithread processors) you would have to be pretty brutal to achieve a similar effect but in theory it is still possible (also depends on the OS and how multitasking is implemented).

Khrys

  • New Member
  • *
  • Posts: 20
As its name implies,  Application.ProcessMessages  handles all pending messages in the message queue. Messages are mostly GUI related; think mouse clicks/motions, key presses/releases, window/control creation and modification, drawing/painting...

There exists exactly one message queue per process (it is global in the process's scope), and thus all windows inside the process are subject to it. External processes are not affected; in general, messages are handled by the process, while processes themselves are managed by the OS.

Being global means that  Application.ProcessMessages  can called anywhere in your program, even inside units that don't contain any user-defined forms. However you'll still need to add the  Forms  unit to the  uses  clause, since that's where  Application  is defined.

You also need to make sure that  Application.ProcessMessages  is only called from the main thread (ThreadID = MainThreadID), but you'll only have to worry about that if you use multithreading in your application.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 850
It's actually thread-specific on Windows. Only messages for windows that are created within the same thread are handled. This allows you to implement MDI applications. But last time when I checked, it was working wrong way in Lazarus.

In most cases it's very useful to understand simple concept - OOP is usually just wrapper around some OS specific code. And in this case ProcessMessages simply runs in-place message loop until all pending message are processed. Something you would do via "while PeekMessage(...) do DispatchMessage(...);".
« Last Edit: May 29, 2024, 09:50:11 am by Mr.Madguy »
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

 

TinyPortal © 2005-2018