[TC 11.00b2] Copy dialog losts info-strings From: and To:

[AntonyD]

for me 64/32 - does not matter.

[ghisler(Author)]

why in some special way prepared TC' build cannot be sent to me

Because I have no idea what could be wrong, so I don't know what such a special build should do.

[AntonyD]

so I don't know what such a special build should do.

Piecewise selectively display information about the state of variables/flags, coordinates of related GUI elements in the log, form a stack of calls to functions related to 1) forming of the affected strings, 2) passing them to the dialog, 3) the process of forming the dialog body is also possible if it dynamically receives data. 4) something else of your choice.

[ghisler(Author)]

I made a few more tests, this time with an 11 GB file, but wasn't able to reproduce it so far. But I have a few questions:
1. When bringing the background copy dialog to the foreground, I noticed that it will show a few things above the progress bar:
- the currently copied file name
- the string Copy:
- the string Copy: plus the current speed and remaining time
Does it make any difference which of these is shown to make the error appear? You can pause at any of them. Here it made no difference.
2. Do the names reappear once the percentage increases in the foreground?
3. Does the problem also happen with Total Commander 10.52 final?

[AntonyD]

1)
Let's just say - after the show:
- the string Copy: plus the current speed and remaining time
I'm much more likely to repeat this bug. But in principle, I saw the loss of text and for:
- the currently copied file name
Only for - the string Copy: = all was fine. But this is very easy to figure out - this line comes on and off too fast. I almost never see it.
And in this regard, I now have the following question - what is this line for? What functionality for ME - as an end user - does having this line provide? What is so special that I can do if I see this text? It seems to me that it is enough to loop only the two patterns described above. And that's it.
2)
No. + In my post above, I showed you in the picture ALL the tree of resources that existed on this form. And there in principle were no text components!!! Here it is again: https://ibb.co/4NBqBL5 + https://ibb.co/x5d3B3X
As you can see, these are only three buttons, one progress bar and some two simple/faceless 'Windows'.
By coordinates, these are invisible areas 1 and 2 under the visible rectangular objects, marked by me with these numbers on pic above.
Can you even confirm the presence of such hidden elements initially on this form?
And as you see - that there was not just a loss of text, but a complete displacement of objects in a form!
3)
No, I can't reproduce it with this version.

P.S. And please visit this topic: viewtopic.php?t=79241
And yes - Part of my problem was solved there. But the other part I don’t think is.
It’s about the lack of appropriate added help pages about a couple of dialogues.

[petermad]

I managed to reproduce it again. It took some tries, but here is how the dialog looks: https://tcmd.madsenworld.dk/blankcopyprogress.png

The dialog is still "alive" = all visible places are updated, except for "From:" can "To:"

It wasn't until I swithed to Danish that it happened, but I don't think I had done that the first time it occurred for me some weeks back, but maybe try it with a language file active.

Again copying an 11 GB file from a Network share connected via WiFi.

[ghisler(Author)]

It could be some kind of timing problem, e.g. the copy thread sends the new names before the dialog resets them.
I still can't reproduce it, but I will add some countermeasures against possible timing problems.

Since it doesn't happen in 10.52, could you please check whether it happens when you add the line
ShowProgressBarSpeed=0
to wincmd.ini section [Configuration], please?

[petermad]

2ghisler(Author)
I managed to reproduce the bug with ShowProgressBarSpeed=0

I can add, that once the bug has occurred, it stays that way (no From: / To: lines), if I continue sending the process to background and back to foreground

[AntonyD]

ShowProgressBarSpeed=0

It looks like this solved the problem. Now there are no line losses. I would even say - there is a feeling that these lines of text now literally jump out on the form by the first GUI elements when it is shown.
Also about the situation with the loss of lines - I can also add that after these objects are gone - then I can at least a dozen times transfer the form to the background and pull it back to the foreground - these lines never appear there. In connection with the fact that I showed you above - HOW the whole form looks in the worst manifestation of this error (have you carefully examined these screenshots?) - I had a suspicion that the Windows conditional type object like this one which marked #1 on my screenshot https://ibb.co/x5d3B3X - this is really some kind of blank that is present on this form, invisible under normal conditions, but in the event of some kind of error, received the coordinates by which its location OVERLIGHTS the place where the "lost" lines are displayed. Those not the lines themselves disappear from the form - but they are simply blocked by some kind of artifact on this form. Perhaps it was previously intended for some useful things, and now it plays the role of a simple gray rectangle. Maybe it's some kind of substrate for rendering something auxiliary? Or to support the dark theme - we know that you had to rewrite many things yourself in order to implement this support, otherwise the standard windows elements would not be drawn in the right colors.

P.S. And I've lost my memory. We discussed in some bug that in order to switch the dialog to the background, and then to the foreground, you need to remember and apply the state of the Pause button?
So, as it were, the computer's memory exists for this))) to remember. So please remember BEFORE transferring to the background and restore AFTER transferring to the foreground of this dialog, the Pause state.

[AntonyD]

2petermad
This is amazing - I typed my post and sent it after yours and only now read yours. And how amazing. The second part of your post is identical to mine - I was just clarifying the fact that the lost lines cannot be returned just like that.
But what is doubly surprising is that you did NOT get rid of the bug when using the specified variable. And this is very strange ... I'll try to double-check everything again.

[AntonyD]

2petermad
Simply amazing thrice!
I was actually able to reproduce this bug again with this variable!!!
And again - the main window of Total, opened to full screen, played a decisive role! Before that, for the convenience of quickly switching to the background copy dialog, I made the size of the main window smaller....

Still, this is most similar to the problem of overlapping on the form by some internal object of these lines, which under normal circumstances has different (smaller) sizes or is located at different coordinates (is the substrate of something another on form).

[AntonyD]

2ghisler(Author)
By the way, about a similar problem. You asked - what should be displayed in a detailed log?
Here is the answer - at least ALL objects that are on the form with their screen coordinates and all flags, including visibility.
Now we would just look at such a log, compare it with the log when the situation is not reproduced and find the culprit.
And only then we would think - how could it get such coordinates or the wrong visibility flag?

[ghisler(Author)]

I will do some limited logging in beta 6, maybe it will give us some clues.

[ghisler(Author)]

I still can't reproduce this bug, so I have added some logging to Configuration - Options - Log file. Please enable logging and make sure to also log successful operations.
Moving from foreground to background will be logged as:
FG->BG: From/to text or an error
Moving from background to will be logged as:
BG->FG: From/to text or an error

[petermad]

2ghisler(Author)

I only get FG->BG and BG->FG logging entries when using 32bit TC 11.00b6 - and currently I cannot reproduce the bug in 32bit TC 11.00b6.

On the other hand I can now reproduce the bug at the first try in 64bit TC 11.00b6 - every time - but unfortunately no FG->BG and BG->FG logging in 64bit TC.