wxgrid

I didn't want this to get lost. So I repeat in new thread

When you click on a column (or a row) label of a grid, the entire column 
(or row) "appears" to be "selected".

What is handling that change in appearance?

I say "appear to be selected" because the row or column really isn't 
because copy, cut and paste don't seem to be implemented within a grid. 
  But they do appear to work with an edit box.  What's up with that?

In moving through a grid.  Arrow keys only work so long as you are NOT 
adding or editing a cell.  So if you are adding or editing a cell you 
currently need to use Tab, ShiftTab (back tab) for right and left and 
ENTER for down. Shouldn't the arrow keys work even when editing or 
adding to a cell?

Kromkowski wrote:
> I didn't want this to get lost. So I repeat in new thread
> 
> When you click on a column (or a row) label of a grid, the entire column
> (or row) "appears" to be "selected".
> 
> What is handling that change in appearance?

This internal to the wxGrid object implementation. An event is actually
generated, we just are not yet passing it on. It is merely a matter of
deciding that it has priority.

> I say "appear to be selected" because the row or column really
isn't
> because copy, cut and paste don't seem to be implemented within a grid.
>  But they do appear to work with an edit box.  What's up with that?

There is no concept of Cut, Copy, and Paste for a grid. It could
certainly be implemented. As for the version that you find working in
edit controls, that is because they are native edit controls and have
these capabilities by default in Windows.

> In moving through a grid.  Arrow keys only work so long as you are NOT
> adding or editing a cell.  So if you are adding or editing a cell you
> currently need to use Tab, ShiftTab (back tab) for right and left and
> ENTER for down. Shouldn't the arrow keys work even when editing or
> adding to a cell?

The arrow keys work while editing a cell, but they move you within the
cell content. That makes sense if you think about it.

Ciao, Neil

Neil Robinson wrote:
> Kromkowski wrote:
>> I didn't want this to get lost. So I repeat in new thread
>>
>> When you click on a column (or a row) label of a grid, the entire
column
>> (or row) "appears" to be "selected".
>>
>> What is handling that change in appearance?
> 
> This internal to the wxGrid object implementation. An event is actually
> generated, we just are not yet passing it on. It is merely a matter of
> deciding that it has priority.

OK, as I suspected. But wouldn't that be the place to implement that one
could implement a Sort as Dan wants. It would also be a place to 
implement a move of a an entire row or column (drag and drop kind of 
thing), which I could see would be useful for some applications.

Although, with respect to SORTS in a spreadsheet program you'd normally 
handle this via a menu item, while in a web page display of data you'd 
"normally" implement the sort via a "click on label" like he
wants to do.

>> I say "appear to be selected" because the row or column
really isn't
>> because copy, cut and paste don't seem to be implemented within a
grid.
>>  But they do appear to work with an edit box.  What's up with that?
> 
> There is no concept of Cut, Copy, and Paste for a grid. It could
> certainly be implemented. As for the version that you find working in
> edit controls, that is because they are native edit controls and have
> these capabilities by default in Windows.

I'm not sure I quit understand.  It seems to me than any place where
one can type information should have the Cut, Copy, & Paste 
capabilities. That seems like standard operating procedure nearly two 
decades into GUI.

>> In moving through a grid.  Arrow keys only work so long as you are NOT
>> adding or editing a cell.  So if you are adding or editing a cell you
>> currently need to use Tab, ShiftTab (back tab) for right and left and
>> ENTER for down. Shouldn't the arrow keys work even when editing or
>> adding to a cell?
> The arrow keys work while editing a cell, but they move you within the
> cell content. That makes sense if you think about it.

Well, I understand what you are saying. But take a look at how most 
spreadsheets programs like Excel and Quattro Pro work.  The arrow keys 
works to move from cell to cell, even if you are editing.  That is 
probably why they have the edit box above the grid (in which the left 
and right arrow key work "within" the text).

But even in Superbase in a table view which seems to be the functional 
equivalent, the up and down arrow keys work differently than left and 
right arrow keys when editing.

JDK

>> Neil Robinson wrote:
>>> This internal to the wxGrid object implementation. An event is
>>> actually generated, we just are not yet passing it on. It is
>>> merely a matter of deciding that it has priority.
>> OK, as I suspected. But wouldn't that be the place to implement
>> that one could implement a Sort as Dan wants. It would also be a
>> place to implement a move of a an entire row or column (drag and
>> drop kind of thing), which I could see would be useful for some
>> applications.
> 
> Possibly, but that is making assumptions about what the user is using
>  the grid for. Better is just to pass on the event and leave it to
> the programmer to decide how to interpret it.

