Thread overview
window menu drawing different in D and in VC++/MinGW
Aug 22, 2006
Serg Kovrov
Aug 22, 2006
kris
Aug 22, 2006
kris
Aug 22, 2006
Derek Parnell
Aug 22, 2006
Serg Kovrov
August 22, 2006
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.


August 22, 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)
> 
> 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.
August 22, 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.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
August 22, 2006
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?
August 22, 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.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.