www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - window menu drawing different in D and in VC++/MinGW

reply Serg Kovrov <kovrov no.spam> writes:
Greetings everybody,

I have ported extremely simple win32 gui example (one of catch22.net 
tutorials), and run into strange problem - when built with D, program 
drawing routine behaves slightly different from original. regardless 
that code almost identical. I suppose it is related to non-client 
drawing of frame window.

Please see screenshots:

This is how it should look (and actually do look so when built with VC++ 
or MinGW):
http://img245.imageshack.us/my.php?image=neatpad01agi8.png

and this one built with D - notice small 1px trashed area under menu:
http://img223.imageshack.us/my.php?image=neatpad01md7.png

Seems window menu bar do not fill entire area, it should do. But I can't 
understand why - This is not ownerdrawn menu, I'm do not have any 
control on how it draws.

I could accept that this yet another problem I should solve, but why it 
manifest itself only when built with D?

Again - I ported code from C++ to D with minimal changes required, all 
drawing routines are identical with original.

source code attached. (I have to use 7zip to fit)

Thanks
-- 
serg.
Aug 21 2006
next sibling parent reply kris <foo bar.com> writes:
Serg Kovrov wrote:
 Greetings everybody,
 
 I have ported extremely simple win32 gui example (one of catch22.net 
 tutorials), and run into strange problem - when built with D, program 
 drawing routine behaves slightly different from original. regardless 
 that code almost identical. I suppose it is related to non-client 
 drawing of frame window.
 
 Please see screenshots:
 
 This is how it should look (and actually do look so when built with VC++ 
 or MinGW):
 http://img245.imageshack.us/my.php?image=neatpad01agi8.png
 
 and this one built with D - notice small 1px trashed area under menu:
 http://img223.imageshack.us/my.php?image=neatpad01md7.png
 
 Seems window menu bar do not fill entire area, it should do. But I can't 
 understand why - This is not ownerdrawn menu, I'm do not have any 
 control on how it draws.
 
 I could accept that this yet another problem I should solve, but why it 
 manifest itself only when built with D?
 
 Again - I ported code from C++ to D with minimal changes required, all 
 drawing routines are identical with original.
 
 source code attached. (I have to use 7zip to fit)
 
 Thanks
IIRC that's related to a Win32 version identifier in the executable? Build.exe has a flag for changing that, and there's some way of creating a .def file for executables build with dmd also (some details in the online dmd doc). Try using google to search digitalmars.com? I know there was a thread on this at one point. Sorry I don't have more detail to hand.
Aug 21 2006
parent kris <foo bar.com> writes:
kris wrote:
 Serg Kovrov wrote:
 
 Greetings everybody,

 I have ported extremely simple win32 gui example (one of catch22.net 
 tutorials), and run into strange problem - when built with D, program 
 drawing routine behaves slightly different from original. regardless 
 that code almost identical. I suppose it is related to non-client 
 drawing of frame window.

 Please see screenshots:

 This is how it should look (and actually do look so when built with 
 VC++ or MinGW):
 http://img245.imageshack.us/my.php?image=neatpad01agi8.png

 and this one built with D - notice small 1px trashed area under menu:
 http://img223.imageshack.us/my.php?image=neatpad01md7.png

 Seems window menu bar do not fill entire area, it should do. But I 
 can't understand why - This is not ownerdrawn menu, I'm do not have 
 any control on how it draws.

 I could accept that this yet another problem I should solve, but why 
 it manifest itself only when built with D?

 Again - I ported code from C++ to D with minimal changes required, all 
 drawing routines are identical with original.

 source code attached. (I have to use 7zip to fit)

 Thanks
IIRC that's related to a Win32 version identifier in the executable? Build.exe has a flag for changing that, and there's some way of creating a .def file for executables build with dmd also (some details in the online dmd doc). Try using google to search digitalmars.com? I know there was a thread on this at one point. Sorry I don't have more detail to hand.
http://www.digitalmars.com/d/archives/c++/windows/32-bits/541.html There were others too, but I must be looking in the wrong place. Anyone else?
Aug 21 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 22 Aug 2006 04:38:57 +0300, Serg Kovrov wrote:

 Greetings everybody,
 
 I have ported extremely simple win32 gui example (one of catch22.net 
 tutorials), and run into strange problem - when built with D, program 
 drawing routine behaves slightly different from original. regardless 
 that code almost identical. I suppose it is related to non-client 
 drawing of frame window.
 
 Please see screenshots:
 
 This is how it should look (and actually do look so when built with VC++ 
 or MinGW):
 http://img245.imageshack.us/my.php?image=neatpad01agi8.png
 
 and this one built with D - notice small 1px trashed area under menu:
 http://img223.imageshack.us/my.php?image=neatpad01md7.png
I believe this is a Windows bug. It happens when your .exe is generated without specifying a modern Windows version. Ensure your .def file for the project has the two lines ... EXETYPE NT SUBSYSTEM WINDOWS,5.0 -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 22/08/2006 11:53:26 AM
Aug 21 2006
parent Serg Kovrov <kovrov no.spam> writes:
Derek Parnell wrote:
 I believe this is a Windows bug. It happens when your .exe is generated
 without specifying a modern Windows version. Ensure your .def file for the
 project has the two lines ...
 
 EXETYPE NT
 SUBSYSTEM WINDOWS,5.0
Thank you, Derek. This is solve the problem. Windows version could be 4.0. It can be also used as linker switch /SU:windows:5.0 (or 4.0) There is a note on SUBSYSTEM directive (http://digitalmars.com/ctg/ctgDefFiles.html#subsystem), said "Use 4.0 when developing Windows XP applications." But I never thought it could be related to this issue. Actually I still have no idea what this directive/switch do. -- serg.
Aug 22 2006