Copy/paste into Standard entities is uncomfortable

Hi,


the copy/paste behavior in Instant-JChem is very uncomfortable.





A) there is no right click functionality for paste and copy


B) activating a column should mark it as active (it works for rows), following EXCEL or spreadsheet logic this is a must.


C) Clicking on a row field name or column field name always means "please activate full row or full column" by not doing so there is always a insecurity, did I do it right? Did I activate it? Which actually needs a second click just for confirmation (which is bad).


D) Delete row and delete column should work via right click


E) Insert row and insert column should have right click, and should insert a column at the left or right of the activated column or row.





Most of the people work with EXCEL so it would be logic


to follow the common spreadsheet logic although it must be said even if EXCEL still suffers from the 8-bit era (only 256 columns allowed and 65k rows) hundreds of developers spent thousands of men-years streamlining every little bit. But still people will feel more comfortable.





Thank you.


Tobias

TobiasKind wrote:

A) there is no right click functionality for paste and copy

you mean Copy/Cut/Paste actions available in popup menu after r-click on table header? yes, these actions can be added there, but the problem is that it always copy the current selection. and when we don't select whole column after r-click to column header it could be confusing. see next point...

TobiasKind wrote:

B) activating a column should mark it as active (it works for rows), following EXCEL or spreadsheet logic this is a must.

originally we had this functionality there - any click on table column header has selected whole column. but it was removed because of two reasons:


1. if you select whole column in master table (in the case of master-detail view), you get all rows selected and so detail table data disappear and all widgets bound to detail table say just "empty selection". Try to select whole column in Wombat activities in sample project and you will see it.


2. there is one important difference between row and column selection in IJC: current query/result set as well as row selection is shared among all views of the same datatree (data trees are these objects under connection in projects explorer). Try to add more form views to the same datatree and play with query and row selection so you will see it. So row selection is shared. The reason is row selection in master table determines the content of detail tables in relational data trees. And selection of columns is not shared and is owned by each widget/form view. Try to add two tables to form and bind them both to the same database table. You will see that column selection could be different in different tables. Then try to select whole column in one of the table, you will see that whole content is selected in other table. And that's the second reason why we don't select whole column after r-click on the header. Maybe it's a little complicated, but try to play with it and I hope you will see the system there.

TobiasKind wrote:

C) Clicking on a row field name or column field name always means "please activate full row or full column" by not doing so there is always a insecurity, did I do it right? Did I activate it? Which actually needs a second click just for confirmation (which is bad). D) Delete row and delete column should work via right click

that was already added to popup menu if you r-click into any cell in table. You will see it in the release next week.

TobiasKind wrote:

E) Insert row and insert column should have right click, and should insert a column at the left or right of the activated column or row.

r-click popup menu is used for context sensitive actions. Delete row or column is reasonable to add there as these actions are really related to the selection context. On the other hand insert row/column are not actions which are related to current selection. In excel you have insert available here because excel is adding rows to the current context (before/after the selected row/column). But this is not our case as this is database application and inserting row in the middle is not supported. You can use sort funtctionality then to see the appropriate order. To summarize it:


1. I think popup menu should stay reasonable short - it would lost its reason if it contains too many actions


2. insert action/column are not action which depends on curent selection, so the currently selected row/column is irrelevant for the insert action


3. both these actions are available in main IJC menu as well as in gridview/form designer toolbar

TobiasKind wrote:

Most of the people work with EXCEL so it would be logic to follow the common spreadsheet logic although it must be said even if EXCEL still suffers from the 8-bit era (only 256 columns allowed and 65k rows) hundreds of developers spent thousands of men-years streamlining every little bit. But still people will feel more comfortable. Thank you. Tobias

I agree that Excel represents de-facto standards for spreadsheets, but the problem is that we cannot copy all the functionality from it. The functionality of IJC is different so also behavior of some actions is different (e.g. excel doesn't change any detail table content if you are changing selection in main table).





Anyway, when thinking about it, we can leave current r-click functionality on table header, but we can add "select whole column" action when user use L-click on table header.





Petr

Just to empahasize the point on ordering or rows and coumns...





Column ordering in the grid view is specific to that particular grid view. You can have multiple views for any particular dataset (Data Tree to use the appropriate IJC terminology) and each grid view can have its columns reordered just by dragging the column headers to their new location.


Therefore the concept of "after this column" has ambiguous meaning at the model (database) level, and so cannot be implementeted in a sensible manner.





Row ordering is dependent on the ordering supplied by the database.


When adding a new row to a database table it will always be added at the "end" or the table, but relational databases do not provide any guaranteed ordering of rows, unless you specify a specific ORDER BY clause. There is no easy way to specify "insert row arter this row but before the next row".





So basically all this is because IJC is fudamentally a database application, and as such is dependent to a large extent on the way databases operate. Excel is not a database application, and so has different behaviour.


Some things we can't change. A bit like the 65K limit in Excel!





Tim

Hi Petr,


thanks for the detailed reply, I agree on most of the points,


but this a very important part, also why JAVA applications were not accepted during the first 10 years (since 1996 or so).


The funny thing was you could program almost every functionality into a JAVA application, but because they did not follow certain rules and standards they were not really successful.





Tobias