www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - The Docs told old things

reply 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.
May 08 2004
parent reply "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?
May 08 2004
next sibling parent reply 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: 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
May 08 2004
parent "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



 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: 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.
May 09 2004
prev sibling parent reply 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?

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?
May 09 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Patrick Down wrote:
 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
May 09 2004
parent Patrick Down <pat codemoon.com> writes:
Andy Friesen <andy ikagames.com> wrote in news:c7lvbu$2oci$1
 digitaldaemon.com:

 Patrick Down wrote:
 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.
May 09 2004