[TC 10.50b5] Options - Edit/View

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: white, Hacker, petermad, Stefan2

User avatar
AntonyD
Power Member
Power Member
Posts: 1231
Joined: 2006-11-04, 15:30 UTC
Location: Russian Federation

Re: [TC 10.50b5] Options - Edit/View

Post by *AntonyD »

These buttons also too close to the neighboring editboxes, imho.
But in terms of buttons coords I would say that editbox width should be reduced by 2-3 px.
And the buttons should remain in their current locations
#146217 personal license
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Re: [TC 10.50b5] Options - Edit/View

Post by *ghisler(Author) »

Then you change the font or scaling factor, and it will again be wrong. There is no solution, sorry.
Author of Total Commander
https://www.ghisler.com
User avatar
AntonyD
Power Member
Power Member
Posts: 1231
Joined: 2006-11-04, 15:30 UTC
Location: Russian Federation

Re: [TC 10.50b5] Options - Edit/View

Post by *AntonyD »

ghisler(Author) wrote: 2022-05-27, 06:46 UTC Then you change the font or scaling factor, and it will again be wrong. There is no solution, sorry.
I tried to test this behavior on other variants of fonts, DPI scaling factor - and nowhere else I could get the same incorrect closing point of two objects. EVERYWHERE in the entire dialog - where else there is a similar combination - editbox+button(>>) - the rendering was fine. And only on this tab in this place - more precisely in two places - there is this incorrect adjunction. Would you agree that if there are many places where it worked - and only one does not - then there is a problem only in this one place? Or am I wrong? Maybe, at least for tests, you will reduce the size of the editbox by a couple of pixels? For comparison, so to speak.

BUT the most interesting thing is - why can you even get an overlap of these two objects? You also showed your code for rendering media player controls in the Lister. And you can clearly see that the coordinates of the next object depend on the final coordinates of the previous object. And How is it possible in our current case that two objects "are attacking" each other? Are the coordinates of the button (>>) not counted AFTER receiving the final coordinates of the editbox? You just need to add the interval delta(obviously a fixed number) to the final coordinates of the editbox and voila!
And the problems of rounding can not work here. Because always a fixed number is added and even with the growth scaling factor - it only grows.

I will clarify separately - I do not consider the question of the discrepancy between the upper boundary of the two objects! Only a problem of overlap...
#146217 personal license
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Re: [TC 10.50b5] Options - Edit/View

Post by *ghisler(Author) »

This isn't leading anywhere, so I'm moving it to "Will not be changed".
Author of Total Commander
https://www.ghisler.com
User avatar
white
Power Member
Power Member
Posts: 4594
Joined: 2003-11-19, 08:16 UTC
Location: Netherlands

Re: [TC 10.50b5] Options - Edit/View

Post by *white »

I noticed the edit boxes are not perfectly aligned with the buttons.
In Normal mode the edit boxes are 1 pixel more to the left than the buttons.
In Dark mode the edit boxes are 1 pixel more to the right than the buttons.

No Windows scaling, clean ini, TC10.50rc1 32bit and 64bit.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Re: [TC 10.50b5] Options - Edit/View

Post by *ghisler(Author) »

They use the same coordinates in normal and dark mode, but Windows draws them slightly differently (on Windows 10 which supports dark mode controls directly).
Author of Total Commander
https://www.ghisler.com
Post Reply