Re: [Java-gnome-developer] Grabbing default in a subclass of Dialog

[Richard S. <ri...@r-...>]

On 12/08/10 17:08, Kenneth Prugh wrote:

> It would seem that the Entry is interfering in this test case, as if
> you remove the Entry hitting enter activates the default button.

You are quite right. I removed the Entry field and played around with it
a bit more but still didn't have much success with the
dialog.setDefaultButton() method:

Havign set Apply as the default button, the dialog shows initially with
the Apply button focussed and pressing return invokes the apply
processing. However, having pressed Close, the next time the dialog is
opened, the Close button has become the default. I tried moving the
setDefaultButton() call around - into the handler that shows the dialog
for example, so that setDefaultButton() is called every time the dialog
is shown, but still the same.

I ened up with the flow I wanted (for a goto line dialog in a text
editor), by not using setDefaultButton() or setCanDefault() at all. I
just added an Entry.Activate() handler on the Entry that emits clicked
on the default button when I press return:

// Add close and apply buttons
final Button defaultButton = new Button(Stock.APPLY);
dialog.addButton(Stock.CLOSE, ResponseType.CLOSE);
dialog.addButton(defaultButton, ResponseType.APPLY);

// Connect the handler that shows the dialog
showDialogButton.connect(new Button.Clicked() {
	public void onClicked(Button source) {
		entry.setText("");
		entry.grabFocus();
		dialog.showAll();
	}
});

// Connect a handler to the entry for the default button
entry.connect(new Entry.Activate() {
	@Override
	public void onActivate(Entry source) {
		defaultButton.emitClicked();
	}
});

It's not ideal because, as a user, you get no feedback about which is
the default button. I notice that gedit neatly sidesteps the issue by
using a different type of control for goto line. ;)

-- 
Regards,

Richard Senior
IRC #java-gnome: san-ho-zay