I think it would be useful to offer a declarative developer option for this for sure

Why should i use a int. grid, when i not want edit it.

Two examples from my most recent projects:

1. A report with grouped columns.
2. A report based on an Oracle Text search with infinite scrolling and single row selection via a radio button.

Standard IG features that are not available in any other component, and in neither case was there ever any requirement or conception that the reports would be editable.

Non-editable is the fail safe mode and therefore should be the default.

when you think about, how often will others use this special feature? 80% or less then 5% ?

Hi @m.patzwahl ,

I realize this idea is over a year old, but we are catching up! Do you mind providing more information about your idea? We are unsure if it's about creating a new IG on Page Designer and enabling Edit”setting by default. Or end users using an IG and activating Edit mode at runtime?

Vincent didn't ask me, but I'd love to see this implemented as:

1. Developer sets declarative option to enable “Single-click Editing”
2. Without the user having to click the Edit button, when the user clicks on an editable field, the edit mode is enabled.
3. That is, they don't need to click twice to edit the field.

I think Stew has a pretty good idea there. A developer should be able to set how the grid functions, and the suggested ability to edit with a single click would be more natural than what users have to do today.

There are a few possibilities here and I'm interested in knowing what people think and what this idea is really getting at.

The original request sounded to me like the grid view should start out in edit mode. I assume the user could choose to leave edit mode.
Stew's comment is more clear that the idea is for an “always edit mode” meaning there is no edit button or need to double click and user can't get to the navigation mode. This is great for editing a few rows but has very bad accessibility in large reports.

In either case the developer default would be the current behavior for backward compatibility and also the reasons that fac586 gave.

Maybe both people are really saying the same thing. 

A different idea has suggested a different way of editing which is “spreadsheet mode” (editing would work much more like Excel). My question is if there were a spreadsheet mode option would that eliminate the need for this idea?

@john.snyders Could you please detail what you mean by:

“spreadsheet mode” (editing would work much more like Excel)

For example, do you mean they click in the cell to edit and it open a separate text box above the entire report/spreadsheet? That's the only interface I could imagine that would eliminate an issue with large reports.

That could work for my users, since it follows a familiar spreadsheet model. On the hand, I'm not sure that would improve the interface that much over the current interface, since they'd have to edit outside the row.

Spreadsheets do have an edit mode. I used to think, incorrectly, they were always in edit mode but it turns out they are almost never in edit mode they just allow basic data entry in navigation mode. Spreadsheet mode means that you can just start typing to enter a new value. If you use the arrow keys it navigates to a new cell. If you want to edit you can press F2 or double click just like in Microsoft Excel or Libre Office Calc but then as soon as you leave the cell you are back to navigation mode. I was not thinking about having a text box on top of the grid. Modern spreadsheets let you edit in place so that text box is not really needed for that although it does more for formula editing.

If that's what you meant by "spreadsheet mode", I'm all for it.

i am so sorry to waste your and my time for this enhancement request. it was just a idea to change the default of a yes/no field in the app and not a new mars mission …

@m.patzwahl NOT AT ALL a waste of time! All these types of discussions are valuable! Thank you!