Angus Leeming <[EMAIL PROTECTED]> writes:
| On Tuesday 03 December 2002 4:43 pm, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>> | This patch to the xforms source seems to cure the problem, acting on
>> | every 10th such mouse event. It's really meant as a diagnostic tool.
>> | Presumably the real fix is to use a client-side specified timer to
>> | discard multiple mouse events that occur too closely together.
>> |
>> | Incidentally, Lars, this is probably a better appoach than your usleep
>> | solution to the selection bug. The code should be fixed in XWorkArea.C's
>> | work_area_handler routine not in screen.C.
>>
>> But we only want the delay (in some cases) if we have a selection
>> going, do we have that info close at hand in the WorkArea?
>
| I don't think we need it.
>
| The toolkit (and that includes XWorkArea here because that's really just a
| ScrollView widget) can distinguish between a mouse press (FL_PUSH) and
| subsequent mouse events (FL_MOUSE).
>
| In the case of the xforms slider widget we have
>
| static int timdel = 0;
| static int max_timdel = 11;
>
| int handle_it(FL_OBJECT * ob, int event, ...) {
| switch (event) {
| case FL_PUSH:
| timdel = 0;
| break;
| case FL_MOUSE:
| if (timdel++ == 0)
| handle_mouse_event();
| else if (timdel > max_timdel)
| timdel = 0;
| break;
| }
| }
>
| (This is trivially easy to modify to use a proper timer.)
>
| Isn't this exactly the behaviour we want XWorkArea to have?
Possibly... I'll just try to move my usleep to the FL_MOUSE case and
see what happens.
--
Lgb
