microsoft.public.access.forms

How about the LostFocus event? I'm not aware of list box controls
automatically requerying or repainting when losing focus, which it sounds
like is what is happening. Something else must be causing it.

Carl Rapson

"ThomasAJ" wrote in message
news:F31A20AA-7C94-4E50-BED9-DB3B955D4977@microsoft.com...
> Not EXIT
>
> Click and dble-click yes.
>
> But these are not executed when the 'white area' is clicked on. See below
> for white area definition.
> --
> Regards
> Tom
>
>
> "Carl Rapson" wrote:
>
>> "ThomasAJ" wrote in message
>> news:D5E60414-9D16-4262-8D46-1D41D17CC72F@microsoft.com...
>> > This list box has over 30 columns and a complicated source.
>> >
>> > Whenever another control on the form is focused on AFTER the list box
>> > has
>> > been 'touched', it seems to be requeried or at least repainted. This
>> > takes
>> > up
>> > a lot of CPU due to its complexity. You can actually see the list box
>> > being
>> > filled top to bottom and left to right, row by row.
>> >
>> > By 'touched' I do not mean even a row being selected but just the
>> > 'white'
>> > area being clicked on. The 'white' area is that area of the list box
>> > that
>> > does not have rows.
>> >
>> > --
>> > Regards
>> > Tom
>>
>> Are you handling any of the list box's events, particularly Click or
>> Exit?
>> If so, what code is in the events?
>>
>> Carl Rapson
>>
>>
>>