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

[AntonyD]

2ghisler(Author)
absolutely the same behavior like petermad has - now I have.

[ghisler(Author)]

When you turn off the logging in 32-bit, do you get the error back? It could have an influence on timing.

[petermad]

I still cannot reproduce it in 32bit TC with logging turned off.

[AntonyD]

I still cannot reproduce it in 32bit TC with logging turned off.

Confirm.
And with easily I can reproduce on 64 bit this bug.

2ghisler(Author)
And I probably have a stupid question - what is so useful in just ONE log entry?

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

- I consider only as the ONE entry in the log btw.
Wouldn’t it be logical to output ALL the actions involved in generating text and sending it to a form, and the coordinates of all the text-receiving objects on it, that you didn't do that? We could have said something by now whether this text is generated in principle and whether there are any objects on the form themselves in which this text could potentially be rendered. Now we just have the case that there is no fact of switching to the background and back? And that's it? waiting for the next build, but with two lines in the log?

[ghisler(Author)]

And with easily I can reproduce on 64 bit this bug.

I didn't port the possible fix to 64-bit yet.

And I probably have a stupid question - what is so useful in just ONE log entry?

There are more, just in case of some errors, but also only in 32-bit.

[petermad]

I didn't port the possible fix to 64-bit yet.

I just wanted to point out that it is much easier to reproduce the bug in TC 11.00b6 x64 than it was in TC 11.00b5 x64 - maybe that could give a clue to the solution.

[ghisler(Author)]

Unfortunately it still does not happen here.

[AntonyD]

Unfortunately it still does not happen here.

We discussed the similar "floating bug" right in the next topic - that it seems like you are loading an icon for a dialog with a completely simple and accurate code - and at the output we get a completely different result depending on the bitness of the application. There seems to be no hint that the problem could possibly be... But alas, it is. Yes, it makes it harder to write code with a fix, but that's life.
Let's just release a new version with a special enabled suuuuuper extended debug of all related processes around this dialog/command - and we will make useful logs for you.

[ghisler(Author)]

I will remove the logging from 32-bit in the next beta to check whether this has any effect on the fix. I will add the fix and logging to the 64-bit beta.

[AntonyD]

TC11b7
So....
logging lines have appear for 64bit TC. I Confirmed it. And very probably the fix did its trick finally.
I could not now reproduce the string lost bug neither on 32 nor on 64 TC...

Thus only one thing is still left:
looks like you missed in answers this FULL body description of some bad behavior:

P.S.
But this also is not the last strange thing which I've observed:
https://ibb.co/mBnzqHp
Here I tried to cancel the copy process and got this dialog. And got a few questions:
1) Why there are 2 areas with collapsed text, marked by ellipses inside the string and with red lines by me?
Yes, I understand that we must somehow to fit veeeeerrrry-loooong string into current size. BUT! For this it should be enough to cut only MIDDLE part of the whole string! Not somewhere in it beginning, not somewhere in the end. ONLY in the middle!
2) Why tooltip was places so dooooown below? And not near the mouse cursor?
3) And it seems that the procedure for calculating the length of the shortened text does not take into account the length of the entire form after putting the translation strings for the buttons. We see in the picture that there is still sooooo much space on the form where we could continue to display the file name, right? And in this form we even could use multiline-label on single-line as it is now! In this case (probably even in most cases) we would not even need hints and shortening of the text - we could see everything at once!

1 & 2 points - no answers.
As to concerning the 3rd point - you answered on its first part (which now is strikethrough) - but my suggestion from its 2nd part was not accepted at all?

[petermad]

I can no longer reproduce the bug in TC 11.00b7 x64

[ghisler(Author)]

Nice to hear that! I will keep this thread in the bug reports section for now, we will have to observe this a bit to check whether it's truly fixed. If the error should happen again, please post the relevant lines from the log.

2AntonyD
What does this have to do with this bug report? Please stop mixing unrelated bug reports, this makes it impossible for me to keep track of them!

[AntonyD]

2ghisler(Author)

I'm just waiting for an answer. The answer may be in the style of - "okay, I'll deal with it - just move these questions to a new topic - it will be easier for me, since I see these as unrelated to the main found problem". But there should be an answer in principle for ALL questions. Before that there was just silence for these 2 first points.
And yes - already moved these questions and suggestion to a new topic. We can continue there.

Regarding the loss of lines - so far, it's not repeating itself. It gives me hope - that everything is really fixed.
But what I noticed - now there is no flicker of text on the background dialog - I always and constantly see only the name of the copied file.
This is supposed to be normal and adequate. BUT! why is this name then not truncated by three dots at the end, but only truncated by the form itself?
It's not pretty! Sometimes it looks like this - which is more or less still readable to the eye
https://ibb.co/L5LkTdr
And sometimes at the end of the form "meet" Such monsters of dots and arrows
https://ibb.co/1mXffKX
Won't this be corrected?

[ghisler(Author)]

And yes - already moved these questions and suggestion to a new topic. We can continue there.

Thanks!

[AntonyD]

So far - still no problems with these lines in the dialog - so very probably bug is fixed, imho.

And as I see additional logging BG->FG/FG->BG: is still here - now we can remove it in further RC1