plib-users

[Plib-users] RE: Crash while deleting puDialogBox... access violation

[McEvoy, N. <nic...@ds...>]

Ralf Pietersz wrote:
>I have a strange crash I dont really understand...
>If there is anyone that has experienced something similar and knows a
>solution please speak up. :)
>Basicly, I create a dialogbox, and close it when the callback for the
>button inside it is called.
>Once it closes I get a crash, access violation.
>Traceback:
>puOneShot::doHit(int 0, int 1, int 243, int 34) line 33 + 12 bytes
>puObject::checkHit(int 0, int 1, int 243, int 34) line 508 + 29 bytes
>puGroup::checkHit(int 0, int 1, int 243, int 34) line 212 + 29 bytes
>puMouse(int 0, int 1, int 394, int 316) line 378 + 42 bytes
>mouse(int 0, int 1, int 394, int 316) line 1004 + 21 bytes
>FREEGLUT! 0089661d()
<snip>

I've only just started using the pui ... so I'm no expert
(although I've been using plib for years) ... but I do remember
I had a similar problem as you describe.

What I found was that the puMouse(button, state, x, y) callback
was arriving after dialog was deleted !?

I'm not sure if it was a timing issue in my code, or a bug in the
pui ... where maybe it doesn't correctly check if the dialog exists
when checking hits (if I remember correctly it seemed to happen on
the mouse up event).

In my case *maybe* it was a timing issue (but I'm not convinced yet)
... I changed my code as follows to delete the dialog after an
intensive load operation (and a redraw ... maybe the redraw is the
solution ... I'm just guessing here):

on mouse down:
- closed & deleted dialog
- loaded level (+ redraw)
- crash occurred (similar to your description)

on mouse down:
- hide dialog
- loaded level (+ redraw)
- deleted dialog
- no problems

Sorry I can't be more helpful than that.  Let us know what you find.

>Do I need to tell PUI I am deleting that dialogbox AND the buttons
>inside it??
>Clean something up? Pop some interface from the stack??

No, I don't think so.

Nick

[Plib-users] RE: Crash while deleting puDialogBox... access violation

[McEvoy, N. <nic...@ds...>]

Ralf Pietersz wrote:
>I am certain its a bug in PUI or a real bad design decision.
>I wasnt able to delete the dialogbox in the callback, whatever I tried.
>But then, where else should I delete it if not in the callback?

I know this is not ideal ... but as a temporary fix ... you could hide
the dialog, in the callback, instead of deleting it.


>The redraw doesnt help for me.... my problem is that its only a
>noticebox,
>so there is no time being used in between, but anyway having the app
>rely on
>a fulfilled race condition is really bad anyway.

Yes, I agree.  That's what I'm worried about in my app ... it works ... but
in the back of my mind I know a bug lurks.  I hate that !  :)


>Still didnt get it to work... I think someone who REALLY knows (like the
>developer who
>wrote it :P) needs to tell us what its doing and why... they should
>know...
>Searching through the code didnt help me at all, whatever its doing must
>be hidden somewhere.

Yes, I suggest take your problem to the devel list.  Someone there (ie. the
pui author) should be more helpful.


>I was trying to pop the dialogbox from the stack but it still gets the
>mouse event and crashes.
>I dont know what else I can do to persuade PUI that I REALLY deleted it.
>:P
>It doesnt say anywhere in the docs how the deletion works, but somehow
>the example apps seem to
>work... really weird.

Damn, I hate it when the example works ... but then crashes in your own
framework.  Happens to me all the time. :)

What you need is a simple example that demonstrates the problem.

Cya,
Nick

RE: [Plib-users] RE: Crash while deleting puDialogBox... access violation

[SkyFlash <sky...@ch...>]

> What I found was that the puMouse(button, state, x, y) 
> callback was arriving after dialog was deleted !?

Yes, thats the same I am seeing, and I dont know why.

> I'm not sure if it was a timing issue in my code, or a bug in 
> the pui ... where maybe it doesn't correctly check if the 
> dialog exists when checking hits (if I remember correctly it 
> seemed to happen on the mouse up event).

I am certain its a bug in PUI or a real bad design decision.
I wasnt able to delete the dialogbox in the callback, whatever I tried.
But then, where else should I delete it if not in the callback?

> In my case *maybe* it was a timing issue (but I'm not 
> convinced yet) ... I changed my code as follows to delete the 
> dialog after an intensive load operation (and a redraw ... 
> maybe the redraw is the solution ... I'm just guessing here):

The redraw doesnt help for me.... my problem is that its only a
noticebox,
so there is no time being used in between, but anyway having the app
rely on
a fulfilled race condition is really bad anyway.

> Sorry I can't be more helpful than that.  Let us know what you find.

Still didnt get it to work... I think someone who REALLY knows (like the
developer who
wrote it :P) needs to tell us what its doing and why... they should
know...
Searching through the code didnt help me at all, whatever its doing must
be hidden somewhere.

> >Do I need to tell PUI I am deleting that dialogbox AND the buttons 
> >inside it?? Clean something up? Pop some interface from the stack??
> 
> No, I don't think so.

I was trying to pop the dialogbox from the stack but it still gets the
mouse event and crashes.
I dont know what else I can do to persuade PUI that I REALLY deleted it.
:P
It doesnt say anywhere in the docs how the deletion works, but somehow
the example apps seem to
work... really weird.

Ralf Pietersz