Re: [XaraXtreme-dev] Re: wxCamDraw painting errors in Align Dialog, was wxCamDrawControl creation error in align dialog & broken build

[Alex Bligh <alex@xxxxxxxxxxx>]

Mark,


> > This is /your/ dialog I take it. Difficult to debug without the code!
>
>
> Nope - the Align dialog shows that way ! Look the attached image.

That's bizarre. I don't see them that way and I don't think anyone
else does. Could you please download the current retail build (the
binary) from the web site and try that and we can try and narrow
down whether it is a compiler difference or something else.

> > Do the DialogDraw demo, the align dialog, and the galleries work
> > on your copy? DialogDraw and the align dialog use GRenderRegion,
> > and the galleries use OSRenderRegion to draw the wxCamDrawControl.
> > With such extensive use I doubt it is /fundamentally/ broken. I
> > could well have broken something though I suppose.
>
> Ok, I'll test DialogDraw and let you know, galleries seem to render ok.

That would be helpful. As I say, Galleries use OSRenderRegion rather than
GRenderRegion. They also use sizers to control the size of the
wxCamDrawControl rather than having it hard-coded (as do the other two).

It could be that the align dialog is (somehow!) reading the sizer info
wrong, and rendering into too small an area. Or it could be some more
fundamental bug to do with the construction of the GRenderRegion.

I take it this appears if you just load the program, do "New Document" draw
a rectangle, then bring up the align dialog?

Can you give me a wxWidgets version and a C Compiler version?

Does an unmodified version built locally do that?

> > > If I close the dialog, the program
> >
> > > crashes with a segmentation fault in the DialogManager::Close
> > > function here:
> > >
> > > *if* (pDlgOp->pEvtHandler->wxAUImanaged)
> > >
> > > with the application message: 'GDK_IS_WINDOW(window)' failed. The gcc
> > > version I'm using is 3.4.4. If you want other information or a
> > > screenshots - just tell me, I will send it to you. Gerry BTW is right -
> > > I'm building it with x86_64 on AMD Athlon 64.
> >
> >
> > That normally indicates you have tried to double destroy the dialog.
> > When you say "if I close the dialog" what are you doing to close it?
>
>
> If I close the Align Dialog hitting the close button - it crashed, but
> this seems to go away it the latest build.

OK I can tell you what that is with 99.99% accuracy. First, go get
the (very) latest build - last night's - and I put in some magical
ERROR3 code which will go off. What is happening is your kernel
message handler is calling End() on the Op (which does a "delete
this" making the pointer to the object itself unsafe), then goes on
to pass the message to the default DialogOp message handler. Besides
being unsafe, this is a bad thing to do because the default message
handler also processes the message, and thus double-deletes the
dialog. What the default handler is doing is trying to tell each
control in the box that the box has died (and it should do any
clearup) through a kernel message. This may or may not be necessary.

So you have a choice to as to how to End() your dialog. Either pass
a DIM_CANCEL or DIM_COMMIT to the base-class message handler OR
call "Close(); End();" yourself BUT then do a "return OK;". DO NOT
do both. Your dialog is doing both (as several did in Camelot and
only worked by complete chance).

I've fixed up the Align dialog and any others I could find, and
the ERROR3 in the debug build will now tell you exactly what's
happened, every time, consistently (it used to not do this
as a side effect of some memory clearing on delete we were doing).

Alex