listbox graphics object in events

is this EVER on any platform the same one from one event to another ?
ie/ if cellbackgroundpaint is called with a graphics is that same graphics EVER passed to celltextpaint or any other listbox event that is passed graphics ?
or does the framework create a new one for EVERY call to these events ?

@William Yu ?

[quote=443000:@Norman Palardy]is this EVER on any platform the same one from one event to another ?
ie/ if cellbackgroundpaint is called with a graphics is that same graphics EVER passed to celltextpaint or any other listbox event that is passed graphics ?
or does the framework create a new one for EVERY call to these events ?

@William Yu ?[/quote]

From what I’ve seen my guess is it is a graphics object that is like one created from Graphics.clip so anything you set in it is lost.

-karen

I really need to know for sure on macOS , Windows & Linux if it is indeed a new instance for each paint event
I’m hoping it is but the only folks who can definitively answer that seem to just ignore my posts lately
I’d point a debugger at the runtime but …

@William Yu ? @Greg O’Lone ? @Travis Hill ?
would be nice if one of them would reply

[quote=443008:@Norman Palardy]I really need to know for sure on macOS , Windows & Linux if it is indeed a new instance for each paint event
I’m hoping it is but the only folks who can definitively answer that seem to just ignore my posts lately
I’d point a debugger at the runtime but …

@William Yu ? @Greg O’Lone ? @Travis Hill ?
would be nice if one of them would reply[/quote]
Hey dude, I’m not ignoring you. You posted this question after I’d signed off for the day. Lemme do some digging.

Functionally Effectively they’re all the equivalent of Graphics.Clip with the properties (listed below) that you change transmitted back to the main graphics object.

Font, Size, Units, Style (bold, italic, underline), ForeColor, Pen Width & Height.

Good to know that it doesn’t persist onto other cells or events, thanks!

That’s not entirely accurate. Now that I’ve gotten some sleep, I realize that I should have said “effectively” instead of “functionally”.

I do have a question for @Norman Palardy though… what’s the underlying question here? Is something not behaving the way you think it should?

and this holds true an all targets ?
that a clipped graphics has its own instances for pen, forecolor, etc, etc and not just references to the underlying items.
effectively so that any changes to the clipped item should not be mirrored in the underlying item ?

basically trying to ve certain that ANY chnage to a graphics passed into CellBackGroundPaint will not be then subsequently passed along to CellTextPaint on macOS, Windows & Linux

[quote=443154:@Norman Palardy]and this holds true an all targets ?
that a clipped graphics has its own instances for pen, forecolor, etc, etc and not just references to the underlying items.
effectively so that any changes to the clipped item should not be mirrored in the underlying item ?

basically trying to ve certain that ANY chnage to a graphics passed into CellBackGroundPaint will not be then subsequently passed along to CellTextPaint on macOS, Windows & Linux[/quote]

I use those very EXTENSIVELY in my mergeableCell listbox and that is certainly the case as it depends on it.

  • Karen

[quote=443154:@Norman Palardy]and this holds true an all targets ?
that a clipped graphics has its own instances for pen, forecolor, etc, etc and not just references to the underlying items.
effectively so that any changes to the clipped item should not be mirrored in the underlying item ?

basically trying to ve certain that ANY chnage to a graphics passed into CellBackGroundPaint will not be then subsequently passed along to CellTextPaint on macOS, Windows & Linux[/quote]
I’m pretty sure that they are though. Just go to CellTextPaint and set g.Forecolor = &cff0000. I think you’ll find that the listbox renders the text in red.

But only for that Cell so it is not carried over to the backing (unclipped) graphics object after the painting for that cell is done. (which I assume is done by the framework in the clipped graphics object after the events returns)

  • karen

found the leaky change I was thinking of !
<https://xojo.com/issue/56409>
changing the g.forecolor in the celltextpaint event and returnring false results in the list drawing in whatever color you changed to on Windows
and return false

that change to the text color shouldn’t turn everything red since we arent doing the drawing
it should draw in whatever color would be normal IF the passed in graphics is its own instance with its own colors etc

however I bet a lot of people rely on this behaviour

[quote=445807:@Norman Palardy]found the leaky change I was thinking of !
<https://xojo.com/issue/56409>
changing the g.forecolor in the celltextpaint event and returnring false results in the list drawing in whatever color you changed to on Windows
and return false

that change to the text color shouldn’t turn everything red since we arent doing the drawing
it should draw in whatever color would be normal IF the passed in graphics is its own instance with its own colors etc

however I bet a lot of people rely on this behaviour[/quote]
As it only does it for THAT cell I always saw that behavior as an intended feature.

All the drawing for that cell being done to that clipped graphics context

just inconsistent
setting g.forecolor & returning false in cellbackgroundpaint has no effect in the background drawn
setting g.forecolor & returning false in celltextpaint changes the color of the text drawn

a consistent api for these things on listbox would be nice but I doubt anyone wants to touch listbox to make any such changes

[quote=445836:@Norman Palardy]just inconsistent
setting g.forecolor & returning false in cellbackgroundpaint has no effect in the background drawn
[/quote]

I always attributed that to the background color being painted BEFORE the event is called so any drawing in the event is done on the “correct background color”… and that is likely what most common need… and without declares we don’t know what the background color should be to be. BTW IIRC that as platform specific at least at some time with it being profiled on a Mac but not a PC…

The painting of the BKG before the event means that returning true has no effect if you have no other code in the event… Again because the cell was filled with the background color BEFORE the event was called,

But one size does not fit all and it did not fit my Listbox subclass,

I think many years ago I (Maybe have been back in REALBugs days) I put in a feature request to have g.forecolor be set the background color for the cell BEFORE the event.

That way we could do things that depended on knowing that color in the event (which I needed).If that as done it would not matter if the background is painted before the event or after when we return true as we could easily paint the correct background color ourselves

But I agree that it would make more sense to do it after (As long as g.forecolor was set correctly before) and only if we return false… But that means we need to know what the background color should be…

Deferring the background drawing until after he event would mean it not need to be drawn twice when we only want to change background color ourselves (which is the most common usage)… It would likely help speed a TINY bit… and the could work like CellTextPaint… but it would definitely break some code…

But setting g.Forecolor to the Background color before the vents is a lot less likely to do so… AND serve a useful purpose!

  • Karen