Sign in Join
Wiki copytemporary

Revision 2 of 2, by WikiArchive on 11-9-2026. The page as it is now.

Win32/64 Interface

https://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Windows_logo_-_2012.svg/60px-Windows_logo_-_2012.svg.png

This article applies to Windows only.

See also: Multiplatform Programming Guide

│ English (en) │ русский (ru) │

Introduction

The win32/64 interface is arguably the most polished and well developed interface of Lazarus, being also the most used one considering the number of downloads. Despite being the most complete, there are still some problems with it that need fixing.

Another important point about the win32/64 interface is that it is currently undergoing migration to unicode.

Win64: please see warning here> "Windows Programming Tips") on not using certain FPC/Lazarus Win64 versions.

Current issues

Scrolling

The scrolling is currently done by moving child controls instead of the client area as the LCL expects. For example in some cases it looks as if the children are being scrolled in reverse. The truth is that the scrolling is pretty much broken. Scrolling the child controls is incompatible with the other widgetsets and also has this drawback: Moving one child after the other generates several move messages. The LCL receives the messages and has to react each time (for instance it has to realign all anchored children). For a single widgetset you can attempt to overcome this problem, but the solution will never work well for all the other widgetsets. This approach works for Delphi's VCL, but not for the LCL. Therefore another approach must be implemented:

Solution

A solution would be to insert a 'client area' window between each child's window and its parent window. The child windows are placed on the 'client area' window, and when the children are scrolled the 'client area' window gets moved instead. This is already done by the other widgetsets.

Mattias: I will implement this eventually, but my winapi interface knowledge is limited and I have a lot of other Lazarus tasks already, so I can't say when I will implement it.

Related bug reports

Focus indication on themed controls

Controls (TCheckBox, TButton, TRadioButton, etc) loose their focus indication when the application is using themes.

Hints to solve

Related bug reports

Navigating controls with the arrow keys

Related bug reports

Implementation details

This list explains how specific parts of the LCL are implemented on the Win32 interface to help people find the appropriate code in it to do bug fixes.

Background color of Standard Controls

See also: Windows_CE_Development_Notes#TRadioButton_and_TGroupBox

One might notice that on Windows there is no implementation for TWSWin32WinControl.SetColor and neither does it have for most standard controls (GroupBox, RadioButton, CheckBox, etc), even thougth those controls can have their background color changed.

The reason is that this is implemented by handling a WM_CTLCOLOR* message. Most standard controls (GroupBox, RadioButton, CheckBox, etc) will send a WM_CTLCOLORSTATIC message. On this message one can set the background color and a handle to the brush used to paint the control must be returned.

Another important detail about this is that child controls have their messages sent to the WindowProc of their parent. So, if one has a Form with a GroupBox and a couple of CheckBoxes inside the GroupBox the messages of the GroupBox will go to the Form and the messages of the CheckBoxes will go to the GroupBox (including the WM_CTLCOLORSTATIC message). To overcome this the win32 widgetset uses SetWindowLong to reset the WindowProc of controls with child controls to our centralized WindowControl on win32callback.inc.

TCheckListBox

See also: Windows_CE_Development_Notes#TCheckListBox

On Windows, a TCheckListBox is a normal window of the class 'LISTBOX' which has the LBS_OWNERDRAWFIXED style set. When the listbox is created a WM_MEASUREITEM message will be sent, and after a WM_DRAWITEM message will be sent whenever an item needs to be painted. In the handler for this message a message LM_DRAWITEM message will be created.

The LM_DRAWITEM message is then intercepted by TWin32WidgetSet.CallDefaultWndHandler and handled in it's internal function:

procedure DrawCheckListBoxItem(CheckListBox: TCheckListBox; Data: PDrawItemStruct);

And here is the real code to paint the TCheckListBox items.

Note: This is kind of ugly, maybe this code should be moved to the LCL so we have a generic code to paint items in case the widgetset doesn't do it itself.

MSDN Docs about the LISTBOX:

FAQ

Processing user messages in your window

write me

Processing non-user messages in your window

To have a custom processing of messages <= WM_USER you should use SetWindowLong from the Windows unit. It will return the address of the current WndProc, so you can just have your WndProc like this:

pascal
begin
     if Msg = WM_COPYDATA then
     ...
     else CallOldWindowProc;
    end;

And you don't lose anything. With a clever code you can even use the same wndproc for any control, just take care to call the correct old wndproc in each case.

Examples

