Progress data in background window truncated/overlap

[white]

I fixed my previous post: I wrote download button instead of background button. I also added total size in k.

[white]

12.05.23 Fixed: Copy in background (F5 - Enter - Background): Use all available space for number of files and size copied (32/64)

It appears that the issue causing the size numbers to not be visible due to weird overlapping has been resolved. However, there seems to be some variation in alignment now. The alignment can either be halfway between the progress bar and the Start button, or it can be aligned with the right side of the progress bar. And wouldn't using all available space be like the mockup in this screenshot? In the mockup, I made the progress percentage right-aligned, consistent with foreground copying.

[ghisler(Author)]

However, there seems to be some variation in alignment now.

Yes, TC will align the size field to the right of the progress bar if there is enough space. Otherwise it will align it to the right of the number of files field and use all the available space up to the buttons. This is intentional because this way it makes the least jumps.

[white]

Yes, TC will align the size field to the right of the progress bar if there is enough space.

If you look at my screenshot where the progress is at 8%, you see that there isn't enough space. The minus sign doesn't fit in there and it looks quite unreadable.

Otherwise it will align it to the right of the number of files field and use all the available space up to the buttons. This is intentional because this way it makes the least jumps.

What about using the design you see in my mockup? Wouldn't that be simpler and more in line with the design of foreground copying? Or is this design not possible or not to your liking?

[ghisler(Author)]

If you look at my screenshot where the progress is at 8%, you see that there isn't enough space. The minus sign doesn't fit in there and it looks quite unreadable.

Sorry, I cannot reproduce that.

[white]

Sorry, I cannot reproduce that.

Here is an animated gif showing it.

[ghisler(Author)]

There was no overlap, but the gap was a bit small (?).

[white]

There was no overlap, but the gap was a bit small (?).

So you are seeing the minus sign that I don't see?

[AntonyD]

2ghisler(Author)
How many more reports of problems with this window does it take to finally be rewritten?
Its size is disastrously small! We could forget about it - if we ALL dialogs / windows of Total supported free resizing, as is possible in applications written in Qt, for example. But you have chosen the difficult path. Use only what was created... what year was the compiler you use released?
Most of these obsolete components are not suitable for modern operating systems. Either there is no support for resizing, or they don’t support multithreading, or they don’t support themes, or ... a bunch or ...
Maybe it's time to start changing the fundamentals?

[Hacker]

AntonyD,

what year was the compiler you use released?

The year when the compilers producing the fastest code were released.

Roman

[AntonyD]

On modern computers, the main thing is not just speed - but functionality and extensibility.
If we stick to the fact that Total can still be launched on windows 3.11, the development of the product will definitely freeze, IMHO.

[Dalai]

2AntonyD
It's not the compiler that has any influence on resizable windows or multi-threading or anything else you mentioned. Anything compiled for Windows can use these features. It's just a matter of the actual implementation.

I agree that it's high time to increase the window size of the background transfer window (and also other windows) and/or make it resizable. Other issues will probably creep up when doing so because all GUI elements must get proper anchors and so on.

Still, please keep in mind that TC might be used on low resolutions of like 800x600 (Windows PE!) so it MUST work properly in such environments, too. It's annoying when GUI elements are too tight together but it's even more annoying when certain window elements can't be reached just because a window is too large for the current resolution because then it becomes unusable!

Regards
Dalai

[ghisler(Author)]

2white
Sorry, I found the problem now by explicitly setting the strings to what you had: There was a calculation error in my code where I added 4 to the available space instead of subtracting it, so in some cases the available space was seen as sufficient, while it wasn't.

[white]

Tested OK using TC 11.00b4 32-bit and 64-bit.

Moderator message from: white » 2023-05-24, 23:14 UTC

Moved to Fixed bugs.