It is quite reasonable for Qt to break down when fatal error occure due
to an errorneous initializing of the whole system. It's like pressing
the gas pedal of a car without ever turning the key first. Since Qt has
quite complex initializing mechnisms which optimize the work during a
running program this behaviour increases debuggability and consistency.
It is no parameter of compiled programs that they should break down on
program errors, its just a reasonable parameter of Qt not to start in
wrong environments. It is left to you to check for a server BEFORE
creating a QApplication as a client.
I also don't know where you want to put your "-qws" argument inside your
application. Though this is possible this should in neither case be
acceptable style. The QApplication class provides a constructor for
this operation and you should use that:
if QwsIsStarted(): # QwsIsStarted() is an own function that tests
# for a server, see below.
app = QApplication( argc, argv, QApplication::GuiClient )
else
app = QApplication( argc, argv, QApplication::GuiServer )
As documented in the Qt Documentation:
-----------
QApplication::QApplication ( int & argc, char ** argv, Type type )
Constructs an application object with argc command line arguments in argv.
For Qt/Embedded, passing QApplication::GuiServer for type makes this application the
server (equivalent to running with the -qws option).
-----------
On the other hand if you want to use "-qws" as an option, why don't you
start a script that restarts your application with "-qws" if the
operation fails.
There are many solutions to the problem which all rely on your knowledge
of a server running. You should think about a test function that I
called QwsIsStarted() as an example here.
BYE INGO
On Fri, Nov 08, 2002 at 12:26:54PM +0100, Michael Lauer wrote:
> Hi,
>
> in Qt there are certain places, where exit() is called, for instance,
> if you construct a QPaintDevice before a QApplication, the process ends.
>
> This behaviour - while perhaps being reasonable in a compiled language -
> seems truly inappropriate in the context of an interpretated interactive
> and dynamic environment such as the Python interpreter.
>
> It would be much more useful if this would raise an exception, like,
> PyQtException, which we could catch and react appropriate - for
> instance, generating the application object and trying again.
>
> It's especially bugging me in Qt/Embedded, where the offending exit()
> call is triggered, when you create a QApplication in client mode but
> no QWS server is running. It would be sufficient to just recreate the
> QApplication with the appropriate parameter (-qws), but I can't because
> my interpreter is being shutdown [see below] :(
>
> ========================================================
>
> mickey@gandalf:~/work/elan$ python
> Python 2.2.2 (#1, Oct 27 2002, 17:30:06)
> [GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import qtpe
> >>> try:
> ... a=qtpe.QApplication([])
> ... except:
> ... pass
> ...
> QSocket::writeBlock: Socket is not open
> QSocket::writeBlock: Socket is not open
> QSocket::writeBlock: Socket is not open
> No Qt/Embedded server appears to be running.
> If you want to run this program as a server,
> add the "-qws" command-line option.
> mickey@gandalf:~/work/elan$
>
> ========================================================
>
> This behaviour is due to the following code:
>
> ========================================================
>
> void QWSDisplayData::waitForConnection()
> {
> #ifndef QT_NO_QWS_MULTIPROCESS
> for ( int i = 0; i < 5; i++ ) {
> if ( csocket ) {
> csocket->flush();
> csocket->waitForMore(2000);
> }
> fillQueue();
> if ( connected_event )
> return;
> usleep( 50000 );
> }
> #else
> if ( connected_event )
> return;
> #endif
> qWarning("No Qt/Embedded server appears to be running.");
> qWarning("If you want to run this program as a server,");
> qWarning("add the \"-qws\" command-line option.");
> exit(1);
> }
>
> ========================================================
>
> Now, my question... is there something I can do at python level
> or is there something we can do at PyQt level to change this behaviour?
>
> Yours,
>
> --
> :M:
> --------------------------------------------------------------------------
> Dipl.-Inf. Michael 'Mickey' Lauer
> [EMAIL PROTECTED]
> Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie
> --------------------------------------------------------------------------
>
> _______________________________________________
> PyKDE mailing list [EMAIL PROTECTED]
> http://mats.gmd.de/mailman/listinfo/pykde
>
_______________________________________________
PyKDE mailing list [EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
