For some reason someone said I have to create a new feedback case Bbecause HiDPI is another issue.
Well, it is not. The original feedback happens for HiDPI disabled and enabled.
Anyhow, it seems Xojo Inc cannot fix this. I will search for another solution (read: another language).
Just because drawinto does not show selected buttons, you want to change language ? Good luck cow boy 
For that specific app I need to make, it probably is. 
@Christoph De Vocht
This may be of no use to you but I just used the BitBlt function and it captured the button states just fine. I’ve been working with these functions for days now so I thought I’d just throw it out there for you.
[code]
Function CaptureRect(HWND As Int32, X As Integer, Y As Integer, Width As Integer, Height As Integer) As Picture
#If TargetWin32 Then
Declare Function GetDesktopWindow Lib “User32” () As Integer
Declare Function GetDC Lib “User32” (HWND As Integer) As Integer
Declare Function BitBlt Lib “GDI32” (DCdest As Integer, xDest As Integer, yDest As Integer, Width As Integer, _
Height As Integer, DCsource As Integer, xSource As Integer, ySource As Integer, rasterOp As Integer) As Boolean
Declare Function ReleaseDC Lib “User32” (HWND As Integer, DC As Integer) As Integer
Const SRCCOPY = &h00CC0020
Const CAPTUREBLT = &h40000000
If Width = 0 Or Height = 0 Then Return Nil
Dim img As Picture = New Picture(Width, Height, 32)
Dim SourceDC As Integer = GetDC(HWND)
Dim DestDC As Integer = img.Graphics.Handle(img.Graphics.HandleTypeHDC)
Call BitBlt(DestDC, x, y, Width, Height, SourceDC, x, y, SRCCOPY Or CAPTUREBLT)
Call ReleaseDC(HWND, SourceDC)
Return img
End Function
#Endif[/code]
I put this in a button action event.
p = CaptureRect(me.Handle,0,0,me.Width,me.Height)Thanks for the code Geoff. We’re at that stage at the moment, but this routine unfortunately doesn’t work for HiDPI resolutions.
Ok, here we go:
HiDPI 100% (normal)
HiDPI 200% (click the link for the image, I did that to stop it getting resized in the forum and looking nasty)
https://www.dropbox.com/s/jjx4arpbkf9xg7a/2017-05-13_05-18-43.png?raw=1
This took me all day to read up on, research and understand what is being done and why. I’ll be using it in the future anyway so I really didn’t mind spending the time on it.
Let me know if you find any problems with it. I tested most things but it’s getting late and I’m tired so I’ll leave it there for now.
Enjoy
https://www.dropbox.com/s/im8d4ds68e74u61/DrawInto2.xojo_binary_project?dl=1
PS. Container Controls dont work at the moment, you can copy them by referencing the individual components though so its not the end of the world. Its the background colours not coming through correctly. If someone finds a solution before I wake up, please let me know
PPS. The eagle eyed among you might spot a Xojo bug with those screenshots, I’ll report it tomorrow if its not on the site already when I check. I keep the bugs I find in a notepad now to stop it interrupting me, I think I got to 5 there, it’s a new record for me in one sitting
PPPS. I now have an increased respect for the Xojo devs that work on HiDPI.
Thanks Julian … that works prefect. Highly appreciated.
Odd Xojo doesn’t do this by default.
@
Sadly your method does not work right for the following controls:
The Xojo method doesn’t draw the listbox correctly either.
TBH I’m getting a little despondent with the Xojo framework atm. I seem to be spending more time trying to patch issues than actually working on my projects. I have a buglist sitting in a notepad that I just can’t face documenting and submitting at the moment.
I have no idea about the problem, Xojo just seem to do some random stuff for different controls. Labels are just borked at the moment <https://xojo.com/issue/46975>, <https://xojo.com/issue/46398>. Sorry Neil, I won’t be looking into this any further, I’m just firefighting all the time against a slow burning fire.
Sigh…
On the upside your help has been very beneficial. At least I was able to resolve the majority of my issues.
The Windows .drawInto class desperately needs so love from the Xojo Inc guys. As said, it is about useless atm.
A dev (I think Norman) said they use DrawInto to put controls onto the IDE in windows. I’d love to know what they do to get radiobutton controls working, it might shed some light on what is wrong.
Nothing special really
Create one & set its properties draw it into a picture and draw that picture into the overall layout editor
And when properties change a new one may be created and the old one dropped, set the properties differently and draw that
But we manually double buffer the entire layout editor on Windows & Linux since their drawing engines dont double buffer like macOS does which is probably relevant
Heu … Norman … thats the problem. .drawinto does not work correct in Windows. That’s the whole point of this thread.
Controls are not draw as they should (even in default state).
Radio Buttons do draw properly in the IDE which is exactly what Julian JUST said[quote=332855:@] I’d love to know what they do to get radiobutton controls working, it might shed some light on what is wrong.[/quote]
DrawInto is one of those bits that makes doing the IDE in Xojo possible
Prior to 2005 it was all written in C/C++
BUT we do double buffer things manually
Is there a blog post or something on the details of this? It might be something that’s of use to us developers.
We draw the control into a picture and that picture is double buffered
No magic
Unless you misunderstood and think we double buffer the CONTROL ? (which is NOT what I meant)
Could we see drawInto ‘fixed’ (read: working as it should) in the near future? Or is this a As-Is feature?
In my (limited) experience with DrawInto, drawing the window and slicing out the portion that represents the control works a whole lot better than DrawInto at the control level. @Norman Palardy, do you use DrawInto at the control level, or the window level?
Control
Means we can limit how much gets redrawn, memory requirements etc
