Boost logo

Boost Testing :

From: David Abrahams (dave_at_[hidden])
Date: 2007-02-04 21:42:39

Bronek Kozicki <brok_at_[hidden]> writes:

> David Abrahams wrote:
>> I'm really sorry, but I just don't have the time to do anything like
>> that right now. I am currently passing -lx120 to bjam and *not* using
>> the "monitored" test option. I cc'd you because I suspected you might
>> be the person who "wrote that part of the code," due to your expertise
>> in this area. Only crashed tests produce these dialogs. I'm doing
>> release mode testing. libs/iterator/test/filter_iterator_test is one
>> of two that produce the dialog for me. I hope that gives you some
>> information to go on.
> the code to close alerts is "only" few months old, so if you are using
> older build of boost

You mean bjam? It was built within the last few weeks; but I'll build
a new one.

> you need new build. Now, the code has serious
> limitation - it's unable to close windows displayed on desktop that is
> different from the one bjam is runnig on. One might thing "surely all
> asserts are displayed on the very same desktop as program that crashed"
> but this would be mistake. Assertions are (often - depending on
> compiler) dialog boxes displayed with option MB_SERVICE_NOTIFICATION or
> MB_DEFAULT_DESKTOP_ONLY, which (through API magic) would display dialog
> on interactive desktop. If bjam is not running on interactive desktop
> (eg. because of screen saver or fast user switching or terminal
> sessions),

I'm running my tests from a .bat script that gets run as a "Scheduled

> it won't be able to find and close assertion alert window -
> because these two are different desktops. This is because of Windows
> limitation - no one, not even administrator can reach windows on desktop
> other than own. Well, I think there is way around - SYSTEM user probably
> would be able to, but that requires rewriting whole functionality as a
> system service. Or running bjam as SYSTEM and putting a little extra
> code in there to iterate over desktops.

Well, I'm afraid we really need that "way around" if we're going to
have effective automated testing on Windows. Otherwise a crashed test
stalls the whole process; a new test run won't start until all those
dialogs are closed.

Dave Abrahams
Boost Consulting

Boost-testing list run by mbergal at