From: Banana on
Dirk Goldgar wrote:
> I didn't know that. <sigh> And I'd finally started to feel like I
> understood the API.

I actually only found out few days ago when experimenting with
manipulating Access windows via API.

It's quite frustrating because 1) it seems the API's documentation are
more or less haphazard so I worry that it may not be the right API to
use or is not appropriate for the purpose I'm thinking of, and 2) Visual
Basic doesn't really make it easy to work with API which may use C/C++
data types & structures so there's always uncertainty that we've used
the right data types.
From: Marshall Barton on
Banana wrote:

>Marshall Barton wrote:
>> Don't forget about Timer events doing the same kinds of
>> things.
>
>Well, I could be wrong but a while ago, I did look at using Timer events
>to run some code asynchronous and after some experimentation came to the
>conclusion that Timer event does not run in a separate thread from the
>rest of code so we would probably have a race condition but not
>conflicts due to two pieces of code executing concurrently.
>
>If we only have to worry about race condition, it shouldn't be material
>as the code being discussed should enable mouse clicking/screen
>updating/whatever before it finish and switch to the other procedure
>waiting to be executed.


Race conditions aside, I'm more concerned about a future
developer forgetting about the delicate situation and using
SetFocus, SelectObject, etc. in a timer event.

I think(?) Windows task switching has a (relatively small?)
chance of messing things over too.

--
Marsh
MVP [MS Access]