[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Automated GUI testing

From: Greg Chicares
Subject: Re: [lmi] Automated GUI testing
Date: Sat, 19 Nov 2005 16:41:06 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2005-11-17 23:57 UTC, Vadim Zeitlin wrote:
> On Thu, 17 Nov 2005 04:58:43 +0000 Greg Chicares <address@hidden> wrote:
> GC>     // Call the EVT_UPDATE_UI handler explicitly and retest.
> GC>     mvc.OnUpdateGUI(update);
> GC> 
> GC> This does work, at least as far as I can determine. But it doesn't
> GC> seem ideal.
>  No, it would be better to send a wxIdleEvent. This wold automatically
> generate wxUpdateUIEvent as well and might do other (possibly critical)
> things too. Many things, especially but not only in custom controls, risk
> to break if idle events are not sent.
> GC> I'm thinking of having OnUpdateGUI() raise a semaphore on entry, and
> GC> clear it only when it knows that it has found a fixed point. But
> GC> please let me know if you see a better way.
>  A brute force solution would be to send a dozen of idle events, this
> should definitely be enough... A more intelligent one would be to modify wx
> itself to iterate in update UI event sending code until there are no more
> changes. I'm actually surprized we don't already do it like this...
> GC> I will soon add tests that require generating some events, so a
> GC> general YieldToWxIdleProcessing() function will be needed in lmi.
>  It should be (but this is untested) enough to just call
> wxTheApp->wxPostEvent(idleEvent).

I tried that in code committed a moment ago (20051119T1631Z):
I still have to call the EVT_UPDATE_UI handler explicitly: idle processing
doesn't take care of that, even if I send 1000 idle events.

Is that because this unit test runs the dialog nonmodally?

If so, then I worry about this concern that you pointed out:

> Many things, especially but not only in custom controls, risk
> to break if idle events are not sent.

and that leads me to wonder whether running it nonmodally for testing
is a fundamentally unworkable idea.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]