Thread overview
The Docs told old things
May 08, 2004
School
May 09, 2004
Walter
May 09, 2004
J C Calvarese
May 09, 2004
Phill
May 09, 2004
Patrick Down
May 09, 2004
Andy Friesen
May 09, 2004
Patrick Down
May 08, 2004
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 09, 2004
"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 09, 2004
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
May 09, 2004
"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.



May 09, 2004
"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?

May 09, 2004
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
May 09, 2004
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.