Unexpected change of drive in inactive panel

[polle452]

TC8.51B3x32

Active Panel:
Multiple Tabs with a Tab for Drive D: (Disk Drive) selected.
Content of CD in drive is shown.

Inactive Panel:
Multiple Tabs with a Tab for Drive F: (Partition of 2nd Phys. Disk) selected.

Problem:
Open disk drive will force the current active Tab to change to the root of C: Drive - content shown.
No change in Inactive Panel.
Insert disk in D: Drive and select the Icon for D: before Drive is ready, will bring up a 'connect' message box. Just before this box is taken down (Drive Ready) the current Tab with F: in the Inactive Panel changes to C:. The Content in the Inactive Panel still shows the F: Drive content.
Any file copy/move from the D: will be performed to the Root of C: Drive.
This happens with any Drive/Folder set in the Inactive Panel.

Using Win7 Home Prem. x64. and problem exists in TC 8.51B3x32 and B4 x32.
The problem is NOT present in TC 8.51B3x64 nor in B4x64.
The problem is NOT present in TC 8.01x32.
The problem is NOT present if I wait until D: Drive is ready before selecting it - any of the above versions of TC.

[ghisler(Author)]

When TC gets focus, it tries to re-read both panels. If you make one side hang, TC will not read the other side and switch to default path to avoid further hangs. This is part of the many functions to prevent TC from hanging.

[polle452]

I can understand that updating the Active Panel is a good idea - here are my disconnects:

a) Why is there a consistent difference in behavior of x32 and x64 versions of TC with respect to updating (or not) the Inactive Panel?

b) Why is there a consistent difference in behavior of 8.51B3&B4x32 and 8.01x32 versions of TC with respect to updating the Inactive Panel?

c) The Tab in the Inactive Panel changes to C: - however the Panel content is never updated (still the F: content) which is rather annoying.

d) If I close the D: without a disk I'll end up with a 'Drive not ready' message box - the Inactive Panel is NOT being updated or changed.

e) If I close the D: by clicking the Icon, I get the 'connect' message box however NO change appears in the Inactive Panel - disk or no disk???

Looks like a change in timing/sequence could fix these inconsistencies.

[ghisler(Author)]

a) 32-bit and 64-bit use completely different compilers (Delphi and Lazarus), and the frameworks are different too. It's not possible to get 100% identical behaviour.

b) Because of the mentioned additions to prevent TC from hanging

c) TC tries to refresh the panel, but since the other side hangs, it aborts and goes to c:

d) The special actions you perform alone cause the possible deadlock/hang situation, which TC tries to avoid

e) This only causes the current panel to be read - the inactive one isn't refreshed because TC doesn't get te focus from another program.

[polle452]

a) Fair enough - I was just trying to point out the difference.

b) Since it all worked as expected in v. 8.01x32 and in v. 8.51x32 B4 this new issue appeared - again I was just trying to point out the difference. I can understand that this could a side effect of changes in the 'hanging' situation between the 2 versions both x32.

c) This is my real problem:

c) TC tries to refresh the panel, but since the other side hangs, it aborts and goes to c:

Yes, the Title Bar in the Inactive Panel changes to c:\*.*; BUT the Panel File and Folder content is NOT refreshed!!! - shows content of a completely different location. In other words changes to a different location (c: root) without updating the content shown (f:\Preferences\...\...\).

d+e) Both these situations were tested to see if TC behaves differently depending on the situation - indeed it does. An empty CD Drive will never end with the incorrect change of Inactive Panel. Depending on how I close the CD Drive tray with a disk inserted, I'll get the error if done manually on the Drive itself, whereas closing the tray by clicking the Disk Icon no error shows.

Christian, if this is how it is going to function, I suggest we stop beating this dead point any more.

[polle452]

Problem fixed in v. 8.51RC1 x32.

[ghisler(Author)]

I didn't change anything - I tried to reproduce the problem, but it didn't happen here. Maybe some kind of timing problem...