Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-interest Archive, November 2006
HTTP-get in one function.


Message 1 in thread

Hello,

I want to write a plugin for a 3rd party application. My plugin will be
invoked when the user presses a button and then there a website should be
catched and parsed. But getting a website and parsing could not be done in
one function (i think).

I need a hint for a solution with that a could make a function like


QString func1()
{
QString output;
http = new Qhttp();
http->setHost("bla.org");

....

return(output);
}



Maybe someone has an idea?

Thx!
Markus
-- 
 [ signature omitted ] 

Message 2 in thread

> I need a hint for a solution with that a could make a function like
>
>
> QString func1()
> {
> QString output;
> http = new Qhttp();
> http->setHost("bla.org");
>
> ....
>
> return(output);
> }
you need to connect the signals emitted by QHttp. I had the same problems a 
few weeks ago and wrote a small helper-class, see

http://svn.sourceforge.net/viewvc/lupus/lupus/src/protocol_handler_http.h?revision=9&view=markup
http://svn.sourceforge.net/viewvc/lupus/lupus/src/protocol_handler_http.cpp?revision=9&view=markup

for details. You could use QBuffer as io-device and convert initialize your 
return-string with QBuffer::buffer().

toby

Attachment:

Attachment: pgpHFk9xJsXC8.pgp
Description: PGP signature


Message 3 in thread

That is not exactly what i was looking for, but brings me to the right idea!
You simply loop over the status-id from the http-process -> simply and
exactly what i need.

Thank you!
Markus

Tobias Doerffel wrote:

>> I need a hint for a solution with that a could make a function like
>>
>>
>> QString func1()
>> {
>> QString output;
>> http = new Qhttp();
>> http->setHost("bla.org");
>>
>> ....
>>
>> return(output);
>> }
> you need to connect the signals emitted by QHttp. I had the same problems
> a few weeks ago and wrote a small helper-class, see
> 
>
http://svn.sourceforge.net/viewvc/lupus/lupus/src/protocol_handler_http.h?revision=9&view=markup
>
http://svn.sourceforge.net/viewvc/lupus/lupus/src/protocol_handler_http.cpp?revision=9&view=markup
> 
> for details. You could use QBuffer as io-device and convert initialize
> your return-string with QBuffer::buffer().
> 
> toby

-- 
 [ signature omitted ] 

Message 4 in thread

Markus Litz wrote:

> That is not exactly what i was looking for, but brings me to the right
> idea! You simply loop over the status-id from the http-process -> simply
> and exactly what i need.
That (probably) won't work.
Your look will hog the CPU and not return control to the eventloop, which in
turn will result in your Qhttp object not doing anything, which in turn
will make sure the status will not change, resulting in an infinate loop.

You should at least return control to the eventloop in your loop somewhere,
but I'm sure there are better solutions.

André

--
 [ signature omitted ] 

Message 5 in thread

Am Samstag, 4. November 2006 12:28 schrieb André Somers:
> Markus Litz wrote:
> > That is not exactly what i was looking for, but brings me to the right
> > idea! You simply loop over the status-id from the http-process -> simply
> > and exactly what i need.
>
> That (probably) won't work.
> Your look will hog the CPU and not return control to the eventloop, which
> in turn will result in your Qhttp object not doing anything, which in turn
> will make sure the status will not change, resulting in an infinate loop.
calling QCoreApplication::processEvents(...) or calling an according 
sleep-function inside the loop should prevent this problem... beside that, 
QHttp works asynchronously so AFAIK there's no need for running the 
event-loop, but I might be wrong.

toby

Attachment:

Attachment: pgpst2f0Unfom.pgp
Description: PGP signature


Message 6 in thread

André Somers wrote:

> You should at least return control to the eventloop in your loop
> somewhere, but I'm sure there are better solutions.

Sounds like a very good idea. Is there a QT way to do this?

Markus

--
 [ signature omitted ] 

Message 7 in thread

"Markus Litz" <imp.palpatine@xxxxxx> wrote in message 
news:eipdq8$5j2$1@xxxxxxxxxxxxxxxxxxxxx
> André Somers wrote:
>
>> You should at least return control to the eventloop in your loop
>> somewhere, but I'm sure there are better solutions.
>
> Sounds like a very good idea. Is there a QT way to do this?

Try calling qApp->processEvents() occasionally in your
loop. 


--
 [ signature omitted ] 

Message 8 in thread

Am Dienstag, 7. November 2006 13:50 schrieb Duane Hebert:
> Try calling qApp->processEvents() occasionally in your
> loop.
isn't that what I posted in a previous mail? :-)

toby

Attachment:

Attachment: pgpsXmhn0tWwY.pgp
Description: PGP signature


Message 9 in thread

Hi,

>> You should at least return control to the eventloop in your loop
>> somewhere, but I'm sure there are better solutions.
> 
> Sounds like a very good idea. Is there a QT way to do this?

Generally speaking, there's an event-based programming(*) way:

1) Never write your own loops waiting for events. There's only one loop, 
that's the application loop. Just hook a callback / slot / event handler 
on the event you're interested in.

2) React to events by running short routines. Never write long routines 
(very roughly no more than 1 s in a GUI program), long routines can 
almost always be rewritten as a sequence of short routines. Call these 
short routines repeatedly using a timer with a timeout of 0:
	http://doc.trolltech.com/4.2/qtimer.html#details

3) As a workaround, when porting existing code - but preferably not when 
writing new code - call QApplication::processEvents() inside long 
routines or loops.

4) You may find threads helpful - but you still need to check some 
condition on a regular basis in your thread's code to be able to 
interrupt the thread. This is therefore not much different from calling 
processEvents() in a single-threaded program.

[*] http://www.google.com/search?q=event-based+programming

--
 [ signature omitted ]