> This is probably not working because only one thread can be involved > with Wt objects at a time.
Ok, this makes perfect sense to me. > The easy part, it seems to me, is to avoid the reentrant event loop > when using WTestEnvironment. But then you still want control over the > return value of the exec() method. Indeed. > I see a number of options: > - extend the WDialog API with a method for testing only, to set the > result that is to be returned by exec(). Not very nice in case the > dialog box is buried deep down your integration test Ok, in my case I can grab a pointer to it. I'll do something like this, but I would like to walk the very same path the user would. > - provide virtual methods in WTestEnvironment which are invoked > whenever a recursive eventloop is started, with contextual information > (the dialog or other object involved), this method could then simulate > interaction with the dialog itself > - provide signals in WTestEnvironment, which allow the same as supra > without requiring to specialize WTestEnvironment > Signal<WDialog *>& dialogExecuted(), Signal<WPopupMenu *>& > popupMenuExecuted(), ... These approaches sound equally attractive, but out of my current wt-skills. I share your feeling about the second being nicer than the first one and it would likely be more viable if I get it right. Do you think you or other wt-developers will have the chance to implement it? It'd be great! Thanks! Antonio ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
