www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Pointers, casting, SetGetWindowLong problem...

reply "Chris Warwick" <sp m.me.not> writes:
Hi, i use this to create and show my window

            HINSTANCE hinstance = GetModuleHandleA(null);
            fhandle = CreateWindowExA(
                WS_EX_APPWINDOW, "CjWindow", "Testing 123", WS_TILEDWINDOW,
                x, y, width, height, HWND_DESKTOP, cast(HMENU) null,
                hinstance, null);
            SetWindowLongA(fhandle, 0, cast(LONG) cast(VOID*) this);
            ShowWindow(fhandle, SW_SHOW);

And this in my WindowProc

    TWindow window = cast(TWindow) cast(void*)  GetWindowLongA(handle, 0);
    if (window == null)  return DefWindowProcA(handle, msg, wparam, lparam);

but i keep getting an access violation on the if (window == null),

if i change it to

    if (window == null) beep(400,50)

i still get it, the AV that is, but if i just skip the check and call the
DefWindoProcA it works fine.

I cant work out why, even if i have fecked up the casting or setting of the
the windowLong var, testing what was returned against null shouldnt cause an
AV should it?

Anycase, any ideas what I've done wrong?

cheers,

cw
Mar 09 2007
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 9 Mar 2007 23:16:34 -0000, Chris Warwick wrote:



     TWindow window = cast(TWindow) cast(void*)  GetWindowLongA(handle, 0);
     if (window == null)  return DefWindowProcA(handle, msg, wparam, lparam);
 
 but i keep getting an access violation on the if (window == null),
 
 if i change it to
 
     if (window == null) beep(400,50)
 
 i still get it, the AV that is, but if i just skip the check and call the
 DefWindoProcA it works fine.


Use this instead ...

    if (window is null) ...

Because ...

    if (window == null)

is identical to 

    if (window.opEquals(null))

which will fail if 'window' is null because it needs to use it to reference
the opEquals method.


-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Mar 09 2007
parent reply "Chris Warwick" <sp m.me.not> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1f2c01vt6zeaq$.ac8d0velaphe$.dlg 40tude.net...

 On Fri, 9 Mar 2007 23:16:34 -0000, Chris Warwick wrote:



     TWindow window = cast(TWindow) cast(void*)  GetWindowLongA(handle, 
 0);
     if (window == null)  return DefWindowProcA(handle, msg, wparam, 
 lparam);

 but i keep getting an access violation on the if (window == null),

 if i change it to

     if (window == null) beep(400,50)

 i still get it, the AV that is, but if i just skip the check and call the
 DefWindoProcA it works fine.


 Use this instead ...

    if (window is null) ...

 Because ...

    if (window == null)

 is identical to

    if (window.opEquals(null))

 which will fail if 'window' is null because it needs to use it to 
 reference
 the opEquals method.


So opEquals must be inherited from Object cause I havnt implememented it in 
my class. So what exactly does this inherited opEquals do? How can an 
inherited opEquals have any sensible result in descendant classes unless 
overriden by those subclasses?

cheers,

cw
Mar 09 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Warwick wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1f2c01vt6zeaq$.ac8d0velaphe$.dlg 40tude.net...

 On Fri, 9 Mar 2007 23:16:34 -0000, Chris Warwick wrote:


     if (window == null)  return DefWindowProcA(handle, msg, wparam, 
 lparam);

 but i keep getting an access violation on the if (window == null),


 Use this instead ...

    if (window is null) ...

 Because ...

    if (window == null)

 is identical to

    if (window.opEquals(null))

 which will fail if 'window' is null because it needs to use it to 
 reference
 the opEquals method.


 
 So opEquals must be inherited from Object cause I havnt implememented it in 
 my class. So what exactly does this inherited opEquals do? How can an 
 inherited opEquals have any sensible result in descendant classes unless 
 overriden by those subclasses?


