I keep on having intermittent problems with dropping on nexus docks. These problems occur with the dock collapsed to an edge, and with magnify enabled (but not ripple or anything else).

Typically, what I'll do is drag the link from the windows start menu (or wherever, the source isn't important, it's not a disappearing source thing), and when I drag it over the hidden nexus dock and the dock appears, sometimes it opens the "wrong" subdock, and then I get all sorts of problems.

By "wrong", I mean if the system is a bit overloaded and there's any delay in the dock appearing, by the time the dock is displayed, Nexus thinks I've had the drop target over whichever subdock happened to be under the mouse pointer while the dock was trying to unhide itself, and there's just no way I can change to a different subdock.

Now, one of three things then happens. Either I keep trying to drag the same item, in which case it DOES drop wherever I put it, but I can only "see" the main dock and the "wrong" subdock, so dropping it there is useless, since trying to drag THAT dropped icon later on results in WS shutting down immediately.
Or, if I 'escape' and try to go and drag the item a second time, the original (incorrect) subdock's little arrow thingy keeps appearing, and the same subdock keeps appearing, but I can never select any other subdock (even after letting the dock hide and re-open).
Or, the whole Nexus dock starts "shaking" - like it's try to paint itself but there's an invisible icon somewhere in the main dock area and it keeps trying to un-magnify and re-magnify.

So there are two separate but related issues here:
1) If there's a delay any time Nexus uncollapses, that delay is taken into account by the "autocollapse" and "subdock expand", and may expire before the dock is even painted, which leaves the drag operation in a bad state, and
2) Once a subdock is opened to accept a drop target, no other subdock can then be opened instead. I'm not sure if this is a bug or a feature, I'm assuming it's a feature, but it feels like a bug...

I can pretty much reproduce this every time the system load increases, and I can definitely reproduce the "only one subdock drop" problem every time, without fail.

Any ideas on how to fix this would be much appreciated. This isn't a showstopper, but when I'm in the state I am now (newly built system, lots of new apps being reinstalled, lots of dock activity), it's a little bit frustrating.

Ok, I can see where, if there is a big delay between the dock starting to un-collapse and the end of the un-collapse animation, the auto hide timer could kick in. I fixed that already.

However, during the un-collapse animation, the dock is disabled, i.e.; it does not accept/react (or should not!) to items being dragged over it. This means sub-docks should not automatically open UNTIL the animation is complete.



Not sure what is going on there, since other sub-docks can be opened in turn by dragging the item over either the little sub-dock indicator, or, in the case of dock place holders, over the place holder itself - UNLESS the source of the item is actually another sub-dock within the same dock (the source must always exist in order to clean up afterwards).

Jorge, you may have fixed the subdock thing when you fixed the uncollapse delay, because I seemed to mainly get the problem when the parent dock took some time to display, and whatever subdock (dock placeholder) was under the mouse cursor when the unhide event was triggered. So I'll check out the new code and see if that's where I was going wrong.

On a kind of similar note, I've noticed that if I drag a NextStart menu item, say from a submenu, intending to drop it on a dock, if I accidentally drag the item over any NS menu that's still open (my dock is on the left of the display, so any NS menu item has to go back across all the submenus), the NS menu "captures" the item, and continuing to drag it over to the dock results in "ghost" drag items on the dock or desktop, and the NS menu captures the dragged item instead. My workaround is to drag up and then left so I avoid the NS menus, but if I'm trying to drag onto a subdock "low down" in the display, it's almost impossible to do unless I manually move the NS menu away to the right and drag from there. I'm not sure if this is related, or if I should put it in a separate thread...

Hey, you know what?! Looks like the drag & drop problems you described above come from you 'crossing over' a NexTSTART item over another NextSTART menu on your way to a NeXuS dock!

I was able to reproduce two of the problems you mentioned: the dock not changing the insert point AND the dock 'shaking' (as you put it) as it constantly magnifies and un-magnifies.

Haven't gone as far as fixing it, but reproducing the problem here 100% of the time should be enough for me to figure out why this happens.

Btw, what do you mean by 'captures'? Does the item get added to the NS menu?

Another important question: as you drag over the previous sub-menus, do new sub-menus open (closing the original source menu) because of the 'spring folders' feature?

Yes, the item typically gets left on the main NS start menu.

It's actually a bit more complicated than that, though...

If I shift-drag a submenu item, the spring folders thing works, but the item doesn't get captured until after I drag it over the Nexus dock and/or a subdock opens to accept the item. If the dock procedure doesn't get to the point of "accepting" the item, the menu capture doesn't seem to occur - but then the item gets 'lost' (I can't find it anywhere, but the original submenu item still exists). Then, if the dock does try to accept the item, after the dock/subdock expands, the NS menu seems to "grab" the item with no ability to stop it, and the mouse cursor isn't a drag cursor any more.

This seems to be a real estate thing (the position of the menu and the dock/subdock makes a difference to the action seen). If the menu isn't anywhere near the dock, it also doesn't always seem to "capture" the item, even if I 'tease' it by dragging the item back over the menu after the dock has prepared to accept the item. It always (repeatably 100%) captures the item if the subdock expands over the NS menu.

I hope that makes a bit more sense.