I read here about how to create a Window Handle into a non-windowed conrol. I did just the way I read, but nothing happens. So I come to you guys.
My class is this way right now:
interface
type
TMyObject = class
private
fMsgHandlerHWND : HWND;
procedure WndMethod(var Msg: TMessage);
public
constructor Create;
destructor Destroy; Override;
end;
implementation
constructor TMyObject.Create;
begin
inherited;
fMsgHandlerHWND := AllocateHWnd(WndMethod);
end;
destructor TMyObject.Destroy;
begin
deallocatehwnd(fMsgHandlerHWND);
inherited;
end;
procedure TMyObject.WndMethod(var Msg: TMessage);
begin
if Msg.Msg = WM_KEYUP then
MessageBeep(0)
else
Msg.Result := DefWindowProc(fMsgHandlerHWND, Msg.Msg, Msg.wParam, Msg.lParam);
end;
I do use my FormCreate to execute var := TMyObject.Create.
Following the line where Windows sends broadcast messages when I press/release a key (correct me if I'm wrong); I'm not sure why it did not work. Somoeone can tell me what did I do wrong? There is another way to catch KeyBoard input with a non-windowed object? If so, how?
Keyboard events are delivered to the window with input focus. That's never going to be your hidden window.
if you want to catch input events the cleanest way is to use the OnMessage event of the global Application object. All queued messages pass through this event handler. Subscribe to it using a TApplicationEvents instance.
Related
I've copied code from this article:
Controlling the number of application instances
However, the message being sent by SendMessage is not being 'caught' by the main form.
This is the code in the DPR file, where we are registering the message, and then broadcasting it if an instance of the application is already running:
var
Mutex: THandle;
begin
MyMsg := RegisterWindowMessage('Show_Main_Form');
Mutex := CreateMutex(nil, True, 'B8C24BD7-4CFB-457E-841E-1978A8ED0B16');
if (Mutex = 0) or (GetLastError = ERROR_ALREADY_EXISTS) then
begin
SendMessage(HWND_BROADCAST, MyMsg, 0, 0);
end
This is code from the main form:
var
fmMain: TfmMain;
MyMsg: Cardinal;
implementation
uses
uSettings;
{$R *.dfm}
procedure TfmMain.AppMessage(var Msg: TMsg; var Handled: Boolean);
begin
if (Msg.Message = MyMsg) then
begin
beep;
Application.Restore;
Application.MainForm.Visible := True;
SetForeGroundWindow(Application.MainForm.Handle);
Handled := True;
end;
end;
procedure TfmMain.FormCreate(Sender: TObject);
begin
Application.OnMessage := AppMessage;
end;
The problem is that the procedure AppMessage does not get called. What is wrong?
OnMessage is used to intercept queued messages. However, this message is sent rather than queued. You need to override the form's window procedure in order to receive it:
Add this to the protected part of your form's type declaration:
procedure WndProc(var Message: TMessage); override;
Implement it like this:
procedure TfmMain.WndProc(var Message: TMessage);
begin
inherited;
if Message.Msg = MyMsg then
begin
Beep;
Application.Restore;
Application.MainForm.Visible := True;
SetForeGroundWindow(Application.MainForm.Handle);
end;
end;
Since this form is presumably the single instance of the application's main form you might replace the body of the message handler with this:
Application.Restore;
Visible := True;
SetForeGroundWindow(Handle);
I would also comment that broadcasting such a message seems a little risky to me. You'll be sending that message to every top-level window in the system. I think that has definite potential to cause problems if you encounter a program that reacts to that message when it should not.
Were it me I would identify the window which you intend to target, and send the message directly to that window. And I would use SendMessageTimeout to be robust to the scenario where the target app is not responding. In that scenario, SendMessage will never return and the sending application will also become hung.
When my control is created I must use DeviceWnd:=AllocateHWnd(DeviceWindowProc); to receive WM_DEVICECHANGE message. And then...
procedure TFileList.DeviceWindowProc(var Message: TMessage);
begin
case Message.Msg of
WM_DEVICECHANGE: begin
case Message.WParam of
DBT_DEVICEREMOVECOMPLETE, DBT_DEVICEARRIVAL:
if PDEV_BROADCAST_HDR(Message.LParam).dbch_devicetype = DBT_DEVTYP_VOLUME then
OnDeviceChange;
end;
end;
end;
Message.Result:=DefWindowProc(DeviceWnd, Message.Msg, Message.WParam, Message.LParam);
end;
This works well, but why I don't reveive that message when I do like this ? :
TFileList = class(TCustomControl)
private
procedure DeviceChage(var AMessage:TMessage); message WM_DEVICECHANGE;
end;
procedure TFileList.DeviceWindowProc(var Message: TMessage);
begin
Message.Result:=DefWindowProc(DeviceWnd, Message.Msg, Message.WParam, Message.LParam);
end;
procedure TFileList.DeviceChage(var AMessage:TMessage);
begin
case AMessage.WParam of
DBT_DEVICEREMOVECOMPLETE, DBT_DEVICEARRIVAL:
if PDEV_BROADCAST_HDR(AMessage.LParam).dbch_devicetype = DBT_DEVTYP_VOLUME then
OnDeviceChange;
end;
end;
From the documentation of RegisterDeviceNotification:
Applications send event notifications using the BroadcastSystemMessage function. Any application with a top-level window can receive basic notifications by processing the WM_DEVICECHANGE message. Applications can use the RegisterDeviceNotification function to register to receive device notifications.
The window that you create with AllocateHWnd is a top-level window. Hence it receives the broadcast messages.
Your custom control is not a top level window. If you want it to receive messages you will have to call RegisterDeviceNotification passing its window handle. If you do that, be sure to deal with VCL window recreation by registering in CreateWnd and unregistering in DestroyWnd.
As a general rule of thumb, AllocateHwnd is the preferred way to listen for notifications. That's because it is not subject to VCL window recreation, and so cannot miss notifications. When a VCL window is being recreated then there is a window of opportunity for notifications to be sent, but your application not having a window ready to receive.
That's certainly going to be an issue in your case and so you should use AllocateHwnd. You can arrange that the window you create with AllocateHwnd is owned by your custom control, and then you can route the notification to that control's code.
WM_DEVICECHANGE is broadcasted to top-level windows. Your custom control's window is not a top-level window, it is a child window of the control's Parent window. That is why your message handler is not being called - the message is never arriving in your control's WndProc() so it can be dispatched to a message handler.
For most device notifications, you can use RegisterDeviceNotification() to have WM_DEVICECHANGE messages be sent to a specific HWND. However, in your example, volume change messages cannot be registered like that:
the function fails if dbch_devicetype is DBT_DEVTYP_VOLUME.
So, for your custom control to receive WM_DEVICECHANGE messages, it MUST allocate its own top-level window, such as with the AllocateHwnd() function:
type
// TCustomControl is meant to be used for developing **visual**
// controls. If your custom control is not visual, you should
// derive from `TComponent` instead...
TFileList = class(TCustomControl)
private
DeviceWnd: HWND;
procedure DeviceWindowProc(var Message: TMessage);
public
constructor Create(Owner: TComponent); override;
destructor Destroy; override;
end;
constructor TFileList.Create(Owner: TComponent);
begin
inherited Create(Owner);
if not (csDesigning in ComponentState) then
DeviceWnd := AllocateHwnd(DeviceWindowProc);
end;
destructor TFileList.Destroy;
begin
if DeviceWnd <> 0 then
DeallocateHwnd(DeviceWnd);
inherited Destroy;
end;
procedure TFileList.DeviceWindowProc(var Message: TMessage);
begin
if Message.Msg = WM_DEVICECHANGE then
begin
case Message.WParam of
DBT_DEVICEREMOVECOMPLETE, DBT_DEVICEARRIVAL:
if PDEV_BROADCAST_HDR(Message.LParam).dbch_devicetype = DBT_DEVTYP_VOLUME then
OnDeviceChange;
end;
end;
Message.Result := DefWindowProc(DeviceWnd, Message.Msg, Message.WParam, Message.LParam);
end;
I have TMyClass, a class derived from TObject. It has a TTimer. Every few minutes, from Timer.OnTimer I check a web page. When the web page changes, I am done and I want to free MyClass. How do I free it?
My question is similar to this one BUT my 'control' is not a TControl. It is descendent of TObject. So, Messages won't work.
Obviously, the solution will be to derive my class from TControl or higher. But let's say I don't want to do that. What would be the solution in this case?
The basic idea behind using a message is correct: ensure that the object gets freed at a later point, after whatever code is currently calling it is finished.
A few years ago, I wrote a Delayed Action unit that gives you a simple way to accomplish this same effect without a TControl. You just call DelayExec and pass an anonymous method to it that will free the object, and it sets up a message internally that makes it happen once the message queue gets pumped.
To receive messages you need to have window handle. You can allocate one using AllocateHWnd, something like
type
TMyClass = class(TObject)
private
FHandle: HWND;
procedure MyWndProc(var Msg: TMessage);
public
constructor Create; virtual;
destructor Destroy; override;
end;
constructor TMyClass.Create();
begin
inherited Create();
FHandle := AllocateHWnd(myWndProc);
end;
destructor TMyClass.Destroy;
begin
DeallocateHWnd(FHandle);
inherited;
end;
procedure TMyClass.MyWndProc(var Msg: TMessage);
begin
case Msg.Msg of
CM_RELEASE: begin
Free;
end;
else Msg.Result := DefWindowProc(FHandle, Msg.Msg, Msg.WParam, Msg.LParam);
end;
end;
Now you can post messages to the object using the FHandle as demonstrated in the post youre reffering to.
Does the TListView control have an event that will fire whenever the control is scrolled?
I would prefer not to have to sub-class the TListView control.
This works perfectly, but might violate the constraints of your question.
In the interface section of the unit containing the form that use the TListView (prior to the TForm declaration), add
type
TListView = class(ComCtrls.TListView)
protected
procedure WndProc(var Message: TMessage); override;
end;
Then, in the implementation section of the same unit, define
procedure TListView.WndProc(var Message: TMessage);
begin
inherited;
case Message.Msg of
WM_HSCROLL, WM_VSCROLL: beep;
end;
end;
You can subclass a window without writing a descendant class, which is useful when you expect the changed behavior to be a one-off requirement. Write a TWndMethod function like in Andreas's answer, but write it in whatever class you want, such as the form that owns the list view. Assign it to the list-view control's WindowProc property. Before you do that, store the property's previous value so you can defer all other messages to it.
type
TNanikForm = class(TForm)
ListView: TListView;
private
FPrevListViewProc: TWndMethod;
procedure ListViewWndProc(var Msg: TMessage);
public
procedure Loaded; override;
end;
procedure TNanikForm.ListViewWndProc(var Msg: TMessage);
begin
case Msg.Message of
wm_VScroll: ;
else FPrevListViewProc(Msg);
end;
end;
procedure TNanikForm.Loaded;
begin
inherited;
FPrevListViewProc := ListView.WindowProc;
ListView.WindowProc := ListViewWndProc;
end;
Or if you want to trap just vertical scroll event, you can use this. Code is almost the same as Andreas posted ...
type
TListView = class(ComCtrls.TListView)
protected
procedure WMVScroll(var Message: TWMVScroll); message WM_VSCROLL;
end;
procedure TListView.WMVScroll(var Message: TWMVScroll);
begin
inherited;
Beep;
end;
The all answer is fine :-), but I don't wont to create new child of class. Thanks everyone for your help :-)!
My resolution: I use component (in Delphi 7) ApplicationEvents and I check change of ScrollBar position (GetScrollPos(ListView.Handle, SB_VERT)).
How can i simulate an OnDestroy event for a TFrame in Delphi?
i nievely added a constructor and destructor to my frame, thinking that is what TForm does:
TframeEditCustomer = class(TFrame)
...
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
...
end;
constructor TframeEditCustomer.Create(AOwner: TComponent)
begin
inherited Create(AOwner);
//allocate stuff
end;
destructor TframeEditCustomer.Destroy;
begin
//cleanup stuff
inherited Destroy;
end;
The problem with this is that by the time my destructor runs, controls on the frame have been destroyed and are no longer valid.
The reason for this is in the containing form's destructor, which it uses to fire an OnDestroy event:
destructor TCustomForm.Destroy;
begin
...
if OldCreateOrder then DoDestroy; //-->fires Form's OnDestroy event; while controls are still valid
...
if HandleAllocated then DestroyWindowHandle; //-->destroys all controls on the form, and child frames
...
inherited Destroy; //--> calls destructor of my frame
...
end;
The destructor of my frame object is being called when the form's destructor runs. Problem with this is that it's too late. The form calls DestroyWindowHandle, which asks Windows to destroy the form's window handle. This recursively destroys all child windows - including those on my frame.
So when my frame's destructor runs, i attempt to access controls that are no longer in a valid state.
How can i simulate an OnDestroy event for a TFrame in Delphi?
See also
Simulating OnCreate and OnDestroy for a Frame?
How to Implement the OnCreate event for a Delphi TFrame object
Embargadero QC#1767: TFrame misses OnCreate, OnDestroy, OnShow
You need to add a WM_DESTROY handler and check for csDestroying in the ComponentState so it's only caught when actually destroying, and not when recreating the handle.
type
TCpFrame = class(TFrame)
private
FOnDestroy: TNotifyEvent;
procedure WMDestroy(var Msg: TWMDestroy); message WM_DESTROY;
published
property OnDestroy: TNotifyEvent read FOnDestroy write FOnDestroy;
end;
procedure TCpFrame.WMDestroy(var Msg: TWMDestroy);
begin
if (csDestroying in ComponentState) and Assigned(FOnDestroy) then
FOnDestroy(Self);
inherited;
end;
That will only work if the frame's window handle has actually been created. There isn't another good hook point, so if you want to ensure it's always called you'll need to set a flag in WMDestroy and fall back to calling it in the destructor if that isn't hit.
The window handles themselves are all cleared in WM_NCDESTROY, which is called after all of the descendant WM_DESTROY messages return, so the form and all of its childens' handles should still be valid at this point (ignoring any that were freed in the form's OnDestroy).
Sounds more like OnClose than OnDestroy.
Anyway, I just inherited all my frames and forms from a base ancestor, and the form's onclose calls then all frames in the component hierarchy.
(It's just an idea but I haven't got the time right now to construct a proof of concept, but I'll share it none the less:)
If it's a problem with the Windows handle(s), you should check wether you're able to attach a Windows' event callback pointer that gets called when the frame's Windows handle ceases to exists. Perhaps with a function like RegisterWaitForSingleObject
Another option is to override AfterConstruction and BeforeDestruction
Something like this:
TMyFrame = class(TFrame)
private
FOnCreate: TNotifyEvent;
FOnDestroy: TNotifyEvent;
protected
procedure DoCreate; virtual;
procedure DoDestroy; virtual;
public
procedure AfterConstruction; override;
procedure BeforeDestruction; override;
property OnCreate: TNotifyEvent read FOnCreate write FOnCreate;
property OnDestroy: TNotifyEvent read FOnDestroy write FOnDestroy;
end;
implementation
procedure TMyFrame.AfterConstruction;
begin
inherited;
DoCreate;
end;
procedure TMyFrame.BeforeDestruction;
begin
inherited;
DoDestroy;
end;
procedure TMyFrame.DoCreate;
begin
if Assigned(FOnCreate) then
FOnCreate(Self);
end;
procedure TMyFrame.DoDestroy;
begin
if Assigned(FOnDestroy) then
FOnDestroy(Self);
end;