Preventing a toolstrip.


  • Impossible Mission Players - A

    Continuing the discussion from Status: THE VERONICA MARS THE WALLACE! WERE WE EVER FRIENDS?!?:

    @Tsaukpaetra said:

    Status: How is it possible that the user can ADD a toolstrip to a toolstrip panel that's been disabled, but can't subsequently REMOVE it?
    You'd think if something was disabled that any and all user interactions are... disabled!

    So the main goal is to prevent the user from dragging a toolstrip outside the toolstripcontainer it's a part of. The ToolstripContainer has four panels, one of which the dragged toolstrip is a child of.

    The goal is to prevent the following from happening:
    (The toolbar from the right panel got moved to the left panel).


  • Impossible Mission Players - A

    @ben_lubar said:

    Is the button to add a toolstrip part of the thing being disabled?

    No this happens automatically during a drag-drop event. Essentially, while dragging a toolstrip, it gets added/removed from any available toostrippanel it's over as you move it around.


  • Impossible Mission Players - A

    @ben_lubar said:

    Is the button to add a toolstrip part of the thing being disabled?

    No this happens automatically during a drag-drop event. Essentially, while dragging a toolstrip, it gets added/removed from any available toostrippanel it's over as you move it around.

    <!-- Not too similar-->


  • Is there any reason the toolstrips that are associated with locations on the UI need to be movable at all?


  • Impossible Mission Players - A

    @ben_lubar said:

    need to be movable at all?
    To be nice? It was an idea I had that I though should be (fairly) easy to implement, i.e. "If this thing did not come from this container, don't allow it to drop here."
    Instead, what I get is "Screw you, we're not going to tell the application anything other than Surprise, you've got a new control added/removed to this panel!"

    My best solution so far is to store the control's parent and compare before-drag and after-drag to ensure it stays where it's supposed to, but this means that the user can fully drag and drop the toolstrip and let it go before it will disappear back into the original position, a surprising and unexpected experience.

    In most applications that I've seen do this, the toolbar just simply doesn't respond to locations it's not allowed to be dropped onto, and this is more what I'm trying to accomplish....


  • Impossible Mission Players - A

    I guess I'm going to keep it as simple as possible and just clip the mouse to the dimensions of the control

    
        Private Sub ToolStrip1_BeginDrag(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ToolStrip1.BeginDrag
            'Set the cursor clipping for the duration of the drag
            Cursor.Clip = sender.Parent.Parent.RectangleToScreen(sender.Parent.Parent.ClientRectangle)
        End Sub
    
        Private Sub ToolStrip1_EndDrag(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ToolStrip1.EndDrag
            'Reset the Mouse clipping
            Cursor.Clip = Nothing
        End Sub
    

    Effect is the same: Since the cursor can't leave the area of the container object, then obviously they can't drag the tool strip outside of it into another container!

    🤦 Silly hack, but it works (mostly, there's a little bit of trickery you can do by rubbing the corner bordering two containers, but whatever).



  • Isn't there a DragOver event or something where you can set AllowDrop to false?


  • Impossible Mission Players - A

    @coldandtired said:

    Isn't there a DragOver event or something where you can set AllowDrop to false?
    So here's the trick, right?
    Under normal circumstances, yes, you should be using the Drag Events for this, and in the QueryDragContinue-something-or-other event, you are supposed to be able to check the Sender (that which is being dragged) and e.Cancel it (or whatever the equivalent is).

    The trouble is that ToolStrips are special, and don't send ANY drag-related events to ANYTHING (except the Drag Start and Drag End on the control itself), and so none of the usual events happen to allow such nice things.
    I literally wired up empty event handlers to all drag events on the containers, and the panels inside them (where possible), set breakpoints (so if any of them ever fired I would know, even if they don't do anything), and I was able to wave the toostrip around, bouncing it into and out of the panels all willy-nilly like, and none ever fired. 😦

    I think it was just an oversight on how MS coded the container, because it makes sense that no events are fired because you're not dragging the control onto it (the container itself can't accept toolstrip controls), and each of the panels don't really support drop events (why? Because you're expected to watch the ControlAdded and ControlRemoved events!).



  • I tested it out with normal panels and it was working as expected (or what I think you expect)

    void panel1_DragEnter(object sender, DragEventArgs e)
        {
            ToolStrip ts = e.Data.GetData(typeof(ToolStrip)) as ToolStrip;
            Panel panel = sender as Panel;
            if (ts.Parent == panel)
            {
                e.Effect = DragDropEffects.Copy;
            }
            else
            {
                e.Effect = DragDropEffects.None;
            }
        }

  • Impossible Mission Players - A

    @coldandtired said:

    normal panels
    Ah, I think that's my problem. I'm using the panels that come out of rick-clicking the toolstrip and choosing "Embed in toolstrip container" (or whatever). This operation gives me a container containing center, left, right, top, and bottom panels to hold the toolstrip.
    I'm certain if I replicated this control in code I could probably get it to work like so, but not using the one automatically made by Visual Studio...



  • I see what you mean now. It moves the toolstrip without giving you the chance to check it first, and places it in the new spot before you can even let go of the mouse button.


  • Impossible Mission Players - A

    @coldandtired said:

    without giving you the chance to check it first
    Yeah. It's weird, but I think I understand why it's behaving like that, because in order for it to "preview" what happens when you finish the drop, it has to tell the target control "Hey, there's a new control here in this position!", and it apparently can't do that in simulation/preview.



  • @Tsaukpaetra said:

    I think I understand why it's behaving like that

    I think it's simpler than that. The ToolStrip control implements drag and drop for you, so you get what the authors wanted. Other controls expose event so that you can implement drag and drop, so they can be tweaked to your heart's content. Unfortunately Microsoft didn't make the ToolTip behavior easily overridable.


  • Impossible Mission Players - A

    insert rant about companies thinking they know what users want


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.