Ironically, it returns the result of "this is other" :P.
Unfortunately, execution never gets that far when the left-hand side of 
'==' actually *is* null...
But yes, that method is indeed meant to be overridden by most classes 
that want to be equality-comparable.
Mar 09 2007
parent reply "Chris Warwick" <sp m.me.not> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:est2j6$1f2d$1 digitalmars.com...

 Chris Warwick wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1f2c01vt6zeaq$.ac8d0velaphe$.dlg 40tude.net...

 On Fri, 9 Mar 2007 23:16:34 -0000, Chris Warwick wrote:


     if (window == null)  return DefWindowProcA(handle, msg, wparam, 
 lparam);

 but i keep getting an access violation on the if (window == null),


 Use this instead ...

    if (window is null) ...

 Because ...

    if (window == null)

 is identical to

    if (window.opEquals(null))

 which will fail if 'window' is null because it needs to use it to 
 reference
 the opEquals method.


 So opEquals must be inherited from Object cause I havnt implememented it 
 in my class. So what exactly does this inherited opEquals do? How can an 
 inherited opEquals have any sensible result in descendant classes unless 
 overriden by those subclasses?


 Ironically, it returns the result of "this is other" :P.
 Unfortunately, execution never gets that far when the left-hand side of 
 '==' actually *is* null...
 But yes, that method is indeed meant to be overridden by most classes that 
 want to be equality-comparable.


Seems odd that it's even implemented at all, = is not overloadable if i 
understood the docs right, and I cant see add or sub being overloaded in 
Object.. So why implement opEquals? Especialy when it's basicly worse than 
(obj1 is obj2).

Unless it's a cunning ploy, using AV faults to cattle prod people into using 
'is'.
Mar 09 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Warwick" <sp m.me.not> wrote in message 
news:est492$1igu$1 digitalmars.com...

 Seems odd that it's even implemented at all, = is not overloadable if i 
 understood the docs right,


Nope, it's assignable with opAssign.  There are restrictions, but it can be 
overloaded.


 and I cant see add or sub being overloaded in Object.. So why implement 
 opEquals? Especialy when it's basicly worse than (obj1 is obj2).


It's implemented for associative arrays to work properly.


 Unless it's a cunning ploy, using AV faults to cattle prod people into 
 using 'is'.


Well == and 'is' have two entirely different purposes.  == is only for 
seeing if two things have the same _value_, while 'is' is used to see if 
_two references point to the same instance_.  == is perfectly fine to use on 
class instances -- as long as they're not null!  It's just like any other 
method.
Mar 09 2007
parent reply "Chris Warwick" <sp m.me.not> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:est9bb$1pac$1 digitalmars.com...

 "Chris Warwick" <sp m.me.not> wrote in message 
 news:est492$1igu$1 digitalmars.com...

 Seems odd that it's even implemented at all, = is not overloadable if i 
 understood the docs right,


 Nope, it's assignable with opAssign.  There are restrictions, but it can 
 be overloaded.


For objects? Wouldnt that make assigning to a null object imposible?

MyObj obj = obj2;

if opAssign is overloaded that will always be

null.opAssign(obj2);

wont it?



 and I cant see add or sub being overloaded in Object.. So why implement 
 opEquals? Especialy when it's basicly worse than (obj1 is obj2).


 It's implemented for associative arrays to work properly.


 Unless it's a cunning ploy, using AV faults to cattle prod people into 
 using 'is'.


 Well == and 'is' have two entirely different purposes.  == is only for 
 seeing if two things have the same _value_, while 'is' is used to see if 
 _two references point to the same instance_.  == is perfectly fine to use 
 on class instances -- as long as they're not null!  It's just like any 
 other method.


Just feels kinda wrong to me. Objects are referance types, passed by, and 
managed by referance, so imo == and = should test and assign referance not 
value.

Although i guess it does seem logical to make a clearer distinction between 
equality and identity, so maybe ill get used to it.

cheers,

cw
Mar 10 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Warwick wrote:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:est9bb$1pac$1 digitalmars.com...

 Nope, it's assignable with opAssign.  There are restrictions, but it can 
 be overloaded.


 
 For objects? Wouldnt that make assigning to a null object imposible?
 
 MyObj obj = obj2;
 
 if opAssign is overloaded that will always be
 
 null.opAssign(obj2);
 
 wont it?


No, one of the restrictions Jarrett mentioned is that an overloaded 
opAssign is only invoked if the type of the value assigned is different 
from the type of the variable it's assigned to.
If they have the same type (or the assigned value is implicitly 
convertible to the type of the variable) the user-defined opAssign isn't 
used.
Mar 10 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Warwick" <sp m.me.not> wrote in message 
news:esu8ah$4uj$1 digitalmars.com...

 Just feels kinda wrong to me. Objects are referance types, passed by, and 
 managed by referance, so imo == and = should test and assign referance not 
 value.


= does assign reference, except if opAssign is overloaded (I don't like 
opAssign with classes for that reason; for structs it makes more sense). 
The nice thing about having '==' vs. 'is' for reference types is that you 
don't have to write

if(obj1.equals(obj2))
    // ...

