Delphi, you've got message to handle!
One of the keys to traditional Windows programming is handling the messages sent by Windows to applications. Simply put, a message is some information sent from one place to another. For the most part, Delphi makes message handling easy through its use of events, an event is usually generated in response to a Windows message being sent to an application.
However, someday we'll want to process some uncommon messages like: CM_MOUSEENTER which happens (is posted by Windows) when mouse cursor enters the client area of some component (or form).
Handling messages on our own requires a few extra programming techniques, this article is here to help us find the right way through the message river and grap needed information.
Learning to manipulate Windows Messages with Delphi
No title bar! How can we drag such a window? It's easy and fun: let's make a Delphi form move by clicking (and dragging) in it's client area. The main idea is to get our hands on the wm_NCHitTest windows message.
Learn how to send the WM_CopyData message between two Delphi applications to exchange information and make two applications communicate. The accompanying source code demonstrates how to send a string, record (complex data type) and even graphics to another application. .
How to dock your Delphi forms to the edges of your desktop screen.
Need to get notified about changes to the attributes or contents of a specified Registry key? Then you are ready for: Part 4 of your 'Big Brother' Delphi code toolkit
Learn how to send messages (signals) to non-windowed applications by using AllocateHWND and DefWindowProc. In this article we also briefly describe what Delphi does in the background to intercept Windows messages, how can we write our own message handler for a windowed application and how to obtain a unique message identifier that we can safely use in our applications. We'll also discover and fix a small bug in the Delphi DeallocateHWND procedure along the route.
In this article you'll learn how to "run-once enable" a Delphi application that can check for its previous (running) instance. Along the process, several techniques of implementing such a check will be discussed; as well as how to bring your already running application to the foreground, if a user tries to run it "one more time". By the end of the article you'll have a copy-to-go code to control the behavior of your application's multiple instances: with the option to limit the number of running instances.
If you want to detect when a user starts resizing and moving a Delphi form, and when the move (or resize) operation is finished, you need to handle a few Windows messages: WM_ENTERSIZEMOVE, WM_MOVE and WM_EXITSIZEMOVE. Here's how...
If you need to react when system date time has changed you can handle the WM_TimeChange Windows message...
If you want to add some custom text on the caption bar of a form, without changing the Caption property of the form you need to handle one special Windows message: WM_NCPAINT (along with WM_NCACTIVATE). Here's how in Delphi.
By (Windows) design, in Delphi applications, hints assigned to menu items do not get displayed in the popup tooltip window (when the mouse hovers over a menu).
Changing the Windows display mode settings (resolution and color depth) from Delphi code. Plus: how to handle the WM_DISPLAYCHANGE Windows message sent to all windows when the display resolution has changed.
Here's how to retrieve the full URL of all opened Internet Explorer instances.
Programmatically Cancel Windows Shut Down action.
Suppose you have a data-critical type of application where you would not want a non-authored user to work with the data. What if you need to display a password dialog *before* the application is restored to make sure an authorized user is accessing it.
By Windows design a form (window) has a size constraint that sets the minimum form height to the height of the caption bar and the width to 112 pixels (118 in XP theme).
Unfortunately, the TPopupMenu does not expose an event you can handle that will fire when the menu gets closed - either after a user has selected an item from the menu or has activated some other UI element. Here's a fix to this behavior.
"...Delphi surfaces the OnMessage event for the Application object. The OnMessage event handler is "supposed" to allow you trap every message sent to your application..."