Member of RibbonGroup displayed at bottom of RibbonGroup

[dbscott525]

With this code:

[B]public[/B] [B]class[/B] TestLayout [B]extends[/B] VStack {
    [B]public[/B] TestLayout() {
 
        RibbonBar ribbonBar = [B]new[/B] RibbonBar();
        addMember(ribbonBar);
 
        RibbonGroup ribbonGroup = [B]new[/B] RibbonGroup();
        ribbonGroup.setTitle("Add");
        ribbonBar.addMember(ribbonGroup);
 
        Img addImg = [B]new[/B] Img("ConversationGuide/Edit/add.png", 18, 18);
        ribbonGroup.addMember(addImg);
 
    }
}

The image added to the RibbonGroup is placed at the bottom of the RibbonGroup with a large margin above the image.

How do I get it to be placed at the top of the RibbonGroup?

[Isomorphic]

Both RibbonBar and RibbonGroup are custom layout widgets. You should use ribbonBar.addGroup() and ribbonGroup.addControl(), rather than directly calling addMember().

Secondly, RibbonGroups are designed to provide a panel-like interface, where contents of groups are of the same presentation, and functionaility is managed by the group. So, you should not add arbitrary widgets to a group. Instead, create instances of IconButton or IconMenuButton that reference your required image and add these instances via group.addControl(). Then, for attributes that control orientation and size, for example, use methods on RibbonGroup and IconButton. See this RibbonBar sample: http://www.smartclient.com/smartgwt/showcase/#ribbonbar

If you want to just add arbitrary widgets, like Img instances, to a tool-area, consider using a ToolStrip instead: http://www.smartclient.com/smartgwt/showcase/#toolstrip

[dbscott525]

I did use the standard addGroup and addControl. I want to make the control draggable. When I made it draggable the dragging funcitonality wouldn't work. When a control is dragged it is visually left in whatever place it was dropped, no matter where it is dropped. It doesn't seem to support drag and drop types.

Please confirm that drag and drop are or are not supported in the ribbon groups.

[Isomorphic]

You've given no information about *how* you've tried to implement drag and drop - please post your updated code when it changes if you have further questions.

To answer your question, no, there is not currently a custom drag and drop implementation on RibbonGroups - you would have to add a drop handler and have it call group.addControl(control, drop index). That should add the control properly at the drop position and reflow the group accordingly.

[dbscott525]

You've given no information about *how* you've tried to implement drag and drop - please post your updated code when it changes if you have further questions.

Here is the code that demonstrates the problem:

[B]public[/B] [B]class[/B] TestLayout [B]extends[/B] VStack {
    [B]public[/B] TestLayout() {
 
        setWidth100();
 
        RibbonBar ribbonBar = [B]new[/B] RibbonBar();
        ribbonBar.setWidth100();
 
        RibbonGroup addGroup = [B]new[/B] RibbonGroup();
        addGroup.setTitle("Add");
        ribbonBar.addMember(addGroup);
 
        IconButton button = [B]new[/B] IconButton("Add");
        button.setCanDrag([B]true[/B]);
        button.setCanDragReposition([B]true[/B]);
        button.setDragType("add");
        button.setIcon("ConversationGuide/Edit/add.png");
        button.setShowButtonTitle([B]false[/B]);
 
        /**
         * This line causes the above IconButton to be repositioned to wherever
         * it is dragged.
         *
         * Since the button is not dragged to any canvas that has its drop types
         * set to "add" I would expect it not to be repositioned.
         *
         * If this line is removed then the button goes back to its original
         * position.
         */
        button.setDragAppearance(DragAppearance.[B][I]TARGET[/I][/B]);
 
        addGroup.addControl(button);
 
        addMember(ribbonBar);
    }
}

Here is what I’m trying to achieve:

