[TC10.70b7] visual bugs dark mode, no scroll bar

[white]

In my own tests, the closest I can get is by using 1/4 of the average character width..

What does font width have to do with it? I don't think it should be related to font width and I think it isn't in normal mode.

[AntonyD]

It's more like a hint of what the custom column configuration contains.

OK, if so - pls add a corresponding tooltip for LOOOOOOONG lines which I can't read just by looking at this tab - or rather this table,
where there are clearly columns, but it turns out they are not columns, but fiction, as I understood you. But it gets even weirder.

[AntonyD]

In my own tests, the closest I can get is by using 1/4 of the average character width of the characters A-Za-z. This leads to good values for fonts up to about 20

And this is already a very good result. Since obviously users will not use sizes larger than 20 in 95/97% of cases. After all, these values are already too large to carry the assimilated information. Much more often, users will change the DPI to the FULL screen, rather than enlarging the font in a single application.
So your solution, if it works fine on font sizes UP to 20 at least - should be tested in the next beta.

[AntonyD]

Something in the dead of the evening seemed to hit me...
And where does the need to count anything come from?
After all, the object itself seems to be created by a direct call to the win32api function:

hWnd = CreateWindowEx(NULL,BUTTON,"Checkbox",BS_CHECKBOX,xPos,yPos,width,height,parent,NULL,NULL,NULL);
CheckDlgButton(hwnd, 1, BST_CHECKED);

When you create a dark theme, these calls no longer work? Well, really - very interesting. No offense!

[AntonyD]

In general, there was information that our programmers on the old forum already in 2009 tried to solve this problem. And it seems that the basis is taken from the size of the icon (its width) from the design theme, which is actually a drawn square for placing a tick of the mark there. Plus half the width of the symbol "0" rendered by the selected font. The sum of these values gives the starting position on the x-axis for the output of the text.
And yes, not all rendered test examples used this value were exactly the same in the end, if they compare their rendering with the default rendering with the built-in windows API. There were inconsistencies. But overall, it gave the best approximation.

[ghisler(Author)]

2AntonDudarenko
Thanks for the hint! Half of the number zero (plus SM_CXMENUCHECK plus 1 pixel) seems even closer to what Windows does than 1/4 of the average character width, but starts to diverge too for fonts >20 (although not as much).

[AntonyD]

Half of the number zero (plus SM_CXMENUCHECK plus 1 pixel)

From which origin do you calculate the distance? Maybe some pseudo graphic explanation you can provide?
With real numbers of used variables (like SM_CXMENUCHECK= ...px, Half-of-0= ...px, etc...)
In beta 8 I see only 1 px diff in comparison with beta7 ! Which means that the problem of the big "void" is still here(((

[AntonyD]

[img]https://i.ibb.co/9yDBmkn/32.png[/img]
[img]https://i.ibb.co/9hmfLbh/64.png[/img]
Again - suggestion is the same - download pics and open in some viewer
and quickly switch back and forth viewing these two pictures.
You'll see it out - finding a few very visible differences.
And the main thing about them is the different size of the whole dialogue!
in 64 bit application the dialogue is larger!

[white]

[img]https://i.ibb.co/vdgH5vg/2.png[/img]

What about the combobox sticking out of the groupbox?

I fixed that by making all the groupboxes a tiny bit wider.

You forgot the groupbox Save on exit.

[AntonyD]

2white

You forgot the groupbox Save on exit.

Thanks for clarifying - I just left this point for homework - to find a few differences in the pictures

[ghisler(Author)]

Again - suggestion is the same - download pics and open in some viewer

Unfortunately I can't make it any better, sorry. Russian strings are generally very long, so they may not fit with all fonts. There is no documentation for the space between the checkbox and the text, so all I can do is guess (or let others guess).

You forgot the groupbox Save on exit.

Ah, you are right - I only searched by width. The same is true for the new separators box on the page "Tabstops/Data formats".

[AntonyD]

2ghisler(Author)

Unfortunately I can't make it any better, sorry. Russian strings are generally very long, so they may not fit with all fonts. There is no documentation for the space between the checkbox and the text, so all I can do is guess (or let others guess).

That's right - we are in a situation where we have to guess, this is normal. And it is precisely in order to guess as accurately as possible that I am trying to help. After all, there may be a situation when you got some values on your computer - and they seem to be good - but on mine there will be others - and the result will be worse. And it is worth trying to understand the reason for this difference.
Note - I have never written that it is necessary to give more space for Russian lines - yes, they are longer on average than their English equivalent, but in this case their length does not affect the essence of the problem in any way - when switching to dark mode, the overall dimensions of the dialog change too strangely depending on the programs bitness (I showed pictures about it) and the moment looks very strange that taking the width of the symbol '0' as a void's width, we did not get even close to the picture that is drawn in a normal mode. That's why I asked for clarification about the initial coordinates, the values of some constants, spec.values, etc... obtained, on the basis of which the starting coordinate of the text input location is obtained - I want to compare them with my picture. In dark and normal modes. Pixel by pixel. It is likely that this way we will be able to find the point of difference and make a BETTER guess about how to conduct calculations. And that's all.

[ghisler(Author)]

With the fonts I tried the estimate with the symbol '0' worked well, even with fixed pitch fonts like Courier New. If you have a better guess, then let me know.

[AntonyD]

With the fonts I tried the estimate with the symbol '0' worked well, even with fixed pitch fonts like Courier New. If you have a better guess, then let me know.

With great pleasure. Just for starters, can you provide me with current data on this task? What did I describe and ask above? From which coordinate and for which objects you start counting. What values ​​and what variables do you currently have for these objects. At least for the default M.SansSerif,8 font.
So that I can compare these values ​​​​with my own and draw any conclusions. In the meantime, according to what I see in 8 beta, there are actually no changes. For example, now the entire character 0 is placed in the void between the checkbox and the text!

Of course, there is no need to describe each checkbox on this tab - just select two that go horizontally.
And for them to paint / draw the concepts used and their meanings.
[img]https://i.ibb.co/xMcqTT7/1.png[/img]
as example.
Why is it important for two horizontally placed objects to know the values? Because I noticed that even the value of the inter-object distance does not match. In one case it is about 223 pixels, in the other it is closer to 215!

[ghisler(Author)]

Here is what i currently use. I'm actually using 1/4 of the width of the 0 character:

Code: Select all

      GetTextExtentPoint32(hdc, '0', 1, size);
      checkboxSpacing=size.cx/4;
      delta=max(2,checkboxSpacing)+GetSystemMetricsForDpi(SM_CXMENUCHECK,CurrentDialogDpiPerScreenScaled);

GetSystemMetricsForDpi calls GetSystemMetricsForDpi on Windows 10 creators version or newer, GetSystemMetrics on older systems. Calling it with parameter SM_CXMENUCHECK gives the width of the checkbox.