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
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 www.boost-consulting.com