Migration guide for code coming from ancient WindowBuilder Pro?

[Zastai]

We have an old customer coming back to us.

Almost 20 years ago, we delivered a project which included Swing screens using a set of custom components.
When used in their current environment (Windows Server 2003 x86, JDK 1.7.0_90, Eclipse 3.3.1.1 and WindowBuilder Pro 6.4.1 (2007/08/13)), these design just fine.
However, they are trying to update their environments and go over to 64-bit, which means they also have to upgrade to a current WindowBuilder. This is causing design time problems for large screens. If we "downgrade" the screens to use plain Swing controls, the problem goes away, so it is likely a compatibility issue situated in our own components.

Is there a migration guide that describes things that need to be done differently in order to work with WindowBuilder compared to the ancient Pro version?

Issue Description

In WindowBuilder Pro, they have

The screen is 90 lines high, so 1530 pixels (component/line height is fixed at 17 pixels).
The screen's vertical resolution is 1080 pixels.
All items are visible.

The same screen in the current environment (Windows Server 2019 x64, OpenJDK 17.0.6, Eclipse 2023-03 (4.27.0) and WindowBuilder 1.12.0) is not shown completely:

Same size and resolution.
The first partially visible item is at 1055 pixels.
Given that the component height is fixed at 17 pixels, its lower edge should be at 1072 pixels.

If they reduce the vertical resolution to 1024, then the visibility is commensurately reduced:

Note that they claim they already investigated the free WindowBuilder over a decade ago, and saw the same problem at that time, which is mainly why they did not switch. The x86->x64 push is now forcing their hand.

If there is no migration guide, and none of this rings a bell as a known issue, I can attach the source of the screen in question along with our component jar for further investigation.

[wimjongman]

Yes, please add all the stuff, as small as possible, that shows us the situation.

[ptziegler]

I agree, a small reproducer is greatly appreciated.

Maybe as a general question: Does the problem also show up in the preview or is it only the design page, where the screen is partially shown?

[Zastai]

Here is the panel from the screenshots, plus the jar with the components.
issue-501.zip

The preview doesn't seem to include a scrollbar so does not reach the affected area:

[Zastai]

@ptziegler @wimjongman Have either of you had any time to have a look at this?

[ptziegler]

My apologies, I completely missed your response with the example project. Having a closer look, this issue seems to be oddly similar to #384

I have the suspicion that this problem is a limitation on how we calculate the preview. To keep it simple, we first create an instance of the class and then we create a screenshot from the area, where the object is shown on the screen.
This approach breaks down the moment those composites exceed the display resolution. As a simple example, if you take a JFrame with size 4000x4000, a large part is off-screen and not rendered properly.

Looking at your screenshots, I think something similar happens here. The composite is only visible up until the "Propositions" area, which is roughly the area where those black bars appear in the design page. If this is indeed the problem, then I don't have an immediate solution on how to deal with this unmapped area... I sadly don't have such an old WindowBuilder version at hand, to see whether it's using a different mechanism than what we use today.

Out of curiosity, does the problem also show up on Windows Server 2019 + WindowBuilder 6.4.1? What happens when you use a higher screen resolution?

[Zastai]

I might be able to get the jars of the old windowbuilder from our customer, but given that I belueve it was license-locked to a mac address, I figure it is likely that those will be heavily obfuscated, which would make it hard to dig into its implementation.

Would it be possible to adjust the snapshotting behaviour to do the equivalent of setting up scrollbars and scrolling horizontally/vertically as needed, taking screenshots along the way and then stitching them together?

[Zastai]

As for the other OS and resolution, I'll see what I can do.

I do think the customer had already mentioned that the extent of the black areas depended on the machine's resolution.

[Zastai]

Info from the customer:

• yes, the greater the resolution, the more can be seen
  • however, even turning the monitor to portrait orientation does not help sufficiently, because some of the frames span 130 lines (of 17 pixels each)
• the installer they have for WindowBuilder Pro is x86 and fails to install on Server 2019
  • similarly, the Eclipse installation they have that contains WindowBuilder Pro, when transplanted to Server 2019, fails to start (not entirely surprisingly, given the Eclipse launcher in question dates back to 2007)

[Zastai]

The customer has made the installer and the zipped Eclipse installation available, however, so if it would help to get the WindowBuilder Pro jars, I can probably provide those.

[ptziegler]

Would it be possible to adjust the snapshotting behaviour to do the equivalent of setting up scrollbars and scrolling horizontally/vertically as needed, taking screenshots along the way and then stitching them together?

That should work, I suppose... You can get the screen resolution via Display.getBounds() and the composite size via Control.getBounds(). From this, you can split up the composite into segments and my moving it around, assure that each segment is inside the visible area, before taking the screenshot.

The tricky part is going to forward this information to the native method calls, which communicate directly with the Windows/GDK/Aqua... However, there are already quite a lot of tasks on my todo-list, so I'm afraid I won't be able to work on this anytime soon. ☹️

If you're willing to give it a shot, the OSSupport class would be a good starting point. And if there are any open questions, I'm more than willing to help you out as best as I can. Until then, working on a screen with a higher resolution seems like the most promising workaround.

[ptziegler]

The customer has made the installer and the zipped Eclipse installation available, however, so if it would help to get the WindowBuilder Pro jars, I can probably provide those.

I appreciate the offer, but I don't think that's necessary. From what I can tell, the underlying problem is caused by the JDK itself. If you try to show a Swing component that is larger than the screen, it will instead maximize. I.e. the new width and height are smaller than or equal to the screen size.

I've tried a couple of things and so far, the results look promising. I'll try to commit this change some time today. Could you try out one of next weeks nightly build and give feedback whether this also works on your side?

[Zastai]

Absolutely. Thanks a lot!

[ptziegler]

Windows put up a little bit of a fight, but the fix is included in the latest nightly build:
https://download.eclipse.org/windowbuilder/updates/nightly/latest

[Zastai]

That certainly looks like it resolves it - excellent.
What sort of timeframe can we expect for that to land in a release?

[ptziegler]

What sort of timeframe can we expect for that to land in a release?

We just missed the 1.13 release window, so this fix will be available with the 1.14. The next release is planned together with the Eclipse 4.30 on December 6th, with the first milestone being scheduled for October 6th.