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),

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),

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);
 

 
 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=


 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

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