Getting crash when drawing from TextArea into Listbox Cell graphics

So, I want to draw styled text into a Listbox cell.

I have working code that renders the StyledText via a TextArea control into a Picture , using either TextArea.DrawInto or a StyledTextPrinter from the same TextArea. Then I can use g.DrawPicture inside CellTextPaint and get to see the styled text.

However, using an intermediate Picture for this is wasteful and also complicates things with HiDPI displays.

So I tried rendering the TextArea directly into the CellTextPaint’s Graphics object. But that consistently leads to a hard crash, usually with segmentation faults, and somewhere inside DrawInto, and with undecypherable stack traces like this:

Thread 0 Crashed:: Dispatch queue: 0 ??? 0xbfffc9a8 0 + 3221211560 1 ??? 0x43998000 0 + 1134133248

A sample project is easy to make:

Add a Listbox and a TextArea to a Window. In the Listbox’ CellTextPaint event put:

TextArea1.DrawInto g, 0, 0

That’s it. Run it, and you’ll get some crash or other weird behavior.

Is this a known issue?

Oh, and there’s one quite “severe” problem with this that I can’t solve at all so far:

I want to keep the drawn background of the cell (e.g. for when it’s selected and has been filled with the highlight color). If I could draw directly from the TextArea into the graphics port, this would be working. But since I have to use a Picture, and that picture does not maintain a proper mask or alpha, drawing that picture into the Cell’s graphic will replace the the non-white background with the picture’s white background.

To see this, change the CellTextPaint code into:

dim p as Picture = self.BitmapForCaching (me.Width, me.Height) TextArea1.DrawInto p.Graphics, 0, 0 g.DrawPicture p, 10, 0

Run it, put something into the TextArea, then click into the Listbox to select it. You’ll see that the left 10 pixel are drawn with the selection background, the rest is white due to the g.DrawPicture call overpainting it entirely. How do I get the selection color across the entire cell?

All I can say is your experience matches mine, in that drawing other controls into a Listbox paint event causes a crash.

I can get this down to no code except one line in the cell text paint event and get a nice stack trace
Stack trace looks like

Thread 0 Crashed:: Dispatch queue:
0   XojoFramework                 	0x0000000106007986 0x105e5c000 + 1751430
1   XojoFramework                 	0x00000001060063b8 GraphicsClipSaver::~GraphicsClipSaver() + 36
2   XojoFramework                 	0x00000001060f509f SubPane::DrawIntoOffscreen(Graphics*, xojo::Value<xojo::Points>, xojo::Value<xojo::Points>) + 393
3   XojoFramework                 	0x0000000106041d42 RuntimeControlDrawInto + 143
4   My Application.debug          	0x0000000105d223a3 RectControl.DrawInto%%o<RectControl>o<Graphics>i8i8 + 67
5   My Application.debug          	0x0000000105da6c17 Window1.Window1.Listbox1_CellTextPaint%b%o<Window1.Window1>o<Listbox>o<Graphics>i8i8i8i8 + 503 (/Window1:34)
6   My Application.debug          	0x0000000105da9484 Delegate.IM_Invoke%b%o<Listbox>o<Graphics>i8i8i8i8 + 100
7   My Application.debug          	0x0000000105da954a AddHandler.Stub.22%b%o<Graphics>i8i8i8i8 + 170
8   XojoFramework                 	0x00000001060577f6 RuntimeListbox::DrawCellText(Graphics*, xojo::Rect<xojo::Points> const*, CellEntry*, int, int, bool, bool, int) + 554
9   XojoFramework                 	0x00000001060566c4 RuntimeListbox::DrawCell(Graphics*, xojo::Rect<xojo::Points> const*, RowEntry*, CellEntry*, int, int, unsigned char) + 1322
10  XojoFramework                 	0x0000000106055fb7 RuntimeListbox::HandleDrawRow(Graphics*, int, xojo::Rect<xojo::Points> const&, unsigned char, std::__1::vector<xojo::Rect<xojo::Points>, std::__1::allocator<xojo::Rect<xojo::Points> > > const&) + 547

so whatever the clip saver is doing in the destructor is causing the crash

submitted a really short sample + crash logs that should make this easy to reproduce

I’ve seen that kind of stack trace with GraphicsClipSaver as well a few times.

I suspect it’s not a bug there, but rather that the drawing code overwrites data on the stack, and that in turn leads to the crash later.