Rename Columns improvements

[dannyparsons]

Data Frame > Rename columns. This currently is only for one name at a time, and that is probably a good default. Ideally it would also be possible a) to make a sequence of names and b) to have a grid where the existing names are in one column and the new names can be typed into the second. An alternative (is it possible?) is to type directly into the column header field?

previously here #1781

[dannyparsons]

b) not possible because of reogrid. We can now type column names into the column metadata grids though

[rdstern]

I like the way the column names can be typed into the column metadata grid. I suggest this is sufficient for now. Later, perhaps keeping the issue live, there is a whole issue of selecting names of columns, i.e. Find, etc which links also to the need for filters to be able to choose a subset of columns as well as rows.

[rdstern]

A small improvement that should be very easy to do is as follows: Please compare Rename column (from right click) at the top With Rename from the bottom right click, which is for the data frame.

They look slightly different - which is one problem.

But the particular small point is that the rename data frame suggests a new name which is the same as the old one. That's nice, because I usually want a small edit of the existing name.

In contrast the rename column suggests the last name - which is dangerous and confusing and has never been what I wanted. This should be easy to fix, so I have made it 0.4.10.

[Patowhiz]

I'm addressing this

[Patowhiz]

@rdstern what about the column label. Do you think it will be a plus if it could show the label name of the selected column i.e when a user selects the column to rename, the receiver is filled with column name from the selector and the label is filled with label of the selected column. Though this functionality is already addressed in the column metadata grid. I feel like it can help especially when a user is renaming and setting labels for several columns.

[rdstern]

I agree and it would be good for the 2 dialogues (rename column and rename data frame to look similar. They can't be the same, because the data frame one doesn't have the same selector.

[Patowhiz]

@dannyparsons I have made the simple changes that @rdstern asked for and enhanced the label input to be capable of displaying labels of the selected column. However I still feel the grid solution you suggested above will be a better solution when it comes to renaming more than 1 column at the same time. I don't know the urgency of this but this can be done or we can update the "Help menu" for renaming columns and instruct the user that if he want to rename more than one column in a less tedious manner then He/She should simply activate the Column Metadata grid.

[Patowhiz]

@dannyparsons , @shadrackkibet was proposing that for dialog Column Rename, when a user selects a column in the DataView and goes to the dialog through the Prepare > DataFrame > Rename Column, then the dialog should know the column selected and should automatically put it as the selected variable. Should this functionality be added?

That calls for minor modification of ucrDataViewaccess of its subroutine, in particular the SelectedColumnsAsArray() from private to public

[Patowhiz]

@shadrackkibet the above comment was answered. @dannyparsons and I agreed that this functionality should be left as it is for the time being. To prevent confusion. The user will just be seeing a blank receiver and will have to retrace his steps and use the correct steps

[dannyparsons]

Yes, it's an interesting suggestion and good to see people thinking about these features. Here was my thinking in more detail:

That's a sensible point, in that very specific case I can see why a user might expect that behaviour, however it's unlikely to confuse them because the receiver will just be empty, so they will just have to do another step that they thought would be done for them. Whereas, I can see cases where this implementation will cause confusion or users making mistakes. So between those two, we should be more concerned about preventing confusion and mistakes, at the expense of making it a little bit more efficient in some case.