That is what I meant,i.e. that these internal event (onlableclick and
onrowclick or whatever they are) should be exposed so that one might be
able to implement, for example, a SORT or column or row "move" or
whatever.


> This is a grid control, not a spreadsheet. A proper spreadsheet
> control would have much more functionality than this.

The distinction is pretty small.  Its the basis for a poor man's 
spreadsheet if you ask me.  Most of the extra functionality of
a spreadsheet control lies in menu functions built on top of the grid in 
my opinion.


>>> There is no concept of Cut, Copy, and Paste for a grid. It could 
>>> certainly be implemented. As for the version that you find
>>> working in edit controls, that is because they are native edit
>>> controls and have these capabilities by default in Windows.
>> I'm not sure I quit understand.  It seems to me than any place
>> where one can type information should have the Cut, Copy, & Paste 
>> capabilities. That seems like standard operating procedure nearly
>> two decades into GUI.
> 
> You are right for the edit control, but why do you think the whole
> grid should respond to a cut, copy or paste automatically? What would
> be the behavior that you are expecting?

I think that any thing that one can "select" should respond to cut
copy 
and paste.  If I select a cell, I should be able to right mouse (Cut, 
Copy, Paste [and I prefer also Append])  If I select a group of cells, I 
should be able to cut copy and/or paste.


>>> The arrow keys work while editing a cell, but they move you
>>> within the cell content. That makes sense if you think about it.
>> Well, I understand what you are saying. But take a look at how most
>>  spreadsheets programs like Excel and Quattro Pro work.  The arrow
>> keys works to move from cell to cell, even if you are editing.
>> That is probably why they have the edit box above the grid (in
>> which the left and right arrow key work "within" the text).
>> 
>> But even in Superbase in a table view which seems to be the
>> functional equivalent, the up and down arrow keys work differently
>> than left and right arrow keys when editing.
> 
> We are not overly impressed with the implementation of the grid
> control in wxWidgets, but it is currently outside our time
> constraints to make significant changes to it. We will eventually do
> so, but there are many other things that have priority, and that one
> will have to wait until version 2 I think, though some things may get
> done earlier.

Yeah, well in other words the grid is a bit crude.  I guess, quite 
frankly, I had only really expected you to use it as the mechanism for 
table view or perhaps for a possible interim template for detail block 
implementation.   How detail blocks are going to work, I put way ahead 
of building a better grid control.

Kromkowski wrote:
> Neil Robinson wrote:
>> This internal to the wxGrid object implementation. An event is
actually
>> generated, we just are not yet passing it on. It is merely a matter of
>> deciding that it has priority.
> 
> OK, as I suspected. But wouldn't that be the place to implement that one
> could implement a Sort as Dan wants. It would also be a place to
> implement a move of a an entire row or column (drag and drop kind of
> thing), which I could see would be useful for some applications.

Possibly, but that is making assumptions about what the user is using
the grid for. Better is just to pass on the event and leave it to the
programmer to decide how to interpret it.

> Although, with respect to SORTS in a spreadsheet program you'd normally
> handle this via a menu item, while in a web page display of data you'd
> "normally" implement the sort via a "click on label"
like he wants to do.
> 

This is a grid control, not a spreadsheet. A proper spreadsheet control
would have much more functionality than this.

>> There is no concept of Cut, Copy, and Paste for a grid. It could
>> certainly be implemented. As for the version that you find working in
>> edit controls, that is because they are native edit controls and have
>> these capabilities by default in Windows.
> 
> I'm not sure I quit understand.  It seems to me than any place where
> one can type information should have the Cut, Copy, & Paste
> capabilities. That seems like standard operating procedure nearly two
> decades into GUI.

You are right for the edit control, but why do you think the whole grid
should respond to a cut, copy or paste automatically? What would be the
behavior that you are expecting?

>> The arrow keys work while editing a cell, but they move you within the
>> cell content. That makes sense if you think about it.
> 
> Well, I understand what you are saying. But take a look at how most
> spreadsheets programs like Excel and Quattro Pro work.  The arrow keys
> works to move from cell to cell, even if you are editing.  That is
> probably why they have the edit box above the grid (in which the left
> and right arrow key work "within" the text).
> 
> But even in Superbase in a table view which seems to be the functional
> equivalent, the up and down arrow keys work differently than left and
> right arrow keys when editing.

We are not overly impressed with the implementation of the grid control
in wxWidgets, but it is currently outside our time constraints to make
significant changes to it. We will eventually do so, but there are many
other things that have priority, and that one will have to wait until
version 2 I think, though some things may get done earlier.