Transfer Bar Disappeared while repositioning and Now Won't Show at all

[dbareis]

"View, Transfers Bar" is ticked, started dragging the bar to the correct position, and it disappeared.

Toggling "Transfers Bar" or restarting BiglytBT won't restore the bar. I suspect it might be off-screen.

Java 1.8.0_341 (64 bit) Oracle Corporation c:\program files\java\jre1.8.0_341

SWT v4942r22, win32, zoom=100, dpi=96 Windows 10 v10.0, amd64 (64 bit) B3.2.0.1_B04/4 az2

[parg]

Go to

Options->Logging: Advanced Settings

Enter transferbar.x as the name and 0 as the value and hit the Set button

Do the same for transferbar.y

restart BiglyBT and hope!

[dbareis]

@parg That didn't work until I noticed I'd accidentally copied the name with a leading space (should probably trim the value of leading trailing spaces).

I just picked up a new beta version and while the values worked (although wasn't at 0,0), as soon as I tried to move it it disappeared again (see attached video). Does it have issues with monitor scaling?

https://user-images.githubusercontent.com/295230/197653668-ad97b05c-836b-40cb-b864-05e29082d295.mp4

Java 1.8.0_341 (64 bit) Oracle Corporation c:\program files\java\jre1.8.0_341

SWT v4942r22, win32, zoom=100, dpi=96 Windows 10 v10.0, amd64 (64 bit) B3.2.0.1_B04/4 az2

[parg]

You hit the nail on the head. Unfortunately the style of window BiglyBT uses for the "transfers bar" has no "dialog trim" - that is, it is lacking the usual Windows stuff at the top like the minimise, maximise and close icons. When this is the case for some reason the window isn't rescaled properly and leads to the issues you are seeing. I've spent some time seeing if I can work around this but can't see a way. If I could detect the issue then I suppose I could add the dialog trim (which makes the bar as ugly as hell) but I can't even detect it :( The real solution is for the SWT UI library we use to fix the problem, but they aren't very responsive and we have other issues there as the latest builds of the library are Java 11+ and we are currently Java 8+

[parg]

I just tried the latest SWT on Java 11 and the problem has been fixed. If you want to try running with Java 11 and the updated SWT then let me know!

[parg]

To try the fix please join the Beta Program (see the Help menu for an option to do this). Then read the section about "Switching Versions" in

https://github.com/BiglySoftware/BiglyBT/wiki/Java-Versions

Once you have BiglyBT running on a Java 11 or higher and you are in the Beta program the SWT library will automatically update to one containing the fix.

[dbareis]

I installed the latest Java (Java 19.0.1 (64 bit)) and saw SWT update (SWT v4956r12, win32, zoom=100, dpi=96).

It worked the first time and then I tried it 2 more times and both failed :-(

Also on top of your previous instructions to reset the x/y coords I think I need to also:

1. Have turned the transfers bar option off
2. Press the SAVE button.

Another weird bug/feature is that if I turn OFF the transfers bar, then restart bigly (from menu), then it is TURNED ON on restart.

Java 19.0.1 (64 bit)
  Oracle Corporation
c:\program files\java\jdk-19

SWT v4956r12, win32, zoom=100, dpi=96
Windows 10 v10.0, amd64 (64 bit)
B3.2.0.1_B05/4 az2

[parg]

Darn it, for me updating SWT seemed to fix the transfer bar issue permanently :( Does it do the same thing as before when it breaks - just vanish?

[dbareis]

@parg Yep, same as before, it just disappears

You showed me how to set variables, is there a similar way to query them (file maybe)?

I thought that if I move the mouse very slowly while moving the bar it might work but if faster it disappears. Then again it doesn't appear consistent. To speed tests up, I found I don't have to restart biglyBT, just turn off the transfers bar before and back on after setting variables.

[parg]

The variables are saved to biglybt.config %APPDATA%\BiglyBT

That file contains non-printables and is in "bencoder" format so don't try and edit it

[dbareis]

@parg I found a Bencode converter:

AFTER SET
~~~~~~~~~~~~~~~~~~~~
    "transferbar.x": 0,
    "transferbar.y": 0,

AFTER DISAPPEARANCE
~~~~~~~~~~~~~~~~~~~~~~~~
    "transferbar.x": 1120,
    "transferbar.y": 317,

As mentioned previously 0.0 is not actually displaying at 0.0 (y coordinate seems OK)

I have 2 monitors (desktop extended) both with different scaling, a small laptop screen and a large monitor on the right (the primary, where 0,0 is top left).

1. L: 1920 x 1080 (150%, 125% recommended)
2. R: 1920 x 1080 (100%, 150% recommended)

UPDATE: After restarting BiglyBt the disappeared transfers bar now displaying approx where I'd expect it to be, I can no longer make it disappear and have moved it where I want it....

biglybt.zip

[parg]

The bug, from my investigation, is that something's wrong with the rescaling for windows that don't have "dialog trim" - they end up on a monitor with scaling applied when it shouldn't be and this borks up the computed location to somewhere off screen. I can see it when I test with my setup - two monitors, one scaled, one not.

When the dialog-trim is missing BiglyBT has to implement the drag feature - it received mouse events during the drag and repositions the window based on the drag mouse location. The bug causes this to give a correct mouse location but when this is applied to the dialog it is incorrectly scaled to somewhere off screen. BiglyBT can't detect this is happening, everything seems fine, as the scaling is happening invisibly to BiglyBT. So we can't fix it.

The only work-around would be to have an option to show the dialog trim but this is as ugly as heck.

[dbareis]

@parg You are probably right about a lot of that but I still think that Bigly bugs have an impact. After restarting Bigly this morning the transfers bar was gone again. After toggling the setting it is back again where I expect it to be (where I moved it yesterday).

Also why does the transfers bar setting get turned ON on a bigbt restart? If I turn it off and then restart (in this case to install latest beta update), the setting gets turned back on and the bar is visible.

[parg]

I'll take a look!

[parg]

If you want it to open on start then you need to explicitly enable that behaviour via

Options->Interface->Start: Open Transfer Bar on startup

[dbareis]

If you want it to open on start then you need to explicitly enable that behaviour via Options->Interface->Start: Open Transfer Bar on startup

Thanks @parg , you are correct that is why it opens on startup, It is a bit confusing when I turn it off under "view" and if it is turned on in View wouldn't it automatically startup and show (I don't see the need for this option at all).

In any case as mentioned one means the bar works and the other means it doesn't so BIGLY behaviour effects the this buggy situation. It is not being moved so any mouse dragging bug won't effect this.

[parg]

If you say so but I have no way of fixing it and a shit load of other stuff to work on