RE: [platform-swt-dev] Overrriding default behaviors

["Erik Poupaert" <erik.poupaert@xxxxxxxxx>]

You're right. Please grant me that I had exactly 2 days time to wrap this
up. It needs cleaning, refactoring, and especially, much user using,
testing, trouble ticket processing, bug fixing, and so on, if it wants to
live on as a useful component, that you can use almost out of the box. I'd
love to do that.

The part you're referring to (excessive copy & paste) was quickly added to
implement something I needed badly and quickly.

As soon as I get a good CVS server location, we can start processing
patches, cleaning up, and move all of this into a more project-like
environment. Now it's quick & dirty fix resulting from a one-man show to
create an example application that was the proof of concept that SWT works
properly on win32 (i.e. convincing managerial types). Now that everybody is
happy with the approach, we can start setting up things. The complaints they
had were actually functional, and not the SWT technology. I had to fix the
default sortorder in some of the grids, and you know, that kind of stuff,
you don't think of as a developer, but which are the basis on which users
judge your application.

In the meanwhile, there's other stuff that's urgent. I really would like to
have some more time in a day :)

The real solution is, of course, to get more people involved, for the parts
they want to get involved with. By the way SWT has a few small issues that,
without fixing, prevent a component-oriented approach. I'm talking about the
hard-coded event numbers in SWT.java (unscalable) and the way
TypedEventListener works (knows all the events, and all the listeners in a
hard-coded way). There are ways to clean this up; but for that the SWT
developers themselves must agree to clean this up.

Erik

-----Original Message-----
From: David Whiteman [mailto:dlwhiteman@xxxxxxxxxxxxxxx]
Sent: Thursday 20 February 2003 18:24
To: Erik Poupaert
Subject: Re: [platform-swt-dev] Overrriding default behaviors


Thursday, February 20, 2003, 11:47:33 AM, Erik Poupaert wrote:

>                                                 if(!cancelUpdateRow(mRow))
>                                                 {
>
if(!handleUpdateRow(mRow))
>                                                         {
>
deselect(pNewRow);
>
mEditor.getEditor().setFocus();
>                                                                 return;
>                                                         }
>                                                 }
>                                                 else
>                                                 {
>                                                         deselect(pNewRow);
>
mEditor.getEditor().setFocus();
>                                                         return;
>                                                 }

Couldn't this instead be written as:

                                                if(cancelUpdateRow(mRow) ||
!handleUpdateRow(mRow))
                                                {
                                                      deselect(pNewRow);

mEditor.getEditor().setFocus();
                                                       return;
                                                }

Also, for as many times as you call deselect() and getFocus()
together, you might want to use an extract method refactoring there.

David
--
Regards,
David
mailto:dlwhiteman@xxxxxxxxxxxxxxx