B4J Question [Solved] Scaling problems when moving the application to the secondary screen

[BlueVision]

Hello friends. I have been struggling for some time with a problem that I have not yet been able to solve satisfactorily. Perhaps my approach is not quite correct in this case. My B4J application is running very well. Some time ago, I decided to hide the classic window around the application using the command

MainForm.SetFormStyle("TRANSPARENT")

in the AppStart sub in the main.
The reason for this was simply to make it a little clearer to the user that this is not a Windows programme in the classic sense, but a JAVA application. It also looks nicer, of course. As usual, the programme is scaled according to the screen values themselves, the application starts in the centre of the screen and scales itself automatically. This works perfectly on different displays. If you now change the style to a transparent background using the above function, you no longer have the option of moving the view of the application using the normal window control functions. For this reason, I have added a small timer routine that enables the view to be moved. This also works very well and I actually thought that this would solve all the problems...

There is now a problem when a second screen is connected to enlarge the Windows desktop. Some colleagues in the helpdesk use this function and can now move the application to the secondary screen using the move function. As a rule, however, a secondary screen has completely different DPI values, a different ratio and a different number of pixels than the primary screen.
The problem is that the application is now cut off, zoomed or incompletely displayed on the secondary screen. As far as I can tell, I can only use the scaling function (i.e. setting Mainform.WindowWidth and Mainform.WindowHeight) when the application is started. The values determined then always refer to the primary screen and are then also applied to the secondary screen when the application is moved. This would explain the problem.
Perhaps one of you has an idea how I can solve this problem. The application has a configuration file in which you could specify whether you want to work in classic Windows mode or display the main form in transparent mode. In the case of classic Windows mode, Windows functions take over the scaling of the window, at least you can adjust the window size and the application also scales correctly on the secondary screen. This option is not available in transparent mode.
I have not yet succeeded in programming the application to be ‘switchable’, because the main form is already created before the configuration file is read in. This can apparently only be ‘hard-wired’ in the programme. The value in the configuration file would then also be meaningless.

Programme code does not really make sense at this point, I think I have described the problem quite well. Not all of you will have a second screen on your computer.
But maybe someone has a solution that will help me. Otherwise, the only thing that will help is to revert the application to a classic window style.

Thanks for reading this!

Yours, BV

 

[Erel]

The first thing to try is to update to JDK 19 and see whether the behavior is better. You can find it here: https://www.b4x.com/android/forum/threads/jgooglemaps-library.56744/#content

 

[BlueVision]

Thanks for the answer Erel. I had a slightly different approach in mind at the moment. But it probably wouldn't work until the Main.Form is loaded and initialised. The solution would be to query the mouse or keyboard when the programme starts and react to an event, depending on which the Main.Form is to be configured.
I have noticed that the mouse query only works after the Main.Form has been loaded and initialised, i.e. is visible. Actually logical.
What about the keyboard? Would that make sense? Assuming that the space bar is pressed while the programme starts, it might be possible to switch between starting in classic window mode or panel mode depending on the status of the key. But I would have to build a routine for this first. Hence the question of whether the work in this direction would be worthwhile at all. In theory, the keyboard should work independently of a loaded form on the screen and be queryable...

 

[BlueVision]

Update:
As expected, the variant with the keyboard query works just as poorly as the variant with the mouse. The routines work, but only after the Main.Form has been loaded, too late...
As suggested by Erel, I have now changed the Java version and compiled the application with it. Some small warning messages popped up, like this:

Only Java 11, 14 and 16 are supported (Tools - Configure Paths).

I think you we can ignore them. The application is now being tested by the colleagues concerned. Wait and see...

 

[BlueVision]

The scaling problems are gone following Erel's advice by using Java version 19. Thank you for your support Erel. Problem solved.