Xojo 2018R3 vs Killer Toolbar - no 'Graphics' property

Title says it all… I just downloaded 2018R3 and tried a quick OSX compile.
KillerToolbar (at leat the version I have) generates several errors about me.graphics does not exist.
I’ll be looking into it later today.

Make a picture, draw into the picture instead.
Call Invalidate method on the control.
Than draw picture in paint event.

Still using the old ‘draw into graphics outside the paint event’ method, by the looks of things?
Hmmm.
Thats likely it.
Right: Sleeves up…

Nope.
Most of the calls are to do with getting a height or width of text.
So it starts with me.graphics and asks for textwidth

I cant see why that would have been removed.
I can replace such calls with a local graphics object (assuming I get the same scalefactor etc.)
Theres maybe one or two calls to drawpicture, and thats easily swapped out.

Yes, same problem here. I don’t paint anywhere other than the paint event, but using the text width/height calculator is a must when calculating dynamically spaced custom controls according to received caption widths. Working on same problem myself now - had not expected to be re-working old ground this morning rather than cutting new code, but hey-ho!

My current quick-and-dirty solution is

Add a private picture property - mPicture
Add a public graphics property - meGraphics

in Open() event, initialise

mPicture = new picture(20,20) meGraphics = mPicture.graphics

(check for nil before use…)

then all me.graphics errors can be replaced by meGraphics
Its ‘a’ graphics property not ‘me’ graphics property,but it should work the same for this.
Still working on it

Yeah, pretty much what I have. Just watch the Picture width, as it [should] impact the StringWidth calculation if wrapping is turned on - luckily, I have a ‘maxwidth’ property for these custom controls that I can use to create the width of the picture, which will give me a true 1:1 representation of the original drawing surface.

Then I removed me.graphics.drawpicture and replaced it with me.invalidate
That got it all running again.

Although it’s now smudgy and unsharp. :frowning:

Antialias = false in the drawbutton code sharpens up the icons, but makes the text awful.
Antialiasmode = Highestquality instead gets me passable text but smudgy icons.
The whole control needs refactoring to draw the captions in the paint event, rather than to a same-size bitmap offscreen (which it is doing now but not in a Hi-DPI way)

Since the Mojave Dark Mode testing has shown up loads of controls which don’t work out of the box for me just yet, I may have to put off 2018R3 until I decide how to replace KTB and fix all the dark mode issues.
Until then I wont support dark mode and keep my canvas.graphics property, thank you.

Huh? I am using Killer Toolbar and have had absolutely no issues, not sure what is different.

Thats good to hear,and possibly answers some of my nagging doubts about whether it may be time to consider buying it again (since there seems to be no upgrade path)

My KillerToolbar predates the GraffitiSuite version, and I bought the source code - which I had to modify over the years (for example, at one time it wouldn’t handle two such bars on one page … I see they have sorted that out now)
The Graffitisuite demo is a compiled app which doesn’t really tell me if their build will work with my ‘other’ code.
What version are you running?