EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Delphi,Messanger,ApplicationEvents

Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.
#18489
Posted: 12/15/2011 13:35:10
by Henrik Lyder (Standard support level)
Joined: 02/02/2010
Posts: 8

using Delphi XE2 - created application using TMCMessanger, TMCSocketTransport, TMCQueue - I dropped a TApplicationEvents on the form and in the OnMessage handler I placed the code

Code
procedure TForm1.ApplicationEvents1Message(var Msg: tagMSG; var Handled: boolean);
begin
  Messenger.DispatchMessages;
end;


The end application in some instances is headless with no screen, no keyboard and no mouse. In this situation I am experiencing significant delays between a message is sent to the application, and the application actually responding to the event.

I placed a TTimer on the application to call the Messanger.DispatchMessages but this a bit messy so I would like to know if there is a different/better way to have the receiving application respond to a message in the shortest possible time.

Regards

Henrik Lyder
#18490
Posted: 12/15/2011 13:55:27
by Eugene Mayevski (EldoS Corp.)

Depending on architecture of your message receiver you can use the "standard" loop of GetMessage/ProcessMessage methods (the loop is standard cause Windows UI is built on top of the similar loop with Windows functions).


Sincerely yours
Eugene Mayevski
#18491
Posted: 12/15/2011 14:14:19
by Henrik Lyder (Standard support level)
Joined: 02/02/2010
Posts: 8

The application is built as a simple forms application with the needed components dropped on the form. as the application will eventuall be doing other tasks also, I dont think I can have the code just sitting in an endless GetMessage Loop?. Ideally I am looking for a way to have the Messanger trigger the main application in a "I_Just_Got_A_New_Message_EventHandler" without depending on the arrival of other events before the DispatchMessages is called.

Henrik
#18493
Posted: 12/15/2011 23:13:00
by Eugene Mayevski (EldoS Corp.)

There's a common misconception, brought up by event-driven programming habbits, that events magically fall down from the sky. This is not so.

Your code can not be magically called without *passing* execution to it. This is what you do by calling DispatchMessages or GetMessage/ProcessMessage. There can be no other way to get some code executed without calling it explicitly or implicitly (in your case, via DispatchMessages).

VCL hides this from you, but internally it has the same (but with Windows API functions) GetMessage/ProcessMessage loop.

If you do some lengthy work in your code, neither form events nor anything else will be called - this is because this GetMessage/ProcessMessage loop is not executed. You can call VCL's Application.ProcessMessages method to solve this problem.

The same with MsgConnect - you can call DispatchMessages method to let MsgConnect process incoming messages (and replies to previously sent messages, btw).


Sincerely yours
Eugene Mayevski
#18496
Posted: 12/16/2011 07:45:24
by Henrik Lyder (Standard support level)
Joined: 02/02/2010
Posts: 8

Thanks for the clarification - I guess I was expecting something like the TClientSocket and the OnRead event. No Matter, I will use a timer on the form and call the dispatch procedure at a set interval to get things moving in a resonable time - if not 'real' time. Or would you reccomend that I place the Messanger code in a seperate thread?


Regards

Henrik Lyder
#18497
Posted: 12/16/2011 08:17:12
by Eugene Mayevski (EldoS Corp.)

TClientSocket and it's OnRead event works via Windows messages as well so there's nothing different in it.

Calling DispatchMessages in OnTimer would be the same as just running a timer and having DispatchMessages in OnMessage (in your initial code). This is because timer in VCL works via Windows messages as well :).

Calling DispatchMessages in a separate thread is possible, yet all callbacks (if you use SendMessageTimeoutCallback()) and event handlers will be called in context of that thread, not the main application thread. If it's suitable for you, then that would be the best approach.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 5422 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!