Win32/64 Interface

From Lazarus wiki
Revision as of 19:42, 6 December 2012 by BigChimp (talk | contribs)
Jump to navigationJump to search

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.

Other Interfaces

Platform specific Tips

Interface Development Articles

Current issues

Scrolling

The scrolling is currently done by moving the childs instead of the client area as the LCL expects. For example in some cases it looks as if the childs are scrolled in reverse direction. The truth is that the scrolling is pretty much broken. Scrolling the childs is incompatible to the other widgetsets and has a drawback: Moving one child after the other generates several move messages. The LCL receives the messages and each time it has to react. For example it has to realign all anchored childs. You can control this trouble for one widgetset but it will never work well for all. So this works for Delphi VCL, but not for the LCL. Therefore another approach must be implemented:

Solution

Between child windows and parent window a 'client area' window will be inserted. The child windows are put onto the 'client area' window and when the childs are scrolled the 'client area' window is moved instead. This is already done by the other widgetsets.

Mattias: I will implement this eventually, but my winapi interface knowledge is little and I have a lot of other lazarus tasks already, so I can't say when I 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

  • According to Paul it isn't related to WM_PAINT

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

  • TWin32WSCustomCheckListBox implements some minimal methods
  • TWin32WSCustomListBox implements handle creating and most methods
  • TWin32CheckListBoxStrings is the main TStrings descendent for this class

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:

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.

Example

By intercepting the WM_NCHITTEST message you can avoid dragging the window

Note: The Part, were the Funktion 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 are. Commenting this Section out seems to do no harm, and you are able to move the Program's windwow in Windows XP.

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,PtrInt(@WndCallback)));
end;