Win32/64 Interface/ru
Эта статья относится только к Windows.
См. также: Multiplatform Programming Guide
│
English (en) │
русский (ru) │
Введение
Интерфейс win32 / 64 является, пожалуй, самым отлаженным и хорошо разработанным интерфейсом Lazarus, а также наиболее часто используемым, учитывая количество загрузок. Несмотря на то, что он наиболее полный, есть некоторые проблемы, которые нуждаются в исправлении.
Еще один важный момент, связанный с интерфейсом win32/64, заключается в том, что он в настоящее время находится в процессе миграции на unicode.
Win64: см. предостережение здесь о неиспользовании определенных версий FPC/Lazarus Win64.
Актуальные вопросы
Скроллинг
В настоящее время прокрутка выполняется путем перемещения дочерних элементов управления вместо перемещения клиентской области, как ожидает LCL. Например, в некоторых случаях это выглядит так, как будто дочерние элементы прокручиваются в обратном порядке. Правда такова, что прокрутка в значительной степени сломана. Прокрутка дочерних элементов управления несовместима с другими наборами виджетов, а также имеет такой недостаток: перемещение одного дочернего элемента за другим генерирует несколько сообщений перемещения. LCL получает сообщения и должен реагировать каждый раз (например, он должен перераспределить все привязанные дочерние элементы). Для одного набора виджетов вы можете попытаться преодолеть эту проблему, но решение никогда не будет работать одинаково хорошо для всех других наборов виджетов. Этот подход работает для VCL Delphi, но не для LCL. Поэтому должен быть реализован другой подход:
Решение
Решением было бы вставить окно «клиентской области» между окном каждого дочернего элемента и его родительским окном. Дочерние окна помещаются в окно «клиентской области», и когда прокручиваются дочерние окна, вместо этого перемещается окно «клиентской области». Это уже сделано другими наборами виджетов.
Замечание Mattias: В конце концов, я это реализую, но мои знания интерфейса winapi ограничены, и у меня уже есть множество других задач Lazarus, поэтому я не могу сказать, когда я это сделаю.
Связанные сообщения об ошибках
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
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:
- http://msdn2.microsoft.com/en-us/library/bb775146(VS.85).aspx
- http://msdn2.microsoft.com/en-us/library/bb775149(VS.85).aspx
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 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.
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;
Other Interfaces
- Lazarus known issues (things that will never be fixed) - A list of interface compatibility issues
- Win32/64 Interface - The Windows API (formerly Win32 API) interface for Windows 95/98/Me/2000/XP/Vista/10, but not CE
- Windows CE Interface - For Pocket PC and Smartphones
- Carbon Interface - The Carbon 32 bit interface for macOS (deprecated; removed from macOS 10.15)
- Cocoa Interface - The Cocoa 64 bit interface for macOS
- Qt Interface - The Qt4 interface for Unixes, macOS, Windows, and Linux-based PDAs
- Qt5 Interface - The Qt5 interface for Unixes, macOS, Windows, and Linux-based PDAs
- GTK1 Interface - The gtk1 interface for Unixes, macOS (X11), Windows
- GTK2 Interface - The gtk2 interface for Unixes, macOS (X11), Windows
- GTK3 Interface - The gtk3 interface for Unixes, macOS (X11), Windows
- fpGUI Interface - Based on the fpGUI library, which is a cross-platform toolkit completely written in Object Pascal
- Custom Drawn Interface - A cross-platform LCL backend written completely in Object Pascal inside Lazarus. The Lazarus interface to Android.
Platform specific Tips
- Android Programming - For Android smartphones and tablets
- iPhone/iPod development - About using Objective Pascal to develop iOS applications
- FreeBSD Programming Tips - FreeBSD programming tips
- Linux Programming Tips - How to execute particular programming tasks in Linux
- macOS Programming Tips - Lazarus tips, useful tools, Unix commands, and more...
- WinCE Programming Tips - Using the telephone API, sending SMSes, and more...
- Windows Programming Tips - Desktop Windows programming tips
Interface Development Articles
- Carbon interface internals - If you want to help improving the Carbon interface
- Windows CE Development Notes - For Pocket PC and Smartphones
- Adding a new interface - How to add a new widget set interface
- LCL Defines - Choosing the right options to recompile LCL
- LCL Internals - Some info about the inner workings of the LCL
- Cocoa Internals - Some info about the inner workings of the Cocoa widgetset