Odd Table Widget & Column View behavior

[PhotonDemon]

Hi All,

I am seeing odd Table Widget & Column View behavior with VA Smalltalk V8 and Windows 7. There is a feature of these widgets where you can set columns to "reorderable". This means the user can left click on the heading of a column and drag it to the left or right and switch the columns around. This works fine in when testing in the development environment but does not work with my packaged image.

I am also using the drag and drop feature to allow the user to select and drag some rows of one table widget and drop them in an other table widget. In my packaged image this works with the "right" mouse button, in the development environment it works with the "left" mouse button. I don't know if this has anything to do with the problem above but it is odd . I currently have the drag/drop spec set to source and target and move+copy+link. I think move is all I need but I left it at move+copy+link, the last time I played with it.

I am also using the sortable column feature, which seems to work just fine but I mention it here just in case it has something to do with the other features.

So, am I doing something wrong? Is there something else I should be doing? Is there something I shouldn't be doing?

Lou

[Eric Clayberg]

This is configurable. See EwDragAndDropManager>>#button:

For example...

EwDragAndDropManager default button: CwConstants::Button1
EwDragAndDropManager default button: CwConstants::Button2
EwDragAndDropManager default button: CwConstants::Button3
EwDragAndDropManager default button: EwConstants::ButtonDrag

[PhotonDemon]

Hi Eric,

Thanks for the prompt reply. The behavior that troubled me the most was that the "reorderable" feature didn't seem to work with my packaged image. As it turns out it does work but you have to hold the mouse button down on the header for a long time in order to grab the column and move it. In the development environment, grabbing the header happens quickly and the mouse pointer changes to horizontal arrows to show you that you have grabbed it and can move it. In the packaged image, when you finally have hold of it, the header changes color (in my case blue) and the mouse pointer sometimes changes and sometimes doesn't. This would be fine if it happened faster. The program isn't doing anything else but dealing with the mouse.

As far as the drag/drop button goes, the use of the "left" button in the packaged image is fine. It just seemed odd that it was the opposite in the development environment. And with the "reorderable" feature seeming not to work, it made me wonder.

Lou

[Eric Clayberg]

As far as the drag/drop button goes, the use of the "left" button in the packaged image is fine. It just seemed odd that it was the opposite in the development environment.

Left-button drag/drop interfered with left-button drag multi-select in most of the browser panes, so we went with right-button drag/drop for the browsers.

BTW, the default drag button used in the browsers is actually user configurable, so you can use left-button drag there as well.

[PhotonDemon]

Hi Eric,

Again, thanks for the prompt reply.

Left-button drag/drop interfered with left-button drag multi-select in most of the browser panes, so we went with right-button drag/drop for the browsers.

I am using multi-select and allow dragging and dropping more than one item at a time, so would it be better if I used the right-button? It doesn't matter that much to me. What ever works with the least problems is fine.

Lou