1. I would like to have a tool ribbon that has groups of icons that are dragged to various places in my application.
2. This icons will have various effects depending on where they are dragged. For example, the “add” icon will cause a new object to be created where it was dragged to.
3. I don’t want/need the icon be show as selected (visually shown as recessed). This is the current behavior of IconButton. Is there a way to suppress this behavior.

[Isomorphic]

Thanks for the test code / description. We're taking a look at this and will get back to you soon

Regards
Isomorphic Software

[Isomorphic]

Apologies for the delay - this has been fixed for builds dated January 15 and later.

For any future posts, please do check the console for errors and let us know what they are - there were lots being generated in this case.

[dbscott525]

I have tested this a found that it causes drop to sporadically fail. This means that sometimes the drop handler is not called while other times it is called. I have not been able to reproduce in a simple test case and can only demonstrate this failure in our application. Even in our application, this failure doesn't occur all the time.

Any suggestions on how I can provide you information to diagnose this problem given that I can provide you a simple test case?

This means that we can't upgrade to this latest version because it breaks our application.

[Isomorphic]

Hi Bruce,

Probably the best first step here would be to show the developer console and enable "debug" level logging for both "EventHandler" and "dragDrop" within your running app.
Then clear the results with the clear button and perform a working drag/drop interaction and show us the generated output.
Then see if you can reproduce the failing drag/drop interaction - once you get this to happen, show us the generated output from that. Even if there isn't any obvious error logged, comparing the two will very likely reveal what the problem is.

If this doesn't get us anywhere, we could set up a live-debug session of your app with one of our engineers, but let's try this first.

Regards
Isomorphic Software

[dbscott525]

I have a slight update on this.

With a little more experimentation I found that

• the drop that’s failing is highly dependent on the place in the HLayout where the drop is placed.
• When the drop fails it shows a vertical line at the position it is being dropped.
• When it succeeds, it shows a dot.

It seems that when dropping to an HLayout it should always display a vertical line. Perhaps, if you track down when the vertical line is displayed versus the dot you can find out why it fails.

I have the output from the console for both successful and failed drops. However, this discussion forum won't allow that size of file. How, can I send these files to you?

[dbscott525]

These logs basically indicate that in the failure case, the drop occurred over a flowLayout, which is a child of the HLayout you actually seem to have proper drop handling logic on, and the flowLayout believed it would handle the drop directly and as such didn't pass the event up to the parent [whereas in the success the drop occurred directly over the HLayout].

Based on a better understanding of the circumstances causing this failure I was able to construct a test case. This fails on the current version (5.0-p20150628) we are using. I don’t know why our application is not failing in the same way using 5.0-p20150628.

Here is the test code

