Difference between revisions of "Win32/64 Interface"
(The win32 interface disables child controls of disabled controls in lazarus 0.9.25) |
|||
Line 26: | Line 26: | ||
* [http://bugs.freepascal.org/view.php?id=10188 10188] | * [http://bugs.freepascal.org/view.php?id=10188 10188] | ||
* [http://bugs.freepascal.org/view.php?id=10471 10471] | * [http://bugs.freepascal.org/view.php?id=10471 10471] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 20:47, 31 January 2008
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
- 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
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