Thanks for your help. I was able to follow most of that and have enabled wccSessionChange. Now for the difficult bit - incorporating and adapting your example of DataModuleControlCodeEvent. As my understanding of classes and objects is rudimentary, I need to get my head around the significance of the term "data module" and the naming of the daemon class (is it arbitrary or is it referenced manually elsewhere?).
This will be a longer explanation, bear with me:
A
data module is similar to a visual form with the restriction that only non-visual components can be placed there (e.g. database connections, timers, etc.). Like forms they have a
LFM file from which the settings you made in the “form designer” (or in this case “data module designer”) are loaded. This includes settings like the
WinBindings.AcceptedCodes or which events are mapped to which methods.
Events are in essence properties that are method variables. Simple example is the predefined
TNotifyEvent:
TNotifyEvent = procedure(aSender: TObject) of object;
An event is usually declared like this:
type
TSomeClass = class
private
fOnWhatever: TNotifyEvent;
public
property OnWhatever: TNotifyEvent read fOnWhatever write fOnWhatever;
end;
By default this are set to
Nil, thus code usually checks whether they are set before calling them. If the event is triggered in more places then it's usually done using a helper method:
procedure TTestClass.DoWhatever;
begin
if Assigned(fOnWhatever) then
fOnWhatever(Self); // Self is usually used as aSender parameter
end;
Now the
OnControlCodeEvent event has the type
TCustomControlCodeEvEvent which has the following signature:
TCustomControlCodeEvEvent = Procedure(Sender : TCustomDaemon; ACode, AEventType : DWord; AEventData : Pointer; Var Handled : Boolean) of object;
The dropdown of a event handler in the object inspector will display all published methods of a class that have a matching signature. Published methods are those that are declared in a
published section
or that are declared at the top
without any visibility specifier (
private,
public, etc.) if the class has type information enabled (which is the case for everything that derives from
TPersistent which is the case for both
TForm and
TDataModule (and thus
TDaemon)).
If you simply double click an event handler in the object inspector the IDE will create a suitable name for the event handler together with the matching signature. Due to the inheritance and some internal magics of the IDE the name in this case will be
DataModuleControlCodeEvent (though
DaemonControlCodeEvent would be more correct, I'll have to check when I find the time if I can improve this
).
You are free to rename this method, but you'll have to adjust the event in the object inspector as well afterwards (the IDE will warn about dangling reference if you save the unit or data module).
Due to the streaming system with the
LFM files the RTL will automatically assign your event handler (in this case
DataModuleControlCodeEvent or whatever you'll name it) to the
OnControlCodeEvent event as if you had written code like this:
constructor TDaemon1.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
OnControlCodeEvent := @DataModuleControlCodeEvent;
end;
This is perfectly valid and can be used if forms, etc. are created at runtime.
I hope this helps you further, if not feel free to ask back.
Recent
