digitalmars.D.dwt - window menu drawing different in D and in VC++/MinGW
- Serg Kovrov (23/23) Aug 21 2006 Greetings everybody,
- kris (7/37) Aug 21 2006 IIRC that's related to a Win32 version identifier in the executable?
- kris (4/45) Aug 21 2006 http://www.digitalmars.com/d/archives/c++/windows/32-bits/541.html
- Derek Parnell (12/28) Aug 21 2006 I believe this is a Windows bug. It happens when your .exe is generated
- Serg Kovrov (11/17) Aug 22 2006 Thank you, Derek.
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
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) ThanksIIRC 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
kris wrote:Serg Kovrov wrote: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?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) ThanksIIRC 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
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.pngI 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
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.0Thank 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