views:

144

answers:

3

As a pet project, I've been playing with the concept of integrating Aero Glass effects into my SWT application. Łukasz Milewski has an excellent blog post explaining how this can be accomplished, which pretty much boils down to this:

final Display display = new Display();
final Shell shell = new Shell(display);
shell.setLayout(new FormLayout());
final MARGINS margins = new MARGINS();
margins.cyTopHeight = -1;

final Composite c = new Composite(shell, SWT.NORMAL);
c.setBackground(new Color(shell.getDisplay(), new RGB(0, 0, 0)));
final FormData fd = new FormData();
fd.top = new FormAttachment(0, 0);
fd.left = new FormAttachment(0, 0);
fd.right = new FormAttachment(100, 0);
fd.bottom = new FormAttachment(100, 0);
c.setLayoutData(fd);

OS.DwmExtendFrameIntoClientArea(shell.handle, margins);

shell.open();
while (!shell.isDisposed()) {
    if (!display.readAndDispatch()) {
        display.sleep();
    }
}

This works beautifully, until you want to add a control. This results in black remaining transparent:

Transparent shell with control

A follow-up post demonstrates how to do this, too, but requires modifying the SWT library. (At least, I believe so, because private SWT functions are overridden with @Override.)

How can I avoid controls becoming transparent? Even better: how can I benefit from transparency (e.g. placing images on it like so), but use it in a sensible way?

A: 

Put your control beyond glass area or try to use force Background color for the control.

Vladimir
Placing my control outside of the glass area more or less defeats the purpose of the effect. I don't consider "avoiding black" a realistic option, either. I know there's a way of doing this correctly (a colleague mentioned resolving a similar issue in C#), so I'll just keep crunching on it.
Paul Lammertsma
A: 

You are concerned by the solution that overrides internal methods, but you are using an internal SWT class in the first place. This seems like a very hacky fragile way (at least in the current SWT implementation) to add some eye candy to your app... I hope you are not doing this in production code.

TK Gospodinov
Wrapping it in a `try { ... } catch (Throwable e) {}` surely can't hurt. It's just eye candy, so if it fails, no biggie, right? There are some `OS` references in current production code, implemented like that. Is it really very bad practice?
Paul Lammertsma
It's also not so much a *concern* of mine to be overriding private methods; it's more that I just can't get it done without compile errors. What am I doing wrong?
Paul Lammertsma
+1  A: 

The overridden methods are "package private". In order to override them without compile time errors, you have to put your classes into the same package as the super class, i.e. org.eclipse.swt or org.eclipse.swt.widgets package. The blog you cite post actually mentions this implementation detail at the end, so I don't know, it this really answers your question.

the.duckman
I simply read right past that. Surely enough, that allows everything to compile without any problems, but there are plenty of things still not working correctly. A fully working example would be great, because only by setting some constants and some additional cases in `callWindowProc()` can I get `OpaqueText` to indeed display opaque text. I'll update my question with my current code in the morning.
Paul Lammertsma
Since the bounty is expiring, I'll award it to you.
Paul Lammertsma