I'm using a component that internally has a KeyDown handler, which sends a user defined PostMessage(WM_GROUPUNGROUP), and also has a custom message handler to handle WM_GROUPUNGROUP.
I want my app to do something after this message handler has executed, without modifying the component code.
(How) Can this be done?
One way to achieve this is via the WindowProc property.
Simply supply your own window procedure by assigning to WindowProc on the instance you want to hook. You'll need to take a copy to the previous value of WindowProc so that you can make sure that the original handling is carried out.
Roughly it goes like this:
type
TMyClass = class
....
FOldWindowProc: TWndMethod;
procedure NewWindowProc(var Message: TMessage);
....
end;
To redirect the window procedure you do this:
FOldWindowProc := SomeControl.WindowProc;
SomeControl.WindowProc := NewWindowProc;
Then implement the new window procedure like this:
procedure TMyClass.NewWindowProc(var Message: TMessage);
begin
FOldWindowProc(Message);
if Message.Msg = WM_GROUPUNGROUP then
....
end;
When you are done with the control, put the old window procedure back in place:
SomeControl.WindowProc := FOldWindowProc;
Another way to do it is to take advantage of the fact that the message is queued. You can add an Application.OnMessage handler, most likely by using a TApplicationEvents object. This will get a look at all queued messages. However, OnMessage fires before the message is dispatched to the control which sounds like it may be the wrong way round for you.
Related
What exactly is the difference between calling DefaultHandler(Message) and inherited in a message handlers. e.g:
TScrollBox = class(TScrollingWinControl)
private
...
procedure WMNCHitTest(var Message: TMessage); message WM_NCHITTEST;
...
end;
procedure TScrollBox.WMNCHitTest(var Message: TMessage);
begin
DefaultHandler(Message);
end;
Why not call inherited here? when should I use either?
Let us consider the example that you provide. Suppose that instead of calling DefaultHandler, inherited was called (or equivalently no WM_NCHITTEST message handler was implemented by TScrollBox). In that scenario the message would be processed by TWinControl in this method:
procedure TWinControl.WMNCHitTest(var Message: TWMNCHitTest);
begin
with Message do
if (csDesigning in ComponentState) and (FParent <> nil) then
Result := HTCLIENT
else
inherited;
end;
This performs special treatment when designing, otherwise it calls inherited which ultimately leads to a call to DefaultHandler which forwards the message to the default window procedure.
Now, TScrollBox replaces that message handler with this one:
procedure TScrollBox.WMNCHitTest(var Message: TMessage);
begin
DefaultHandler(Message);
end;
That calls DefaultHandler directly, and so unconditionally forwards the message to the default window procedure.
So, what we conclude from this is that TScrollBox.WMNCHitTest simply changes behaviour at designtime by suppressing the code in TWinControl.WMNCHitTest which returns HTCLIENT.
I presume therefore that this was the motivation of the author of this VCL code. By using DefaultHandler the behaviour of the underlying window (as determined by the default window procedure) is restored, removing any behaviour modifications implemented by the intervening VCL code.
It is very hard to be sure in specific cases. DefaultHandler handles (in theory) all messages where a message handler handles only one. Default Handler is a public virtual method and so can be overridden explicitly. Message handlers are not declared virtual, and are usually private anyway, so for example in your code if you replace
inherited;
by
inherited WMNCHitTest( message );
the compile will fail.
The other issue is which ancestor overrides what. So one ancestor may override the Message Handler, and another may override Default Handler, which makes it very confusing without a lot of digging.
So I guess for me I have to fall back on what seems best for documentation. Which means, in general, I would use inherited, because I am falling back on the ancestors implementation of this particular message, not the ancestors implementation for messages in general.
Which I guess is another way of saying - I would go with Victoria's approach.
I have one button on my form. Following is the click event of that button
procedure Form1.btnOKClick(Sender: TObject);
begin
//Do something
end;
This event will be called only when I click the button, right?
How can I call this event automatically without any user intervention?
The best way to invoke the OnClick event handler attached to a control is to call the Click method on the control. Like this:
btnOK.Click;
Calling the event handler directly forces you to supply the Sender parameter. Calling the Click method gets the control to do all the work. The implementation of the windows message handler for a button click calls the Click method.
But I second the opinion expressed in whosrdaddy's answer. You should pull out the logic behind the button into a separate method.
Do not put your businesslogic into event handlers. This will make your code unreadable when the application grows larger.
Normally you would do this:
procedure TForm1.DoSomething;
begin
// do something
end;
procedure TForm1.btnOKClick(Sender: TObject);
begin
DoSomething;
end;
then all you need to do is call DoSomething from other parts in your code
You can call this event in code like any other method.
...
btnOkClick(Self.btnOk); // Sender in this case is the btnOk
...
The Sender can be whatever object you like or nil.
I have created one application in which Main Form Calls Sub Form on FormShow event of Main Form. Sub Form is displayed and gives two options to choose. If First option on sub form is selected then then a Message is displayed and after that Main form will be displayed. Now when application runs on first time then after option selected on subform Meassage will be displayed. But i want to display message with Main Form as Background. So any solution to this. below is the FormShow code.
Procedure TMainForm.FormShow(Sender:TObject);
begin
if (SubForm.ShowModal = mrOK) and bOption1 then
begin
ShowMessage('Enter the value');
end;
end;
If I understand correctly then your problem is that when the message box show up your main form is still invisible.
If this is the case then you have two options:
Don't show your SubForm from the OnShow event of the main form, but at a later time
Don't show the message directly after ShowModal returns, but at a later time
For point number 2 you can use a similar approach as I suggested here, using PostMessage. So your code would look somethind like this:
procedure TMainForm.FormShow(Sender:TObject);
begin
if (SubForm.ShowModal = mrOK) and bOption1 then
begin
PostMessage(Self.Handle, WM_SHOWMYDIALOG, 0, 0);
end;
end;
The handler of WM_SHOWMYDIALOG then displays the actual message. This approach can also work for point 1, see ain's answer.
PostMessageposts a message to your application's message queue which will be processed after the main form finished becoming visible.
Another Option would be to use OnActivate of the Mainform instead of onShow.
If I understand you right you want
const
UM_AFTERSHOW = WM_APP + 1;
type
TForm1 = class(TForm)
protected
procedure UMAfterShow(var Msg: TMessage); message UM_AFTERSHOW;
procedure DoShow; override;
end;
procedure TForm1.DoShow;
begin
inherited;
PostMessage(Self.Handle, UM_AFTERSHOW, 0, 0);
end;
procedure TForm1.UMAfterShow(var Msg: TMessage);
begin
ShowMessage('Enter the value');
end;
By showing your message in the UMAfterShow handler you give the main form opportunity to become visible and thus to be in background.
The problem you are seeing (if I understand properly) is that FormShow is called before your main form is actually visible. So the message dialog shows before your main form.
What you need to do is use PostMessage to post a message to your main form that you then handle. This will allow your FormShow code to finish and the code will be triggered after the form is shown.
Take a look here for an example.
Yet another option would be to drop a TTimer component on your main form to trigger the message dialog.
Drop a TTimer component on your main form and set the enabled property to False and change the time from 1000 to 100. Code your message dialog and also set the Timer.Enabled property to False in the timer event to avoid repeated firings.
Now you can Enable the Timer at the point where you would have shown the message dialog in your main form's OnShow event.
In my Delphi form's OnShow method, I determine that a dialog must be opened automatically once the form is opened - and I should be able to do this by simulating a click on a menuitem.
However, calling menuitem.Click brings up the dialog before the main form has opened - which is not what I want.
I expect that should do what I want, but I cannot find what parameters to pass for "wparam" to send the click to my menuitem.
PostMessage(handle, WM_COMMAND, wparam, 0)
The MSDN WM_COMMAND docs talk about IDM_* identifiers, but how does that appear in Delphi?
(I know this is a very old question but despite being resolved in some way the real question has really gone unanswered.)
--
The command item identifier of a 'TMenuItem' is in the Command property. According to WM_COMMAND's documentation the high word of 'wParam' would be '0' and the low word would be the menu identifier;
PostMessage(Handle, WM_COMMAND, MakeWParam(MyMenuItem.Command, 0), 0);
or simply;
PostMessage(Handle, WM_COMMAND, MyMenuItem.Command, 0);
With a popup menu item there would be a slight difference: the VCL handles popup menus' messages with a different utility window. The global PopupList variable has the handle to it in its Window property;
PostMessage(PopupList.Window, WM_COMMAND, MyPopupMenuItem.Command, 0);
Perhaps you can try to open the dialog in the OnActivate event ?
I am not really sure if the OnActivate gets fired again other than when the form is shown but if it does you can use :
procedure TForm1.FormActivate(Sender: TObject);
begin
Form2.ShowModal;
Self.OnActivate := nil;
end;
Wouldn't you have to do this with a one-time timer, if you want the form to appear as per a normal Show/ShowModal, get drawn (etc) fully, and then immediately do something else?
tmrKickOff : a TTimer, 100 ms interval, disabled at design time,
fires off a 'tmrKickOffTimer' event.
in form create,
tmrKickOff.Enabled:=false; //just in case something happened in IDE
in form show, at end of all other stuff;
tmrKickOff.Enabled:=true;
in tmrKickOffTimer
begin
tmrKickOffTimer.Enabled:=false;
menuItemClick(nil);
end;
with apologies for style, form and any error-trapping :-)
Alternatively, handle the Application.OnIdle event with something along the lines of ...
if not DialogDone then
begin
MyDialogForm.ShowModal; // or menuItem.Click ....
DialogDone := true;
end;
OnIdle won't fire (for the first time) until the Form is shown and the message queue is empty.
I don't think you can send a message directly to your menu item, but you can just post it to the main window and show your dialog from there. I do this and it works great so that the dialog box (in my case, a login prompt) appears on top of the main window to avoid confusion.
-Mark
procedure WMPostStartup(var Message: TMessage); message WM_POSTSTARTUP;
procedure TMainForm.WMPostStartup(var Message: TMessage);
begin
Self.Refresh;
// Now show the dialog box.
end;
One method I have used, which is very simular to MarkF's solution, is to create a new user defined message type and send a message using that type to yourself when you determine that you need to perform this other process after your main form displays:
const
wm_SpecialProc = wm_User + 1;
procedure TForm1.WMSpecialProc(var Message:tMessage); message wm_SpecialProc;
begin
Form2.ShowModal;
end;
procedure TForm1.OnShow(Sender:tObject);
begin
if true then
PostMessage(Application.MainForm.Handle,wm_SpecialProc,0,0);
end;
The nice thing about this method is that you are in control of the message generation, so can populate ANY lparam or wparam you want to later use by your handler. I sent the message directly through the application.mainform but you could also just say handle for the current form.
When a user double-clicks a dbgrid, I show a non-modal form.
When they close that form, I want to refresh the grid.
To accomplish that, I have tried the following:
1 - Define a custom message constant:
const
WM_REFRESH_MSG = WM_USER + 1; //defined in a globally available unit
2 - In the OnClose event of my non-modal form, I have this:
procedure TMyNonModalForm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
PostMessage(Self.Handle,WM_REFRESH_MSG,0,0);
end;
3 - In the private declarations of the form that holds the dbGrid, I have this:
procedure OnRefreshRequest(var Msg: TMessage); message WM_REFRESH_MSG;
...
procedure TMyFormWithADBGrid.OnRefreshRequest(var Msg: TMessage);
begin
RefreshGrid;
end;
After doing these things, the PostMessage fires fine, but the OnRefreshRequest procedure never runs. What am I doing wrong?
Note that WM_USER is not the correct constant to base your own messages on, unless you are writing a custom control directly descending from TWinControl. Use WM_APP instead.
Also, it's considered good style to use UM_ for User Message instead of WM_ because that prefix is supposed to be reserved for the Windows header files.
Aside from the message name in the other answer, you are posting a message to Self.Handle while Self is going away. You probably meant to post to a different handle (the window that launched the modeless one). Give your modeless window access to that handle when you create it, and post the message there instead.
The post message needs to be sent to the other window handle, not the self.handle that you have listed. One way to do this would be to create a new property on your non-modal form and assign it the handle of the other form just before you show your non-modal one.
Other than that, and implementing the WM_REFRESH_MSG properly (CheGueVerra has it correct) it should work fine.
You might try and change the end of the declaration to match the message you are trying to send.
procedure OnRefreshRequest(var Msg: TMessage); message WM_CEA_REFRESH;
Should be this
procedure OnRefreshRequest(var Msg: TMessage); message WM_REFRESH_MSG;
I've uploaded an example of "What would Kevin do?" to Embarcadero's newsgroup forum embarcadero.public.attachments.
Basically it's a custom event that the main form (or whatever form/object you want) subscribes to when the non-modal form closes. In the main (or whatever) form...
var
NonModalForm :TfmNonModalForm;
begin
NonModalForm := TfmNonModalForm.Create(nil);
NonModalForm.Execute(NonModalFormClosingListener);
In the Execute method
procedure TfmNonModalForm.Execute(YourListenerMethod: THeyIClosedEvent);
begin
FHeyIClosedEvent := YourListenerMethod;
Show();
end;
If you can't get to the forum and need the additional code, leave a comment and I'll post the missing pieces.
Good luck