Forum

Hello,

it seems to me, that Prof-UIS uses the order in m_pDockSite->m_listControlBars and PtInRect() to determine a docking container, that fits to the current mouse position, when a control bar is about to be dragged.

Sometimes this causes a problem, when a bar is dragged over a visible bar, that covers another bar. Sometimes it happens, that the docking markers of the covered bar gain priority over the docking markers of the visible bar making it impossible to dock the dragged bar together with the visible bar.

It would be helpful, if the Z-order of the available bars would be evaluated, too, and if the bar with a "topmore" Z-position (i.e. that bar, that is currently "visible" at the mouse position) would receive priority over a covered bar.

We confirm the target bar hit testing is not always corresponding to Z-order of floating mini frame windows. But in all such cases the following is true: some of overlapped floating windows are placed into absolutely unusable state. So typically you don’t face the incorrect Z-order hit testing because you are keeping floating window so they are not intersected with each other.

Hello

I am afraid that I don’t agree with your response. It is common sense under Windows to allow floating windows to overlap each other. It is usually also possible to have full access to all features of the topmost window. You are right, that some of overlapped floating windows are placed into absolutely unusable state. But this is not true for the topmost, fully visible window of such group of overlapping windows.

With Prof-UIS, however, it is not always possible to drag another bar from another part of the screen to a group of overlapping bars in order to dock this dragged bar into the topmost, fully visible container. Sometimes docking markers of other bars appear, that are currently completely covered by the visible bar. These covered bars may even completely prevent the visible bar from acting as docking target.

I think dragging and docking of a bar is somewhat similar to object drag&drop. With object drag&drop it is common sense, that the drop target is always the topmost window. This is not always the case for Prof-UIS dragging and docking. From my point of view this is a bug in Prof-UIS.