[Development] A new approach for Qt main()

[Mark De Wit]

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:development-bounces+mark.dewit=iesve.com at qt-project.org] On Behalf Of Thiago Macieira
Sent: 10 December 2016 00:43
To: development at qt-project.org
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
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development