I threw some tpanels of various sizes over my application both on the desktop and nested to capture a screenshot of the problem. surprisingly they were OK (except that the top border is missing).

changing the color however moves the text and borders about 10 - 15 pixels upwards. changing color back to clBtnFace fixes it. nested tpanels of clBtnFace are affected if the parent is a different color. nested tpanels that inherit parent color are OK.

???

Terry

if anyone wants to help, here are 2 screenshots, the good, and the bad and the ugly. (took the arm one with my phone so its a bit crappy)

http://www.klc.net.nz/images/

TIA

Terry Kemp wrote

if anyone wants to help, here are 2 screenshots, the good, and the bad and the ugly. (took the arm one with my phone so its a bit crappy)

any updates ?

Well I have a deadline for implementing the Gumstix on a prototype so I have learned to live without tpanels and any tgraphiccontrol descended controls. Amazing what you can do with no panels, shapes speedbuttons etc. TG for tstatictext ;)

I got lazarus compiled with qt-core but when I went to run it (lazarus) it wanted a Qvfb which I couldn't get working on the x86_64 so I could prove that it was a qt-core issue.

i have stepped through the code in lazarus to look at potential sources of the problem with the graphiccontrol descendants in arm and I think it has something to do with DC origin on arm with no window manager that causes all these components to draw at (0, 0, x, x) i.e. top left. I haven't had time to workout gdb tracing on arm yet.

here is a 'video' of my close to finished controller... http://www.klc.net.nz/linux/?p=15

its a screen capture of firefox on workstation.

there is a couple more screenshots of the host development stage in

http://www.klc.net.nz/images

When I get setup to debug this properly I will let you know my findings

cheers

Terry