[B]public[/B] [B]class[/B] FlowLayoutDropFail [B]extends[/B] VStack {
 
    [B]public[/B] FlowLayoutDropFail() {
        setBorder("2px solid blue");
        setMembersMargin(10);
        setPadding(10);
        addMember([B]new[/B] TestRibbonBar());
        addMember([B]new[/B] TestHLayout());
    }
 
    [B]private[/B] [B]static[/B] [B]class[/B] TestRibbonBar [B]extends[/B] RibbonBar {
        [B]public[/B] TestRibbonBar() {
            addGroup([B]new[/B] TestRibbonGroup());
        }
    }
 
    [B]private[/B] [B]static[/B] [B]class[/B] TestRibbonGroup [B]extends[/B] RibbonGroup {
        [B]public[/B] TestRibbonGroup() {
            setTitle("Test");
            addControl([B]new[/B] TestIconButton());
        }
    }
 
    [B]private[/B] [B]static[/B] [B]class[/B] TestIconButton [B]extends[/B] IconButton {
        [B]public[/B] TestIconButton() {
            setCanDrag([B]true[/B]);
            setCanDragReposition([B]true[/B]);
            setCanDrop([B]true[/B]);
            setCursor(Cursor.[B][I]MOVE[/I][/B]);
            setDragType("TestHLayout");
            setIcon("ConversationGuide/BLUE_O.png");
            setShowButtonTitle([B]false[/B]);
            setShowFocused([B]false[/B]);
            setShowTitle([B]false[/B]);
        }
    }
 
    [B]private[/B] [B]static[/B] [B]class[/B] TestHLayout [B]extends[/B] HLayout {
 
        [B]int[/B]                 drops = 0;
        [B]private[/B] [B]final[/B] Label label;
 
        [B]public[/B] TestHLayout() {
 
            setBorder("2px solid black");
            setCanAcceptDrop([B]true[/B]);
            setDropTypes("TestHLayout");
            setMembersMargin(10);
            setPadding(10);
 
            label = [B]new[/B] Label();
            label.setContents("Nothing Dropped");
            addMember(label);
 
            addMember([B]new[/B] TestFlowLayout());
            addMember([B]new[/B] ColoredCanvas("red"));
 
            addDropHandler([B]new[/B] DropHandler() {
                @Override
                [B]public[/B] [B]void[/B] onDrop(DropEvent dropEvent) {
                    dropEvent.cancel();
                    label.setContents("drop #" + ++drops);
                }
            });
        }
    }
 
    [B]private[/B] [B]static[/B] [B]class[/B] TestFlowLayout [B]extends[/B] FlowLayout {
 
        [B]public[/B] TestFlowLayout() {
            setBorder("2px solid red");
            setDropTypes("TestFlowLayout");
            setHeight(120);
            setWidth(250);
 
            /**
             * Adding this line causes drops in the TestFlowLayout region to
             * fail for the TestHLayout.
             */
            setCanAcceptDrop([B]true[/B]);
 
            addTile([B]new[/B] ColoredCanvas("blue"));
            addTile([B]new[/B] ColoredCanvas("green"));
        }
    }
 
    [B]private[/B] [B]static[/B] [B]class[/B] ColoredCanvas [B]extends[/B] Canvas {
        [B]public[/B] ColoredCanvas(String color) {
            setBackgroundColor(color);
            setHeight(100);
            setWidth(100);
        }
    }
}

[Isomorphic]

Just a note to let you know, we're looking into this and will update here when we have more information.

[Isomorphic]

Which version of SmartGWT are you using? 5.0 or 5.1?

[Isomorphic]

Ah, apologies, we see that it's 5.0.

[Isomorphic]

We're not sure if you're claiming a *recent* regression, or one since the build you mentioned several times (from June of 2015), but we're not seeing any evidence of a regression here.

What's happening is that your inner layout specifies dropTypes which do not allow for the dragType of the icon being dragged. The icon has "TestHLayout", as does the outer-layout, but the inner layout has "TestFlowLayout". Thus, the icon you're dragging is not compatoble with the layout you are dropping it onto. The inner layout is attempting to process the drop (becuse you've set canAcceptDrop:true), rejecting it because it's not of an acceptable dragType (icon.dragType is not in layout.dropTypes), and consuming the event.

a) If you want to drop items onto the inner layout and have the *outer layout* catch the drop, you just need to get rid of the dropTypes on the inner layout. That will cause the drop to bubble (because it doesn't violate the inner-layout's dropTypes).

b) If you want the inner layout to react to the drops itself, add the icon's dragType to the layout's dropTypes.

In other words, if a widget specifies its own dropTypes, they are enforced - if a drop event doesn't fit them, it is consumed.

This is the behavior we expect so, as we say, this doesn't appear to be any kind of regression, or anything specific to the widgets you're using. If you're confident that it *is* a regression, we'll need more information about exactly *what* you believe has regressed, and the exact version you think it's regressed since, so we have a timescale to work with in looking for the problem.

If there turns out that you agree there is no regression, and you still need to do exactly what your sample was trying to do, we may be able to find an EventHandler workaround that would enable you to do it.

Can you also clarify the actual version and build you're currently testing with?