public class Window

Returns the framework assigned id of this window.

This is the id a port stores at creation and echoes back on every event, so it is also how a window is looked up from Desktop#windowById(int).

Returns the top level container this component currently belongs to, which is either the Form filling the main surface or the Window of a native desktop window, or null when this component is not attached to one.

Prefer this over #getComponentForm() in code that must keep working inside a desktop Window. getComponentForm() keeps its original meaning and returns null for a component hosted in a Window, because a Window is not a Form.

Returns the layer belonging to the given class within the layered pane that spans the whole top level, including the title area, creating it if needed.

The name mirrors Form#getFormLayeredPane(java.lang.Class, boolean) on purpose: Sheet, InteractionDialog and ToastBar attach through this method, and renaming it for windows would fork them.

Returns the region of this top level that is guaranteed not to be obscured by system chrome such as a notch or a rounded corner.

Note the window does not paint this itself, unlike Form. Its layered pane repaints the whole window underneath whatever sits in the pane (#getFormLayeredPane(java.lang.Class, boolean)), so a tint applied in #paint(Graphics) would be composited once for the window and once more for that backdrop, and read visibly darker than the same tint on a form. What covers the window paints the tint instead, exactly once.

Makes sure the component is up to date with the current theme, ONLY INVOKE THIS METHOD IF YOU CHANGED THE THEME!

A window caches the tint it took from the look and feel, so a theme change has to drop it or every later overlay keeps painting the old theme’s scrim.

Returns the region of this top level that is guaranteed not to be obscured by system chrome such as a notch or a rounded corner.

A desktop window has no notch or rounded corner to avoid, so the safe area is the whole window.

Returns the area of this component that is currently hidden by the virtual keyboard.

Always zero: a desktop window has no virtual keyboard overlaying it.

Sets whether the platform draws a title bar and border for this window.

An undecorated window draws no chrome of its own either, and #getDragRegionStatus(int, int) refuses to drag it, so the application has to supply both. A Toolbar is not the way to do that: it is installed through Form#setToolbar(Toolbar) and is bound to a form throughout, so it cannot be put on a window.

Returns this window’s bounds in desktop coordinates, including any native chrome.

This is a different coordinate space from Component#getWidth() and Component#getHeight(), which report the Codename One content size.

Sizes this window so its Codename One drawable area is the given size, rather than its native frame.

#setWindowSize(int, int) asks the platform for a frame of that size. On a decorated window the title bar and borders sit outside the surface Codename One paints into, so the drawable comes back smaller – and content sized to fit is clipped along the bottom by exactly the height of the title bar. This asks for the drawable size instead and lets the window work out its own chrome.

The correction is applied once, after the native window exists, and only when the platform actually disagrees. A port whose chrome varies with the size it is given cannot make this oscillate.

The usable area of this window’s display, in the device pixels a layout uses.

Monitor#getWorkArea() is in desktop coordinates, which count pixels only where the platform’s own coordinates do. Compared raw against a preferred size, the usable width on a display at twice the scale reads as half what it is – so a dialog capped at nine tenths of it was really held to about 45%.

Restores this window from a minimized state.

A window the application hid is not minimized and is not brought back by this. #hide() leaves the peer alive with the hierarchy invisible, so handing that peer to the platform’s restore puts the native window back on screen while the framework still counts it as hidden – and nothing ever repaints it, because the paint loop skips a window that is not showing. The result is a blank or stale window that #isWindowShowing() denies is there. Bringing a hidden window back is #show()’s job, which restores the whole lifecycle rather than just the native state.

Shows this window and blocks the calling code until it stops being on screen – whether that is #dispose() or #hide().

Hiding ends the wait as surely as disposing does, and that is deliberate: the window is closed as far as the user is concerned, and parking the caller on a window nobody can see or reach would hang it. #HIDE_ON_CLOSE reaches this path, so a modal window with that close operation returns here still live and reusable. Code that runs cleanup after this returns should therefore ask #isWindowDisposed() rather than assume it – the window may be waiting to be shown again. Minimizing does not end the wait; a minimized window is still up.

This uses the same mechanism as a modal Dialog: the caller is parked while the event dispatch thread keeps running, so every other window carries on painting and animating. Input to the windows this one blocks is dropped by the framework, so modality behaves the same way on every platform whether or not the platform implements its own.

Indicates whether this window has completed at least one paint cycle, and so whether its content – rather than an empty surface – is what a capture would return.

A window’s raster exists from the moment it is shown, so capturing before the first paint yields a blank frame of the right size rather than a failure. Test and tooling code that wants the content should wait on this.

Captures this window’s current contents.

The ordinary Display#screenshot(com.codename1.util.SuccessCallback) can only see the application’s main surface, so a window has to be captured through the window manager instead. This is what the windowed screenshot tests use.

Sets the top level that owns this window. An owned window stays above its owner and is disposed with it.

The name avoids setOwner, which Component already uses for an unrelated hit testing mechanism.

If this Component is focused, the pointer pressed event will call this method

A Container has no hit testing of its own – Form does that work itself – so a Window has to as well, or a press would never reach the component under it. This is the same walk Form performs, without the menu bar special case a window has no equivalent of.

If this Component is focused, the pointer dragged event will call this method

The multi pointer form, which is how a pinch reaches the component under the fingers. Without it Component’s version runs instead: it tests the pinch on the window itself and then collapses the event to a single coordinate, so the pressed child gets an ordinary one-finger drag and never its pinch callbacks.

If this Component is focused this method is invoked when the user presses and holds the key

The keyboard counterpart of #longPointerPress(int, int), and broken the same way: Display dispatches a long key press to the top level, Component’s implementation is empty, so holding a key inside a window reached nothing. Found by checking what else shares that dispatch site rather than waiting for it to be reported.

If this Component is focused this method is invoked when the user presses and holds the pointer on the Component

Component’s implementation only fires listeners attached to this window, so without this a long press on a button inside a window reached nothing – neither the component nor its context menu.

Invoked for devices where the pointer can hover without actually clicking the display. This is true for PC mouse pointer as well as some devices such as the BB storm.

Component’s implementation is empty, so without this a window would receive hover events and drop them: no tooltips, and no hover state on the components under the pointer.

Returns this top level as a Container.

A Java interface cannot extend a class, so without this a TopLevelContainer reference could not be handed to anything expecting a Component.

If this Component is focused, the key pressed event will call this method

A window dispatches keys itself, exactly as Form does. Inheriting Container’s handler instead only forwards to a lead component, so the focused component would never see a key, arrow traversal would not work and nothing registered through #addKeyListener(int, ActionListener) would ever fire.

This is the same shape as Form#keyPressed(int) minus the menu bar, which a window does not have: commands reach the desktop menu instead.

Adds a Component to the Container

Adds to the content pane, mirroring Form, so window.add(cmp) means window.getContentPane().add(cmp). Container’s add() is final and routes through here, so overriding addComponent covers both.

This method adds the Component at a specific index location in the Container Components array.

The indexed overloads need delegating too. They are separate methods rather than paths through the two above, so without these an indexed add put the component in the window root beside the title area and the content pane – where the root’s own BorderLayout would place it, and where #getContentPane() cannot see it.

Replaces this window’s content, animating the change.

The window analogue of showing another Form with a transition, and the reason a Form transition into or out of a window is not a thing: a transition paints the two screens into one Graphics covering one surface, and two operating system windows are composited by the window server, on monitors that may not even share a scale factor. There is no shared context to draw an in between frame into. Moving between screens inside one window is an ordinary transition, and this is it.

Animates a pending layout into place, this effectively replaces revalidate with a more visual form of animation

See:

Form hi = new Form("Layout Animations", new BoxLayout(BoxLayout.Y_AXIS));
Button fall = new Button("Fall");
fall.addActionListener((e) -> {
    for(int iter = 0 ; iter < 10 ; iter++) {
        Label b = new Label ("Label " + iter);
        b.setWidth(fall.getWidth());
        b.setHeight(fall.getHeight());
        b.setY(-fall.getHeight());
        hi.add(b);
    }
    hi.getContentPane().animateLayout(20000);
});
hi.add(fall);

This method is the exact reverse of animateLayout, when completed it leaves the container in an invalid state. It is useful to invoke this in order to remove a component, transition to a different form or provide some other interaction. E.g.:

Form hi = new Form("Layout Animations", new BoxLayout(BoxLayout.Y_AXIS));
Button fall = new Button("Fall");
fall.addActionListener((e) -> {
    if(hi.getContentPane().getComponentCount() == 1) {
        fall.setText("Rise");
        for(int iter = 0 ; iter  {
            hi.removeAll();
            hi.add(fall);
            hi.revalidate();
        });*/

    }
});
hi.add(fall);

This method is the exact reverse of animateLayoutAndWait, when completed it leaves the container in an invalid state. It is useful to invoke this in order to remove a component, transition to a different form or provide some other interaction. E.g.:

Form hi = new Form("Layout Animations", new BoxLayout(BoxLayout.Y_AXIS));
Button fall = new Button("Fall");
fall.addActionListener((e) -> {
    if(hi.getContentPane().getComponentCount() == 1) {
        fall.setText("Rise");
        for(int iter = 0 ; iter  {
            hi.removeAll();
            hi.add(fall);
            hi.revalidate();
        });*/

    }
});
hi.add(fall);

Is the component a bidi RTL component

Forwarded to the content pane as well as the window root: the application’s layout runs in the content pane, so setting it on the root alone left directional layouts and alignment reversed while isRTL() reported true.