• School (7/7) May 08 2004 http://www.digitalmars.com/d/windows.html
• Walter (4/11) May 08 2004 Thanks, fixed.
• J C Calvarese (13/25) May 08 2004 I'd bet he's talking about:
• Phill (19/48) May 09 2004 in
• Patrick Down (10/14) May 09 2004 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/57
• Andy Friesen (4/15) May 09 2004 Maybe it has to do with the user32.lib being linked in. Tried
• Patrick Down (9/27) May 09 2004 It's a good idea Andy. There are really three variables in the

School <itsnotvalid-news yahoo.com.hk> writes:

http://www.digitalmars.com/d/windows.html

If you follow the instruction out there, you would be told that casting
in the code is:
'''C style cast deprecated, use cast(char*)(o.toString())'''
It's actually a new thing introduced in DMD 0.88.

Also note that the problem of GUI generation problem as I pointed out in
DMD 0.86 for Windows XP /w modern GUI is still there.

"Walter" <newshound digitalmars.com> writes:

"School" <itsnotvalid-news yahoo.com.hk> wrote in message
news:c7i83s$go5$1 digitaldaemon.com...
 http://www.digitalmars.com/d/windows.html

 If you follow the instruction out there, you would be told that casting
 in the code is:
 '''C style cast deprecated, use cast(char*)(o.toString())'''
 It's actually a new thing introduced in DMD 0.88.

Thanks, fixed.

 Also note that the problem of GUI generation problem as I pointed out in
 DMD 0.86 for Windows XP /w modern GUI is still there.

Can you reference the posting for this please?

J C Calvarese <jcc7 cox.net> writes:

In article <c7kcj4$fk0$1 digitaldaemon.com>, Walter says...
"School" <itsnotvalid-news yahoo.com.hk> wrote in message
news:c7i83s$go5$1 digitaldaemon.com...
 http://www.digitalmars.com/d/windows.html

 If you follow the instruction out there, you would be told that casting
 in the code is:
 '''C style cast deprecated, use cast(char*)(o.toString())'''
 It's actually a new thing introduced in DMD 0.88.

Thanks, fixed.

 Also note that the problem of GUI generation problem as I pointed out in
 DMD 0.86 for Windows XP /w modern GUI is still there.

Can you reference the posting for this please?

I'd bet he's talking about:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/57

"I have a D Windows GUI program that that I have written.  
It works ok except that it has a small rendering problem 
when run under Windows XP.  It has a small 1 pixel line 
directly under the menu that is not rendered so that 
whatever is behind the window shows through.  (See attached 
PNG file)  Now this line does not show up in Window 2K nor
does it show up in Windows XP if you run XP with the "classic"
style UI.  It only shows up if you run the program in XP
with the standard XP style UI."

JC

"Phill" <phill pacific.net.au> writes:

"J C Calvarese" <jcc7 cox.net> wrote in message
news:c7kf3a$j3e$1 digitaldaemon.com...
 In article <c7kcj4$fk0$1 digitaldaemon.com>, Walter says...
"School" <itsnotvalid-news yahoo.com.hk> wrote in message
news:c7i83s$go5$1 digitaldaemon.com...
 http://www.digitalmars.com/d/windows.html

 If you follow the instruction out there, you would be told that casting
 in the code is:
 '''C style cast deprecated, use cast(char*)(o.toString())'''
 It's actually a new thing introduced in DMD 0.88.

Thanks, fixed.

 Also note that the problem of GUI generation problem as I pointed out



in
 DMD 0.86 for Windows XP /w modern GUI is still there.

Can you reference the posting for this please?

 I'd bet he's talking about:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/57

 "I have a D Windows GUI program that that I have written.
 It works ok except that it has a small rendering problem
 when run under Windows XP.  It has a small 1 pixel line
 directly under the menu that is not rendered so that
 whatever is behind the window shows through.  (See attached
 PNG file)  Now this line does not show up in Window 2K nor
 does it show up in Windows XP if you run XP with the "classic"
 style UI.  It only shows up if you run the program in XP
 with the standard XP style UI."

I have XP and I have this line in C++ GUI's (using MFC)
and also D.
I have Walter's C++ IDE and I only get this line in my
GUI when either "Windows NT'  or "Win32's" executable
are selected in Project -> settings.
I dont get this line when either "Windows 95" or
"Windows 3.1" are selected in Project -> settings.

The weirdest thing that I find is that if you drag and move the GUI, it
remebers what was behind it before you moved it. Therefore it is not really
transparent, its like
a snapshot of that particular pixel on the screen that
remains on the GUI no matter where you move it.
But if you minimize or maximize the GUI it repaints and
you get the different pixel line which will stay untill it is repainted
again(even if you drag the GUI around).

Phill.

Patrick Down <pat codemoon.com> writes:

"Walter" <newshound digitalmars.com> wrote in news:c7kcj4$fk0$1
 digitaldaemon.com:

 Also note that the problem of GUI generation problem as I pointed out in
 DMD 0.86 for Windows XP /w modern GUI is still there.

 
 Can you reference the posting for this please?


http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/57

However here is the most important point:

winsamp.d with dmd has the problem
winsamp.cpp with dmc has the problem
winsamp.cpp with VC++ does not have the problem

What is the difference between Digital Mars's code
generation and MSVC++'s code generation that causes
this?  

Andy Friesen <andy ikagames.com> writes:

Patrick Down wrote:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/57
 
 However here is the most important point:
 
 winsamp.d with dmd has the problem
 winsamp.cpp with dmc has the problem
 winsamp.cpp with VC++ does not have the problem
 
 What is the difference between Digital Mars's code
 generation and MSVC++'s code generation that causes
 this?  

Maybe it has to do with the user32.lib being linked in.  Tried 
implibbing user32.dll and linking that instead?

  -- andy

Patrick Down <pat codemoon.com> writes:

Andy Friesen <andy ikagames.com> wrote in news:c7lvbu$2oci$1
 digitaldaemon.com:

 Patrick Down wrote:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/57
 
 However here is the most important point:
 
 winsamp.d with dmd has the problem
 winsamp.cpp with dmc has the problem
 winsamp.cpp with VC++ does not have the problem
 
 What is the difference between Digital Mars's code
 generation and MSVC++'s code generation that causes
 this?  

 
 Maybe it has to do with the user32.lib being linked in.  Tried 
 implibbing user32.dll and linking that instead?
 
   -- andy
 

It's a good idea Andy.  There are really three variables in the
equation.

1. The headers
2. The libraries
3. The compiler

I doubt that the headers are a problem but the libraries could
be.