like in certain other languages.

On a side note, I just like the way 'is' reads more than '=='.  And you can 
even use it with non-reference types, where it acts just like '==', so you 
can write things like

if(x is 5)

Which just looks great IMO :)
Mar 10 2007
prev sibling next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Warwick wrote:

 
     TWindow window = cast(TWindow) cast(void*)  GetWindowLongA(handle, 0);
     if (window == null)  return DefWindowProcA(handle, msg, wparam, lparam);
 


[snip]

 
 I cant work out why, even if i have fecked up the casting or setting of the
 the windowLong var, testing what was returned against null shouldnt cause an
 AV should it?


Actually, the test is *exactly* what's causing this.
Comparing class references (including null, if the type is a class type) 
is done by calling a member function on the left operand with the right 
operand as a parameter (in this case, window.opEquals(null)). To call 
opEquals, the vtable pointer needs to be found, which produces an access 
violation for null references (since it needs to dereference the 
reference to get at the vtable pointer).

What you want to do is not test equality, but testing identity. For 
that, replace '==' by 'is':
---
     TWindow window = /* whatever */;
     if (window is null)  /* something */;
---
should do what you want.
Mar 09 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Warwick wrote:

 Hi, i use this to create and show my window
 
             HINSTANCE hinstance = GetModuleHandleA(null);
             fhandle = CreateWindowExA(
                 WS_EX_APPWINDOW, "CjWindow", "Testing 123", WS_TILEDWINDOW,
                 x, y, width, height, HWND_DESKTOP, cast(HMENU) null,
                 hinstance, null);
             SetWindowLongA(fhandle, 0, cast(LONG) cast(VOID*) this);
             ShowWindow(fhandle, SW_SHOW);
 
 And this in my WindowProc
 
     TWindow window = cast(TWindow) cast(void*)  GetWindowLongA(handle, 0);
     if (window == null)  return DefWindowProcA(handle, msg, wparam, lparam);
 
 but i keep getting an access violation on the if (window == null),
 
 if i change it to
 
     if (window == null) beep(400,50)
 
 i still get it, the AV that is, but if i just skip the check and call the
 DefWindoProcA it works fine.
 
 I cant work out why, even if i have fecked up the casting or setting of the
 the windowLong var, testing what was returned against null shouldnt cause an
 AV should it?
 
 Anycase, any ideas what I've done wrong?
 
 cheers,
 
 cw
 
 



This is definitely an F.A.Q.
Is there a D Programming FAQ anywhere?
'Why does "if (someobject == null)" keep crashing?' would definitely be 
there.
What else?

--bb
Mar 09 2007
next sibling parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
Bill Baxter wrote:

 This is definitely an F.A.Q.
 Is there a D Programming FAQ anywhere?
 'Why does "if (someobject == null)" keep crashing?' would definitely be 
 there.
 What else?
 
 --bb


I've started recording "surprises" like these on a Web page here: 
http://www.baysmith.com/d/

   Bradley
Mar 09 2007
next sibling parent reply torhu <fake address.dude> writes:
Bradley Smith wrote:

 I've started recording "surprises" like these on a Web page here: 
 http://www.baysmith.com/d/


That's a good idea, but I see a couple of errors on that page.

At the bottom: "crashes because null not evaluated as false".  null does 
evaluate to false.  The reason it crashes is that assert(obj) doesn't 
check for null, it just calls the class invariant. 
http://www.digitalmars.com/d/class.html#invariants

And "Don't use == to compare with null" can be a bit misleading.  If the 
object has an opEquals defined that takes a reference as an argument, 
you would actually "use == to compare with null".  Maybe if it said 
"Don't use == to check if a reference is null".

But it's a nice initiative nevertheless.  The official docs are a bit 
unclear on many issues.
Mar 10 2007
parent Bradley Smith <digitalmars-com baysmith.com> writes:
torhu wrote:

 Bradley Smith wrote:

 I've started recording "surprises" like these on a Web page here: 
 http://www.baysmith.com/d/


 
 That's a good idea, but I see a couple of errors on that page.
 
 At the bottom: "crashes because null not evaluated as false".  null does 
 evaluate to false.  The reason it crashes is that assert(obj) doesn't 
 check for null, it just calls the class invariant. 
 http://www.digitalmars.com/d/class.html#invariants
 
 And "Don't use == to compare with null" can be a bit misleading.  If the 
 object has an opEquals defined that takes a reference as an argument, 
 you would actually "use == to compare with null".  Maybe if it said 
 "Don't use == to check if a reference is null".
 
 But it's a nice initiative nevertheless.  The official docs are a bit 
 unclear on many issues.


