Sorry, this is almost OT, but I don't know where else to ask.

While checking an application, I found a strange problem: under Windows WS when TTrackbar Orientation is trVertical, it doesn't behave properly under Wine. The widget size is correct, but Tick Marks and bar movement behave following the Width value instead of the Height value. In a real Windows environment, it works properly as it works with other

Does anybody with experience in using Lazarus and Wine under Linux have an idea of why this happens and how to fix it?

My environment: Linux CentOs 6, Lazarus 1.8.0 FPC 3.0.4, wine 1.8.6

Giuliano

I can confirm behavior in Wine. When you change trVertical to trHorizotal - everything OK. But oppositely, trackbar calculates with new width and OLD height and ticks remain horizontal. When you resize it at least 1 pixel, everything is OK. But I'm not able to say if the issue is in Wine or in Lazarus.  
V.
 

What widgetset win32 or qt ?

zeljko

In my setup qt WS under wine works just fine. I’ve seen the problem only with win32.

Giuliano

Giuliano Colla wrote

> Il giorno 22 dic 2017, alle ore 14:02, zeljko via Lazarus ha scritto:> >> On 12/22/2017 01:26 PM, Vojtěch Čihák via Lazarus wrote:>> I can confirm behavior in Wine. When you change trVertical to trHorizotal - everything OK. But oppositely, trackbar calculates with new width and OLD height and ticks remain horizontal. When you resize it at least 1 pixel, everything is OK.>> But I'm not able to say if the issue is in Wine or in Lazarus.> > What widgetset win32 or qt ?> In my setup qt WS under wine works just fine. I’ve seen the problem only with win32.

As a non-expert I don't like raising my head above the parapet, and I very much don't want to appear to be criticising anybody's work.

Incompatibilities in Wine are not unknown. I know somebody who found that a specialist comms program we both used misbehaved under Wine, he localised and reported the bug to the Wine developers and it was fixed promptly. The twist in that particular case is that the program concerned was written by somebody who then moved to MS, and he might have done maintenance on it with "a more complete understanding of the API than is normally documented".