Resize cursor not visible when layout members cover the whole canvas area

[gedri]

Hello,

In my application I have a layout filled with widgets with 0 margins, and I want the layout to be resizable.
I am setting the edgeMarginSize to 10 so it will be easy for the user to drag the edges, but the problem is that the cursor only changes to the resize cursor on the single pixel edge, regardless of the value I set to edgeMarginSize.

In fact, the value edgeMarginSize does affect the area where resize can be initiated from, but the cursor does not change accordingly to reflect that area correctly.
The following simple example illustrates it - I have set the edgeMarginSize here to 50 in order to make the problem more noticeable (in my application I would want to set it to 10).

With this example, you can actually start resizing the layout fairly far away from the edge (up to 50 pixels), but the cursor will only change to the resize cursor on the single border pixel which makes it very confusing.

isc.Layout.create({
width: 300, height: 300,
border: "1px solid black",
canDragResize:true,
edgeMarginSize:50,
members: [isc.Label.create({
contents:"Resize from any side",
align: "center",
width:"100%", height:"100%",
})]
});

If I set a margin for the canvas member, then the cursor will change to resize cursor in the area of the margin, but in my application I need the canvas to cover all the layout without any margins (this is visual design decision).

I am using SmartClient v11.1p_2017-07-30

Thanks in advance.
Gil

[Isomorphic]

If you want resizing of the whole Layout to be possible even when the cursor is not over the Layout, you need to make the contained item canDragResize:true, then delegate the drag to the containing Layout by setting it as the dragTarget.

[gedri]

Thanks for the answer.
What you suggested works on the simple example, but I have 2 problems with it:

1. There appears to be a bug.
If I don't set canDragResize=true and dragTarget=parent on the contained item, resizing from the contained item still works- only the cursor does not switch to 'resize cursor' in order to indicate it.
So either resizing should not work from the contained item, or the resize cursor should appear in order to indicate the it works.

2. In my application, windows have many nested contained items - some intersect with the resizing edge and some don't.
I could write code to recursively scan all nested items, find the ones which intersect with the resizing edge and set canDragResize=true for each one of them (and dragTarget=parent and calculate edgeMarginSize for each one), but this appears like an overkill - is that really the only way to solve this?

Thanks
Gil

[Isomorphic]

Not a bug: a parent can end up starting a drag when a child was clicked, but the child is in charge of what cursor is shown. Asking the whole hierarchy of widgets to try to determine what drag would occur on a click *on every mousemove* is not something we want to require (can be a lot of computation).

Now that you've said that the containing Window can contain various kinds of widgets, we'd recommend reconsidering your design. If there is nowhere to grab at the edge of the Window, then you've got a "dead zone" all around the edge of the Window, where interactive elements provided by child components can't be placed (or just won't work). A simple example is a scrollbar on the right hand side of a grid: if the grid is flush to the right edge of the window, then either part of the scrollbar doesn't work or resizing is no longer possible along that edge. There are lots of other examples, like collapsed sections (bottom) or collapsed Layout members (left).

That all said, if you're being forced to proceed with this design, you could install a mouseMove handler on the Window.body that calculates whether you're in the resize zone and changes the cursor on whatever is under the mouse.