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?
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
[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
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
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
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’.
True, but in that case I could use image files instead.
But the idea is to have a ‘native’ look for each Windows iterations. So a correct working .drawinto is very handy.
[quote=330486:@Christoph De Vocht]True, but in that case I could use image files instead.
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.
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%)
