| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 6 | |
Hi,
First of all, I am completely new to Qt. I have looked through the documentation
these last few of days and read some Qt code from a library I am using, but
that's where my experience ends. now to my question/problem:
I am using a third party library which in turn uses Qt. The particular section I
am working on now just uses QObject and QTcpSocket. It suppose to connect to an
IP camera and get a stream, decode it, etc. I am stuck at getting the stream
from the camera. For reference, the library is Mobotix's sdk for their cameras
http://developer.mobotix.com/mobotix_sdk_1.0.1/index.html#cpp_lib
The class where I have the problem, mx::HTTPGetStreamSource, is supposed to
connect to the camera (which has a web server integrated) and get a stream. It
uses
QTcpSocket::connectToHost( const QString &, quint16, OpenMode ) to connect to
the host, and it sets up a few slots:
mx::HTTPGetStreamSource::HTTPGetStreamSource() {
AsyncSocket = new QTcpSocket();
QObject::connect(AsyncSocket, SIGNAL(connected()),
this, SLOT(processIncomingBytes()));
QObject::connect(AsyncSocket, SIGNAL(readyRead()),
this, SLOT(processIncomingBytes()));
QObject::connect(AsyncSocket, SIGNAL(disconnected()),
this, SLOT(processSocketDisconnected()));
}
Now, the function processIncomingBytes is where the interesting stuff is
supposed to happen, i.e. HTTP negotiation, requesting the web page, etc. This
unction is actually implemented in a base class, but I don't think that is
mportant. The thing is that the slot connected to the connected() signal is
never called. For debugging I re-implemented processIncomingBytes() with some
debug printouts to stdout in HTTPGetStreamSource, but it is never called. The
camera is reachable, I verified that the web page requested is correct, but I
believe the problem happens before that.
Last, the class also provides for a means of connecting to the camera
synchronously using waitForReadyRead() function, and this happens to work
correctly.
Am I missing something obvious? I'd appreciate some help in the form of advice,
pointers, etc.
jorges
______________________________________________
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
--
[ signature omitted ]
Just a quick thought before anything else, have you checked that the machine
you are using to develop the programme is not firewalled? I know you say it
is reachable but it is worth checking that a firewall isn't getting in the
way. Assuming it is safe to do so, I'd try turning it off and see if this
affects the behaviour.
I don't think it will make a difference, but try putting 'this' in your new
socket line as follows - it should really be there:
AsyncSocket = new QTcpSocket( this );
I'm not clear from your description that the above line is actually executed.
Have you put debug in here to check that the socket and connections are
actually made?
Hope this helps,
Nick
On Monday 26 May 2008 02:41:11 jorgesmbox-ml@xxxxxxxx wrote:
> Hi,
> First of all, I am completely new to Qt. I have looked through the
> documentation these last few of days and read some Qt code from a library I
> am using, but that's where my experience ends. now to my question/problem:
> I am using a third party library which in turn uses Qt. The particular
> section I am working on now just uses QObject and QTcpSocket. It suppose to
> connect to an IP camera and get a stream, decode it, etc. I am stuck at
> getting the stream from the camera. For reference, the library is Mobotix's
> sdk for their cameras
> http://developer.mobotix.com/mobotix_sdk_1.0.1/index.html#cpp_lib
> The class where I have the problem, mx::HTTPGetStreamSource, is supposed to
> connect to the camera (which has a web server integrated) and get a stream.
> It uses
> QTcpSocket::connectToHost( const QString &, quint16, OpenMode ) to connect
> to the host, and it sets up a few slots:
>
> mx::HTTPGetStreamSource::HTTPGetStreamSource() {
>
> AsyncSocket = new QTcpSocket();
>
> QObject::connect(AsyncSocket, SIGNAL(connected()),
> this, SLOT(processIncomingBytes()));
> QObject::connect(AsyncSocket, SIGNAL(readyRead()),
> this, SLOT(processIncomingBytes()));
> QObject::connect(AsyncSocket, SIGNAL(disconnected()),
> this, SLOT(processSocketDisconnected()));
> }
>
> Now, the function processIncomingBytes is where the interesting stuff is
> supposed to happen, i.e. HTTP negotiation, requesting the web page, etc.
> This unction is actually implemented in a base class, but I don't think
> that is mportant. The thing is that the slot connected to the connected()
> signal is never called. For debugging I re-implemented
> processIncomingBytes() with some debug printouts to stdout in
> HTTPGetStreamSource, but it is never called. The camera is reachable, I
> verified that the web page requested is correct, but I believe the problem
> happens before that.
>
> Last, the class also provides for a means of connecting to the camera
> synchronously using waitForReadyRead() function, and this happens to work
> correctly.
>
> Am I missing something obvious? I'd appreciate some help in the form of
> advice, pointers, etc.
>
> jorges
>
>
> ______________________________________________
> Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
----- Mensaje original ----
> De: Nicholas Robinson <npr@xxxxxxxxxxxxxxxx>
> Para: qt-interest@xxxxxxxxxxxxx
> Enviado: lunes, 26 de mayo, 2008 5:09:03
> Asunto: Re: Help w/ signals-slots and QTcpSocket
>
> Just a quick thought before anything else, have you checked that the machine
> you are using to develop the programme is not firewalled? I know you say it
> is reachable but it is worth checking that a firewall isn't getting in the
> way. Assuming it is safe to do so, I'd try turning it off and see if this
> affects the behaviour.
>
> I don't think it will make a difference, but try putting 'this' in your new
> socket line as follows - it should really be there:
>
> AsyncSocket = new QTcpSocket( this );
>
> I'm not clear from your description that the above line is actually executed.
> Have you put debug in here to check that the socket and connections are
> actually made?
>
> Hope this helps,
>
> Nick
>
I have a guess that maybe the problem I have is due to the signals/slots mechanism not being setup correctly. All signals/slots stuff happen at the library, where the project is correctly set up to generate and include moc files. The main application, however, consists only on instantiating some objects, setting the input source, the decoder, etc. and then looping forever to process the stream. Maybe because this a console application, there's something else to be done for signals and slots work. I have no instance of QCoreApplication or anything like that in main(). The loop I mentioned before just ask the source if there are bytes to process, which indirectly calls QTcpSocket::read( char *, qint64 ) : qint64
I'll investigate down this line, but I find information about Qt non-gui programming scarce.
jorges
> On Monday 26 May 2008 02:41:11 jorgesmbox-ml@xxxxxxxx wrote:
> > Hi,
> > First of all, I am completely new to Qt. I have looked through the
> > documentation these last few of days and read some Qt code from a library I
> > am using, but that's where my experience ends. now to my question/problem:
> > I am using a third party library which in turn uses Qt. The particular
> > section I am working on now just uses QObject and QTcpSocket. It suppose to
> > connect to an IP camera and get a stream, decode it, etc. I am stuck at
> > getting the stream from the camera. For reference, the library is Mobotix's
> > sdk for their cameras
> > http://developer.mobotix.com/mobotix_sdk_1.0.1/index.html#cpp_lib
> > The class where I have the problem, mx::HTTPGetStreamSource, is supposed to
> > connect to the camera (which has a web server integrated) and get a stream.
> > It uses
> > QTcpSocket::connectToHost( const QString &, quint16, OpenMode ) to connect
> > to the host, and it sets up a few slots:
> >
> > mx::HTTPGetStreamSource::HTTPGetStreamSource() {
> >
> > AsyncSocket = new QTcpSocket();
> >
> > QObject::connect(AsyncSocket, SIGNAL(connected()),
> > this, SLOT(processIncomingBytes()));
> > QObject::connect(AsyncSocket, SIGNAL(readyRead()),
> > this, SLOT(processIncomingBytes()));
> > QObject::connect(AsyncSocket, SIGNAL(disconnected()),
> > this, SLOT(processSocketDisconnected()));
> > }
> >
> > Now, the function processIncomingBytes is where the interesting stuff is
> > supposed to happen, i.e. HTTP negotiation, requesting the web page, etc.
> > This unction is actually implemented in a base class, but I don't think
> > that is mportant. The thing is that the slot connected to the connected()
> > signal is never called. For debugging I re-implemented
> > processIncomingBytes() with some debug printouts to stdout in
> > HTTPGetStreamSource, but it is never called. The camera is reachable, I
> > verified that the web page requested is correct, but I believe the problem
> > happens before that.
> >
> > Last, the class also provides for a means of connecting to the camera
> > synchronously using waitForReadyRead() function, and this happens to work
> > correctly.
> >
> > Am I missing something obvious? I'd appreciate some help in the form of
> > advice, pointers, etc.
> >
> > jorges
> >
> >
> > ______________________________________________
> > Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> > "unsubscribe" in the subject or the body. List archive and information:
> > http://lists.trolltech.com/qt-interest/
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
______________________________________________
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
--
[ signature omitted ]
Am Montag, 26. Mai 2008 schrieb jorgesmbox-ml@xxxxxxxx: > I have a guess that maybe the problem I have is due to the signals/slots > mechanism not being setup correctly. All signals/slots stuff happen at the > library, where the project is correctly set up to generate and include moc > files. The main application, however, consists only on instantiating some > objects, setting the input source, the decoder, etc. and then looping > forever to process the stream. Maybe because this a console application, > there's something else to be done for signals and slots work. I have no > instance of QCoreApplication or anything like that in main(). The signal/slot-mechanism _needs_ a running event-loop! The easiest is to use QCoreApplication and make the whole app event-driven (even the looping on the stream). The second solution should be to call QCoreApplication::processEvents() regularly from your own loop. Have fun, Arnold -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Monday 26 May 2008 11:38:56 Arnold Krille wrote: > Am Montag, 26. Mai 2008 schrieb jorgesmbox-ml@xxxxxxxx: > > I have a guess that maybe the problem I have is due to the signals/slots > > mechanism not being setup correctly. All signals/slots stuff happen at > > the library, where the project is correctly set up to generate and > > include moc files. The main application, however, consists only on > > instantiating some objects, setting the input source, the decoder, etc. > > and then looping forever to process the stream. Maybe because this a > > console application, there's something else to be done for signals and > > slots work. I have no instance of QCoreApplication or anything like that > > in main(). > > The signal/slot-mechanism _needs_ a running event-loop! The easiest is to > use QCoreApplication and make the whole app event-driven (even the looping > on the stream). The second solution should be to call > QCoreApplication::processEvents() regularly from your own loop. Not exactly. The signal/slot mechanism, when in a direct connection, doesn't require an event loop. It only requires the event loop in a queued connection, and those only appear if you're using threads or if you explicitly chose QueuedConnection when connecting. However, QTcpSocket only operates on the socket during the event loop run, or if one of the waitFor* functions are called. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Am Montag, 26. Mai 2008 schrieb Thiago Macieira: > On Monday 26 May 2008 11:38:56 Arnold Krille wrote: > > Am Montag, 26. Mai 2008 schrieb jorgesmbox-ml@xxxxxxxx: > > > I have a guess that maybe the problem I have is due to the > > > signals/slots mechanism not being setup correctly. All signals/slots > > > stuff happen at the library, where the project is correctly set up to > > > generate and include moc files. The main application, however, consists > > > only on instantiating some objects, setting the input source, the > > > decoder, etc. and then looping forever to process the stream. Maybe > > > because this a console application, there's something else to be done > > > for signals and slots work. I have no instance of QCoreApplication or > > > anything like that in main(). > > The signal/slot-mechanism _needs_ a running event-loop! The easiest is to > > use QCoreApplication and make the whole app event-driven (even the > > looping on the stream). The second solution should be to call > > QCoreApplication::processEvents() regularly from your own loop. > Not exactly. > The signal/slot mechanism, when in a direct connection, doesn't require an > event loop. It only requires the event loop in a queued connection, and > those only appear if you're using threads or if you explicitly chose > QueuedConnection when connecting. Yeah, I realized that the moment I hit send. But then I got distracted by my work and boss. But I also thought that the tcp-stuff probably does some async-stuff, maybe even in another thread. And there the queued connections (through signals or not) are introduced... > However, QTcpSocket only operates on the socket during the event loop run, > or if one of the waitFor* functions are called. Have fun, Arnold -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
> De: Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx>
> Para: qt-interest@xxxxxxxxxxxxx
> Enviado: lunes, 26 de mayo, 2008 12:41:28
> Asunto: Re: Help w/ signals-slots and QTcpSocket
>
> On Monday 26 May 2008 11:38:56 Arnold Krille wrote:
> > Am Montag, 26. Mai 2008 schrieb jorgesmbox-ml@xxxxxxxx:
> > > I have a guess that maybe the problem I have is due to the signals/slots
> > > mechanism not being setup correctly. All signals/slots stuff happen at
> > > the library, where the project is correctly set up to generate and
> > > include moc files. The main application, however, consists only on
> > > instantiating some objects, setting the input source, the decoder, etc.
> > > and then looping forever to process the stream. Maybe because this a
> > > console application, there's something else to be done for signals and
> > > slots work. I have no instance of QCoreApplication or anything like that
> > > in main().
> >
> > The signal/slot-mechanism _needs_ a running event-loop! The easiest is to
> > use QCoreApplication and make the whole app event-driven (even the looping
> > on the stream). The second solution should be to call
> > QCoreApplication::processEvents() regularly from your own loop.
>
> Not exactly.
>
> The signal/slot mechanism, when in a direct connection, doesn't require an
> event loop. It only requires the event loop in a queued connection, and those
> only appear if you're using threads or if you explicitly chose
> QueuedConnection when connecting.
>
> However, QTcpSocket only operates on the socket during the event loop run, or
> if one of the waitFor* functions are called.
>
You are rigth, I just did a quick test and now the app works. I just created a QCoreApplication object and call processEvents() in the main loop like Arnold Krille suggested before your post.
Now that Ihave been bitten by this, I looked through the docs to find more info, but I didn't find much on the event loop, and less about the specific situations where the signal/slot might not need an event loop. Would you care to point me to sources to read more about this?
Thank you all for your help,
jorges
> --
> Thiago José Macieira - thiago.macieira AT trolltech.com
> Trolltech ASA - Sandakerveien 116, NO-0402 Oslo, Norway
______________________________________________
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
--
[ signature omitted ]