Ideally, we'd fork comctl32 into two libraries like windows does, but that
would probably mean we'd have to fork from wine, moving the maintenance
effort to our side. That's why we did not do it yet.
Sent from my Windows Phone
------------------------------
From: Alex Ionescu
Sent: 21/12/2014 09:05
To: ReactOS Development List
Cc: Linda Wang; Filip
Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do
not add two additional pixels at the top margin of the toolbar. This is the
behaviour of comctl32 v6 and our explorer depends on that to appear
properly. We do...
Isn't the correct solution to use SxS with an activation context?
Best regards,
Alex Ionescu
On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote:
Author: gadamopoulos
Date: Sat Dec 20 16:49:31 2014
New Revision: 65766
URL:
http://svn.reactos.org/svn/reactos?rev=65766&view=rev
Log:
[COMCTL32]
* Do not add two additional pixels at the top margin of the toolbar. This
is the behaviour of comctl32 v6 and our explorer depends on that to appear
properly. We don't have a proper solution for these differences in behavior
and since we already opt to use the v6 behavior I think it is fine.
CORE-5483 #resolve #comment Committed a slightly different version of the
patch, thanks.
Modified:
trunk/reactos/dll/win32/comctl32/toolbar.c
Modified: trunk/reactos/dll/win32/comctl32/toolbar.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar…
==============================================================================
--- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20
16:49:31 2014
@@ -244,7 +244,12 @@
static inline int default_top_margin(const TOOLBAR_INFO *infoPtr)
{
+#if 0
return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER);
+#else
+ /* This is the behaviour in comctl32 v6 */
+ return 0;
+#endif
}
static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle)