.DrawInto Windows oddness

I use a technique to draw controls into a Canvas or Listbox cells to fake using Native controls.
Although this technique works very good running macOS, it doesn’t when doing the same in Windows.
It seems the .DrawInto does not draw the actually state of controls in Windows.
See screenshot. Left is the drawn version, right the control.

The code I use in the canvas is:

dim controlPicture as picture controlPicture = window.BitmapForCaching(PushButton1.Width,PushButton1.Height) editPushButton.DrawInto(controlPicture .Graphics,0,0) g.DrawPicture startPic,0,0

Any thoughts why this works fine in macOS and not in Windows?

Have you tried your code in pre-D2D versions of Xojo? If it works there I’d report it as a bug, if it doesn’t I’d report it as a bug :slight_smile:

TLDR; report it as a bug :smiley:

PS. I just tested it in another language and it worked fine.

What do you mean with ‘other language’?

I only tried it with the latest Xojo version. Will try with older later.

I mean another programming language, i.e. not xojo (I cant say which one), so it looks like a problem with xojo. If you raise a ticket about it the nice folks at Xojo might be able to shed some light on the issue or even fix the problem if there’s one to fix :slight_smile:

In “that other tool” you’d have to draw the control into a HWND that is NOT the one it is currently in in order to emulate this

Drawing it into the same HWND is not the same

If the other language that cannot be named happened to use .Net, the controls would not be Win32 so comparison would not be valid.

Its not .Net, its a competitor so I don’t want to name it, it is a Win32 exe.

This is using SendMessage with WM_PRINT and a few other params.

With the same call I can copy it to the window if I want instead of the canvas, device context is irrelevant.

The same routine doesnt work on Xojo though, the state isnt copied.

I assume that Xojo uses the same method, which is why its not working with DrawInto or my method, why I dont know.

[quote=330322:@JulianS]Its not .Net, its a competitor so I don’t want to name it, it is a Win32 exe.
[/quote]
Dunno what they are doing
All I can say is what we do and after a chat I understand why this doesn’t do whats expected
I have no idea about “fixing” it

[quote=330322:@JulianS]

This is using SendMessage with WM_PRINT and a few other params.

With the same call I can copy it to the window if I want instead of the canvas, device context is irrelevant.

The same routine doesnt work on Xojo though, the state isnt copied.

I assume that Xojo uses the same method, which is why its not working with DrawInto or my method, why I dont know.[/quote]

No
That doesn’t work for certain use cases

All I did was look up how C# does it, here:

https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs,4441da5479e7a6f8

Then used similar calls.

I don’t know what use cases it wouldn’t work for if it’s fine for .Net. I can only assume it doesn’t work for uses cases that arise from the Xojo implementation of things. That’s a bummer :frowning:

So is this considered a bug?
If not, the .drawinto has no use for Windows.

Not necessarily. You simply have to color the button yourself. Not quite as easy, but it should not be out of your reach. The fact that Windows controls are all rectangular makes it really simple BTW, contrary to macOS.

[quote=330408:@Christoph De Vocht]So is this considered a bug?
If not, the .drawinto has no use for Windows.[/quote]

It is of use, just not for what you want to use it for, which isn’t much good in your situation :frowning:

Personally I’d put a bug report in on it, however there’s no guarantee that it will be looked at any time soon so I’d start looking into ways around it.

Maybe generate your own controls using declares for the controls that aren’t handled as expected with drawinto. Not ideal but you should be able to get by.

If I get time, I’ll take a further look, it would be nice if Norman could let us know why it doesn’t do what we expect so we can see if there’s a way around it.

It’s possible that this can work for buttons and it should be fixed. The problem is that PrintWindow/WM_PRINT/WM_PRINTCLIENT aren’t universally supported. There’s no universal way to redirect GDI drawing and it’s touched on a bit in Microsoft’s blog post on ‘Mitigating Airspace Issues In WPF Applications’.

Thanks for the info Joe, I’ll have a read.

Christoph, do you want to put the bug report in?

feedback://showreport?report_id=48015

Thanks for looking into this.

True, but in that case I could use image files instead. :slight_smile:
But the idea is to have a ‘native’ look for each Windows iterations. So a correct working .drawinto is very handy. :slight_smile:

[quote=330486:@Christoph De Vocht]True, but in that case I could use image files instead. :slight_smile:
But the idea is to have a ‘native’ look for each Windows iterations. So a correct working .drawinto is very handy. :)[/quote]

Never said in an ideal world a drawinto that would work identically to Mac would be a bad idea. It simply seems not to be here.

You can also “animate” your window the very same way you wanted to do it with declares. The point is you are not limited to the technique used on Mac.

Keep an open mind.

Nice find on the feedback Robin, thats the same code I linked above, I should have continued converting the code from c# instead of relying on drawinto for the last stage. It looks like that works perfectly in windows. I’ve submitted a bug with the reported size of the combobox which is causing their bottom pixels to be cut off, a little extra code to use +1 on the height will get around that. Hows that Christoph?

I only see the Controls being drawn in the column “workaround” if i set .SupportsHiDPI=false.
With .SupportsHiDPI=true I don’t see anything (well, the first Workaround-Canvas one has a bit of some “blurry thing” in it) on my Windows 10 machine (using a Monitor with ScaleFactor 2x, 200%)

Sadly, the workaround does not work with HiDPI enabled.