The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,262 other subscribers

Archive for December 22nd, 2020

Some odd Windows Messages for my research list (Windows 10 with a very basic Delphi application)

Posted by jpluimers on 2020/12/22

The bold messages below inside the main message loop are on my research list because:

  • they seem to be undocumented in WinUser.h and other header files
  • they are sent to Window handles that have no corresponding VCL TWinControl bound to them
  • they are WM_TIMER messages sending to a null hwnd, without the Delphi code registering a window-less timer (note the lParam indicates they have different call back procedures attached to them)

Being inside the message loop, they are either posted or created by Windows.

The hexadecimal value for WM_TIMER is documented: [Archive.is] 0x0113 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search.

Neither of the below messages are documented in either of the Undocumented Windows books (yes, there are two; the first – though rare to get – was a slightly earlier published one-person effort; the second was a tiny bit later three-person effort, but much thicker and included a diskette with tools; both books complement each other well; I am listed in both):

Messages I am looking for:

Yes, I know that Windows Messages are usually noted as 4 hexadecimal digits, but since they are UINT, the logging framework logs them as 32-bit hexadecimal values as this was a 32-bit application, see these WM_* constants and message ranges:

  • 0x0400: [WayBack] WM_USER – Windows applications | Microsoft Docs
  • 0x8000: [WayBack] WM_APP – Windows applications | Microsoft Docs

    The WM_APP constant is used to distinguish between message values that are reserved for use by the system and values that can be used by an application to send messages within a private window class. The following are the ranges of message numbers available.

    Start End Meaning Note
    0 WM_USER–1 Messages reserved for use by the system.
    WM_USER 0x7FFF Integer messages for use by private window classes. Depends on the one that called RegisterClass, see below.
    WM_APP 0xBFFF Messages available for use by applications. Depends on the one that called CreateWindow, see below.
    0xC000 0xFFFF String messages for use by applications.
    0x10000 0xFFFFFFFF Reserved by the system.

Note that [WayBack] Which message numbers belong to whom? – The Old New Thing explains more about CreateWindow and RegisterClass, which are important for the above subranges.

Similarly, the sharing of the ID space for Windows Messages, Atom Names and Clipboard Formats:

It might be that two of the messages are related to an undocumented UserAdapterWindowClass: [WayBack] Windows Creators Update Crashes old C++ Apps – Stack Overflow.

On message handling in general:

Related (as my WM_TIMER knowledge was rusty when scheduling this blog post):

Read the rest of this entry »

Posted in Development, Software Development, The Old New Thing, Windows Development | Leave a Comment »

winapi – What format is the time member of a MSG structure? – Stack Overflow

Posted by jpluimers on 2020/12/22

Found it. GetMessageTime defines it as the number of milliseconds since the system was started.

Source: [WayBack] winapi – What format is the time member of a MSG structure? – Stack Overflow.

It is not documented in the MSG/tagMSG documentation: [WayBack] tagMSG | Microsoft Docs Contains message information from a thread’s message queue.

Luckily, The Old New Thing does: [WayBack] What clock do MSG.time and GetMessageTime use? – The Old New Thing

The unit is documented in [WayBack] GetMessageTime function | Microsoft Docs: Retrieves the message time for the last message retrieved by the GetMessage function.

–jeroen

Posted in Development, Software Development, The Old New Thing, Windows Development | Leave a Comment »

If you control both caller and callee: do not “override” functions by introducing a function with the same name

Posted by jpluimers on 2020/12/22

Every now and then I see people “overriding” a function by introducing a function with the same name.

Often this raises a lot of confusion, because the override will only work if you have the unit of the override closer in your user scope.

Example:

Unit AdoOverrideUnit;

interface

function VarTypeToDataType(VarType: Integer): TFieldType;

implementation

uses
  Data.DB;

function VarTypeToDataType(VarType: Integer): TFieldType;
begin
  Result := Data.DB.VarTypeToDataType(VarType);
  // override Result for some ADO specific data management layer case.
  // ...
end;

end.

In this case it is much better to call the override AdoVarTypeToDataType instead of VarTypeToDataType.

Otherwise, when AdoOverrideUnit is not closer in scope than Data.DB, the wrong method will be called which is hard to track down.

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »