When editing an FXTable item, if you press Escape, your changes are
cancelled. However, when an item is selected but not being edited, the
table still traps the Escape keypress. As a result, in the following
code, if you open the dialog and then press Escape, it closes. But if
you open the dialog, select an item in the table, and then press Escape,
nothing happens. Is this behavior - trapping Escape when no item is
being edited - desirable? I would expect the dialog to close in both
cases.
Tim Smith
require ''fox16''; include Fox
app = FXApp.new
main = FXMainWindow.new app, ''Test'', :height => 100, :width
=> 100
button = FXButton.new main, ''open dialog'',
:opts => BUTTON_NORMAL | LAYOUT_CENTER_X | LAYOUT_CENTER_Y
button.connect(SEL_COMMAND) {
dialog = FXDialogBox.new main, ''Dialog''
table = FXTable.new dialog
table.setTableSize 2, 2
table.visibleRows = 2
table.visibleColumns = 2
table.setItemText 0, 0, ''one''
table.setItemText 0, 1, ''two''
table.setItemText 1, 0, ''three''
table.setItemText 1, 1, ''four''
dialog.execute
}
app.create
main.show PLACEMENT_SCREEN
app.run
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/fxruby-users/attachments/20080304/5cce9740/attachment.html
On Mar 4, 2008, at 2:17 PM, Tim Smith wrote:> When editing an FXTable item, if you press Escape, your changes are > cancelled. However, when an item is selected but not being edited, > the table still traps the Escape keypress. As a result, in the > following code, if you open the dialog and then press Escape, it > closes. But if you open the dialog, select an item in the table, > and then press Escape, nothing happens. Is this behavior ? trapping > Escape when no item is being edited ? desirable? I would expect the > dialog to close in both cases.Jeroen will need to make the decision about whether this is the appropriate default behavior for FXTable (i.e. it''s a FOX thing, not an FXRuby thing). If you had some way to know for sure that the user is not currently editing a cell, you could just intercept the SEL_KEYPRESS message and handle it yourself, e.g. table.connect(SEL_KEYPRESS) do |sender, sel, event| if event.code == KEY_Escape && (we''re not editing a cell) true else false end end The problem I''m running into is that the information that you need to make that determination (namely, whether or not an editor window has been constructed) isn''t currently exposed to FXRuby. I will make a note to fix that in the next release. Hope this helps, Lyle --- "FXRuby: Create Lean and Mean GUIs with Ruby" Now available as a Beta book from the Pragmatic Bookshelf http://www.pragprog.com/titles/fxruby -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/fxruby-users/attachments/20080304/04e42c07/attachment-0001.html
Thanks Lyle!
Tim
________________________________
From: fxruby-users-bounces at rubyforge.org
[mailto:fxruby-users-bounces at rubyforge.org] On Behalf Of Lyle Johnson
Sent: Tuesday, March 04, 2008 4:34 PM
To: fxruby-users at rubyforge.org
Subject: Re: [fxruby-users] FXTable and Escape key
On Mar 4, 2008, at 2:17 PM, Tim Smith wrote:
When editing an FXTable item, if you press Escape, your changes are
cancelled. However, when an item is selected but not being edited, the
table still traps the Escape keypress. As a result, in the following
code, if you open the dialog and then press Escape, it closes. But if
you open the dialog, select an item in the table, and then press Escape,
nothing happens. Is this behavior - trapping Escape when no item is
being edited - desirable? I would expect the dialog to close in both
cases.
Jeroen will need to make the decision about whether this is the
appropriate default behavior for FXTable (i.e. it''s a FOX thing, not an
FXRuby thing).
If you had some way to know for sure that the user is not currently
editing a cell, you could just intercept the SEL_KEYPRESS message and
handle it yourself, e.g.
table.connect(SEL_KEYPRESS) do |sender, sel, event|
if event.code == KEY_Escape && (we''re
not
editing a cell)
true
else
false
end
end
The problem I''m running into is that the information that you need to
make that determination (namely, whether or not an editor window has
been constructed) isn''t currently exposed to FXRuby. I will make a note
to fix that in the next release.
Hope this helps,
Lyle
---
"FXRuby: Create Lean and Mean GUIs with Ruby"
Now available as a Beta book from the Pragmatic Bookshelf
http://www.pragprog.com/titles/fxruby
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/fxruby-users/attachments/20080304/bc5f75af/attachment.html
On Tuesday 04 March 2008, Lyle Johnson wrote:> > On Mar 4, 2008, at 2:17 PM, Tim Smith wrote: > > > When editing an FXTable item, if you press Escape, your changes are > > cancelled. However, when an item is selected but not being edited, > > the table still traps the Escape keypress. As a result, in the > > following code, if you open the dialog and then press Escape, it > > closes. But if you open the dialog, select an item in the table, > > and then press Escape, nothing happens. Is this behavior ? trapping > > Escape when no item is being edited ? desirable? I would expect the > > dialog to close in both cases. > > Jeroen will need to make the decision about whether this is the > appropriate default behavior for FXTable (i.e. it''s a FOX thing, not > an FXRuby thing).Indeed, if FXTable does this, I think its wrong; we should probably ignore ESC when a cell is not being edited... I will take a look. - Jeroen