By intercepting the WM_NCHITTEST message you can avoid dragging the window.

Note: The part were the function interacts with "WM_NCHITTEST" has a very strange result in Windows XP. You will be unable to move the window. In Vista on the other hand, you still can. Commenting this section out seems to do no harm, and you are able to move the program's window in Windows XP.

pascal
uses
       ...Windows...
    ...
    var
      PrevWndProc: WNDPROC;
    ...
    function WndCallback(Ahwnd: HWND; uMsg: UINT; wParam: WParam; lParam: LParam):LRESULT; stdcall;
    begin
      if uMsg=WM_NCHITTEST then
      begin
        result:=Windows.DefWindowProc(Ahwnd, uMsg, WParam, LParam);  //not sure about this one
        if result=windows.HTCAPTION then result:=windows.HTCLIENT;
        exit;
      end;
      result:=CallWindowProc(PrevWndProc,Ahwnd, uMsg, WParam, LParam);
    end;
    
    //install our message handler
    procedure TForm1.FormCreate(Sender: TObject);
    begin
      PrevWndProc:=Windows.WNDPROC(SetWindowLongPtr(Self.Handle,GWL_WNDPROC,PtrUInt(@WndCallback)));
    end;

When there is no form (for example there is a necessity to receive windows messages in a custom component, things happen differently. The example shows how to detect if a device is connected or disconnected to the computer.

pascal
unit MyCustomControl;
    
    {$mode ObjFPC}{$H+}
    
    interface
    
    uses
      {$ifdef windows}Windows, jwaWinUser, JwaDbt,{$endif}
      Classes, SysUtils, stdctrls,  LCLIntf;
    
    type
    TMyCustomControl = class(tcombobox)
        private
           procedure InitResources_1;
           procedure InitResources_2;
        protected
          procedure CreateWnd; override;
          procedure WndProcNew(var Message: TMessage);
       public
         destructor Destroy; override;
      end;
    
    DEV_BROADCAST_HDR_DEVICE_TYPE = Cardinal;
    
    DEV_BROADCAST_HDR = record
      dbch_size: Cardinal;
      dbch_devicetype: DEV_BROADCAST_HDR_DEVICE_TYPE;
      dbch_reserved: Cardinal;
    end;
    
    DEV_BROADCAST_DEVICEINTERFACE_W = record
      dbcc_size: Cardinal;
      dbcc_devicetype: Cardinal;
      dbcc_reserved: Cardinal;
      dbcc_classguid: TGuid;
      dbcc_name: array[0..0] of WideChar;
    end;
    
    const
     DBT_DEVTYP_DEVICEINTERFACE = $5;
     DEVICE_NOTIFY_WINDOW_HANDLE = $0;
     DEVICE_NOTIFY_ALL_INTERFACE_CLASSES = $4;
     //THIS IS A GUI FOR USB
     GUID_DEVINTERFACE_USB_DEVICE: TGUID = '{A5DCBF10-6530-11D2-901F-00C04FB951ED}';
    
    var
      _dev: Dev_Broadcast_DeviceInterface_W;
      DevBlockRem: DEV_BROADCAST_HDR;
      NewHandle: HWND;
      {$ifdef windows}
      FDevNotify: HDEVNOTIFY;
      {$endif}
    
    procedure Register;
    
    implementation
    
    {$ifdef windows}
    procedure TMyCustomControl.CreateWnd;
    begin
      inherited CreateWnd;
      //These two calls are equivalent like the have constructed here
      //USE ONLY ONE OF THEM !!!
      //Call this if you want define some type of resources, see documentation
      InitResources_1;
      //Call this if you want define Hardware resources
     // InitResources_2;
    end;
    
    procedure TMyCustomControl.InitResources_1;
    begin
      NewHandle:= LCLIntf.AllocateHwnd(@WndProcNew);
      ZeroMemory(@_dev, sizeOf(Dev_Broadcast_DeviceInterface_W));
      with _dev do
        begin
          dbcc_size:=sizeOf(Dev_Broadcast_DeviceInterface_W);
          dbcc_devicetype:= DBT_DEVTYP_DEVICEINTERFACE;
          dbcc_reserved:=0;
          dbcc_classguid:= GUID_DEVINTERFACE_USB_DEVICE;
          dbcc_name:='';
        end;
      //Use "DEVICE_NOTIFY_ALL_INTERFACE_CLASSES" if you want catch all messages from all classes (ignore dbcc_classguid)
      FDevNotify:=RegisterDeviceNotification(NewHandle, @_dev, DEVICE_NOTIFY_WINDOW_HANDLE or DEVICE_NOTIFY_ALL_INTERFACE_CLASSES);
      Win32Check(FDevNotify <> nil);
    end;
    
    procedure TMyCustomControl.InitResources_2;
    begin
      NewHandle := LCLIntf.AllocateHWnd(@WndProcNew);
      ZeroMemory(@DevBlockRem, sizeOf(DevBlockRem));
      DevBlockRem.dbch_size := sizeof(DEV_BROADCAST_HDR)+sizeof(DEV_BROADCAST_DEVICEINTERFACE_W);
      DevBlockRem.dbch_devicetype := DBT_DEVTYP_DEVICEINTERFACE;
      DevBlockRem.dbch_reserved := 0;
      FDevNotify := nil;
      FDevNotify := RegisterDeviceNotification(NewHandle, @DevBlockRem, DEVICE_NOTIFY_WINDOW_HANDLE or DEVICE_NOTIFY_ALL_INTERFACE_CLASSES);
      Win32Check(FDevNotify <> nil);
    end;
    
    destructor TMyCustomControl.Destroy;
    begin
      if FDevNotify <> nil then
        UnregisterDeviceNotification(FDevNotify);
      inherited;
    end;
    
    procedure TMyCustomControl.WndProcNew(var Message: TMessage);
    var
      Description: string = '';
    begin
      case Message.Msg of
        WM_DEVICECHANGE: //for example
          begin
            Description := IntToHex(Message.wParam);
            case Message.wParam of
              DBT_DEVNODES_CHANGED : Description := Description + ' A device has been added to or removed from the system.';
              DBT_QUERYCHANGECONFIG : Description := Description + ' Permission is requested to change the current configuration (dock or undock).';
              DBT_CONFIGCHANGED : Description := Description + ' The current configuration has changed, due to a dock or undock.';
              DBT_CONFIGCHANGECANCELED : Description := Description + ' A request to change the current configuration (dock or undock) has been canceled.';
              DBT_DEVICEARRIVAL : Description := Description + ' A device or piece of media has been inserted and is now available.';
              DBT_DEVICEQUERYREMOVE : Description := Description + ' Permission is requested to remove a device or piece of media. Any application can deny this request and cancel the removal.';
              DBT_DEVICEQUERYREMOVEFAILED : Description := Description + ' A request to remove a device or piece of media has been canceled.';
              DBT_DEVICEREMOVEPENDING : Description := Description + ' A device or piece of media is about to be removed. Cannot be denied.';
              DBT_DEVICEREMOVECOMPLETE : Description := Description + ' A device or piece of media has been removed.';
              DBT_DEVICETYPESPECIFIC : Description := Description + ' A device-specific event has occurred.';
              DBT_CUSTOMEVENT : Description := Description + ' A custom event has occurred.';
              DBT_USERDEFINED : Description := Description + ' The meaning of this message is user-defined.';
            end; //case
    
            if (Message.wParam and $8000)<> 0 Then  { if the upper bit is set then header info follows}
             Begin
                Description :=  Description + '; Device Type = ' + IntToStr(PDEV_BROADCAST_HDR(Message.Lparam)^.dbch_deviceType);
                Case PDEV_BROADCAST_HDR(Message.Lparam)^.dbch_deviceType of
                     1 : Description := Description + ' : OEM, Mouse, Keyboards, optimistically';
                     2 : Description := Description + ' : Memory Device';
                     3 : Description := Description + ' : '+ String(Pwidechar(@PDEV_BROADCAST_PORT(Message.LParam)^.dbcp_name)); //USB COM ports usually send their names (for example you can get “COM5”)
                     //Most USB devices send nothing but 5 (keyboards and mice, sound cards, wifi adapters, phones). Displays also send 5.
                 end;
             end;
            writeln(Description);
            //Message.Result := 0; // Messagge handled
          end;
      end;
    end;
    {$endif}
    
    procedure Register;
    begin
      RegisterComponents('Additional',[TMyCustomControl]);
    end;
    
    end.

Other Interfaces

Platform specific Tips

Interface Development Articles

From the Free Pascal wiki, page "Win32/64 Interface", as the Internet Archive kept it on 2025-11-27, last changed on 2025-11-12. Copyright stays with the author who wrote it, according to the old wiki's Licensing page. If you have concerns about this material, message the admin.