I have an application based on qt-solutions qtwinmigrate sample. Because we're integrating Qt into an existing MFC application, we're not even running QApplication exec. The application uses MFC's entry point for startup and drives the Qt event loop manually as part of the MFC event loop.
Mark -----Original Message----- From: Development [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: 10 December 2016 00:43 To: [email protected] Subject: Re: [Development] A new approach for Qt main() Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke escreveu: > On 2016-12-09 16:23, Thiago Macieira wrote: > > Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke > > > > escreveu: > >> I can work around that, though it's obnoxious. I'm more concerned about > >> not being able to tinker with the CLI arguments before Qt gets them. > > > > That's a valid concern, but not one that warrants a QApplication subclass. > > Right; that one is an issue if the user is no longer in control of > instantiating the Q*Application instance. Ah, that's a good point. Though quite frankly I don't see that as an issue. Applications can only have access to argc and argv if they write the main() function, which means they can continue to use the current functionality. I'm imaginiing that this new way is needed for platforms where a main() function makes no sense, in which case there's no command-line to begin with. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
