GoIconicNode label pos/GoPalette columns

We have populated a GoPalette with some GoIconicNodes. We would like to position the labels according to the docking orientation of the frame hosting the palette, e.g. label to the side. Sample code appears to use SetSpotLocation to specify label positioning; however our invocation of node.Label.SetSpotLocation has no effect no matter what arguments we supply, the label remaining below the icon. What code should we use to position the label relative to the node icon?
Another couple items: We’d like to specify that palette nodes are laid out in a single column or row; is there perhaps an example of how to do this? Also, the nodes in the palette are not the nodes we wish to appear in the canvas when dropped; is it straightforward to handle the drop event to create a new node rather than dropping the dragged node, or are there other issues we should be aware of? Many thanks in advance.

I think you might be able to temporarily set GoIconicNode.DraggableLabel to true when you use SetSpotLocation to position the Label.
To get a single column GoPalette, you can specify the GridCellSize’s Width to be really wide.
The easiest thing to do might be to allow the drop to happen, and then replace the dropped objects. You can do this by defining a GoView.ExternalObjectsDropped event handler and iterate through the resulting/modified Selection (but remember that you can’t modify a collection while iterating through it!).
A “better” way to go is to override GoView.DoExternalDrop, as several of the example applications do. There you have the flexibility to do what you want instead of the standard behavior. This includes handling drops with arbitrary data formats. Take a look at DoExternalDrop as overridden in ProtoApp and in OrgCharter, where different choices are made.

Setting the DraggableLabel property does the trick thank you. Two issues now arise. What we have is a palette trying to look something like the VS.NET IDE toolbox, with 16x16 icons labeled to the side. However the palette layout always skips the second cell, so we have (with asterisk being an icon)
* Label 1

  • Label 2
    * Label 3
    The cell width is 600 and height is 19. We tried changing palette.AlignSelectionObject to no effect. Anything else we might tweak to fix this?
    Also, occasionally, as others have recently noted I believe, when you drag a palette node, you wind up dragging the node around within the palette window (no no-drop cursor), instead of dragging the node to another window. We played around with this, and it seems that when you grab the node at its top border pixel, and drag it slowly downward a single pixel, that then the continuation of the drag operation becomes intra-window. I’m guessing that the reason is often not easy to recreate this is that often the icon border pixels are transparent, and one usually would pick a visible part of the icon to grab onto.

That initial skip is a bug. Try setting the Y value of the GridOrigin to zero.
I still can’t reproduce that dragging-an-object-within-the-palette-window bug. What version of .NET are you using?

OK, that origin fix works also, thank you. I’m using .NET framework 1.1.4322. We can reproduce that palette object drag anomaly more often than not. It will occur if you start the drag with the cursor on the inside edge of the GoIconicNode icon selection rect, doesn’t matter which side.

The procedure in the previous post for reproducing that drag anomaly was wrong. Rather, it appears to occur when the both node selection and node begin drag occur on the same mouse down. To reproduce, 1. hit esc to clear all selections; 2. click on an icon and drag with a single mouse click.

Well, I’ve tried that, and variations of what you suggest, at least a hundred times now, and I have yet to see it happen once.
Assuming this is a timing problem, I also tried when the palette window did not have focus and while a bunch of compiles were going on concurrently, in order to slow down my machine, so that I could try to “flick” the node in the palette with a mouse down and move as fast as I could. I would sometimes miss the node and get a rubber-band rectangle, but otherwise it always worked.