Thanks for the feedback. I've updated these points.
Mar 10 2007
prev sibling parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sat, 10 Mar 2007 03:06:46 +0200, Bradley Smith  =

<digitalmars-com baysmith.com> wrote:


 Bill Baxter wrote:

 This is definitely an F.A.Q.
 Is there a D Programming FAQ anywhere?
 'Why does "if (someobject =3D=3D null)" keep crashing?' would definit=




ely be  =


 there.
 What else?
  --bb


 I've started recording "surprises" like these on a Web page here:  =



 http://www.baysmith.com/d/

    Bradley



The comment of the following line:

   ContainsResource res1; //  Error: variable scope.main.res1 reference =
to  =

auto class must be auto

uses the 'auto' keyword instead of 'scope'.

(Or is the error message of the compiler out of date?)
Mar 10 2007
parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
Kristian Kilpi wrote:

 On Sat, 10 Mar 2007 03:06:46 +0200, Bradley Smith 
 <digitalmars-com baysmith.com> wrote:


 I've started recording "surprises" like these on a Web page here: 
 http://www.baysmith.com/d/

    Bradley


 
 
 The comment of the following line:
 
   ContainsResource res1; //  Error: variable scope.main.res1 reference 
 to auto class must be auto
 
 uses the 'auto' keyword instead of 'scope'.
 
 (Or is the error message of the compiler out of date?)



Perhaps, but the above is the error message from DMD v1.007.
Mar 10 2007
parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sat, 10 Mar 2007 22:58:02 +0200, Bradley Smith  
<digitalmars-com baysmith.com> wrote:


 Kristian Kilpi wrote:

 On Sat, 10 Mar 2007 03:06:46 +0200, Bradley Smith  
 <digitalmars-com baysmith.com> wrote:


  >

 I've started recording "surprises" like these on a Web page here:  
 http://www.baysmith.com/d/

    Bradley


   The comment of the following line:
    ContainsResource res1; //  Error: variable scope.main.res1 reference  
 to auto class must be auto
  uses the 'auto' keyword instead of 'scope'.
  (Or is the error message of the compiler out of date?)



 Perhaps, but the above is the error message from DMD v1.007.


Ok, when the 'auto' keyword was changed to 'scope', the error message
(at least this one) wasn't updated. I wonder if Walter knows about it.
Mar 11 2007
prev sibling parent reply "Chris Warwick" <sp m.me.not> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:essrhi$vgr$1 digitalmars.com...

 Chris Warwick wrote:

 Hi, i use this to create and show my window

             HINSTANCE hinstance = GetModuleHandleA(null);
             fhandle = CreateWindowExA(
                 WS_EX_APPWINDOW, "CjWindow", "Testing 123", 
 WS_TILEDWINDOW,
                 x, y, width, height, HWND_DESKTOP, cast(HMENU) null,
                 hinstance, null);
             SetWindowLongA(fhandle, 0, cast(LONG) cast(VOID*) this);
             ShowWindow(fhandle, SW_SHOW);

 And this in my WindowProc

     TWindow window = cast(TWindow) cast(void*)  GetWindowLongA(handle, 
 0);
     if (window == null)  return DefWindowProcA(handle, msg, wparam, 
 lparam);

 but i keep getting an access violation on the if (window == null),

 if i change it to

     if (window == null) beep(400,50)

 i still get it, the AV that is, but if i just skip the check and call the
 DefWindoProcA it works fine.

 I cant work out why, even if i have fecked up the casting or setting of 
 the
 the windowLong var, testing what was returned against null shouldnt cause 
 an
 AV should it?

 Anycase, any ideas what I've done wrong?

 cheers,

 cw



 This is definitely an F.A.Q.
 Is there a D Programming FAQ anywhere?
 'Why does "if (someobject == null)" keep crashing?' would definitely be 
 there.


It would certainly help if this was mentioned in the docs section on 
classes.

cheers,

cw
Mar 09 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Warwick wrote:

 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:essrhi$vgr$1 digitalmars.com...



 This is definitely an F.A.Q.
 Is there a D Programming FAQ anywhere?
 'Why does "if (someobject == null)" keep crashing?' would definitely be 
 there.


 
 It would certainly help if this was mentioned in the docs section on 
 classes.


It does now.  :-)  At least on the comments page.

--bb
Mar 09 2007