• Serg Kovrov <kovrov no.spam> Aug 21 2006
• kris <foo bar.com> Aug 21 2006
• kris <foo bar.com> Aug 21 2006
• Derek Parnell <derek nomail.afraid.org> Aug 21 2006
• Serg Kovrov <kovrov no.spam> Aug 22 2006

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.

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?

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

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.