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@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.c?rev=65766&r1=65765&r2=65766&view=diff
==============================================================================
--- 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)