Qt-interest Archive, January 2007
Qt3 equivalent of QIODevice::peek()?
Message 1 in thread
I have some Qt4 code that needs to be back ported to a Qt3 project.
In my Qt4 project, I have a QTCPSocket (which inherits eventually from a
QIODevice), where when I receive data over the socket, I peek at the
first couple of bytes looking for a sync pattern to make sure I'm
getting a message that I know how to decode. To do that I call:
QByteArray QIODevice::peek ( qint64 maxSize )
I'm looking for a similar function in Qt3's QSocket class, where I can
look into the QIODevice's buffer without removing bytes from the buffer.
The only thing I see is:
virtual Q_LONG readBlock ( char * data, Q_ULONG maxlen )
But that function actually removes the data from the QIODevice which I'm
trying to avoid.
Sean
--
[ signature omitted ]
Message 2 in thread
Murphy, Sean M. wrote:
> I'm looking for a similar function in Qt3's QSocket class, where I can
> look into the QIODevice's buffer without removing bytes from the buffer.
> The only thing I see is:
> virtual Q_LONG readBlock ( char * data, Q_ULONG maxlen )
> But that function actually removes the data from the QIODevice which I'm
> trying to avoid.
You can achieve the same thing as what Qt 4 does by calling ungetch() on the
data you receive for sequential devices, or seek() back for random-access
devices. That's what Qt 4 does, too.
Andreas
--
[ signature omitted ]
Message 3 in thread
Ok, so if I wanted to peek at the first 12 bytes, I could pull the first 12 bytes out into my own buffer, either by running through a loop calling getch() 12 times, or by calling readBlock(myBuffer, 12). Then I would immediately run through my buffer backwards calling ungetch() 12 times? Something like:
char myBuffer[12];
QSocket socket;
socket.readBlock(myBuffer, 12);
for (int i=11; i >=0; i--)
{
socket.ungetch(myBuffer[i]);
}
Sean
-----Original Message-----
From: Andreas Aardal Hanssen [mailto:ahanssen@xxxxxxxxxxxxx]
Sent: Fri 1/12/2007 2:33 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Qt3 equivalent of QIODevice::peek()?
Murphy, Sean M. wrote:
> I'm looking for a similar function in Qt3's QSocket class, where I can
> look into the QIODevice's buffer without removing bytes from the buffer.
> The only thing I see is:
> virtual Q_LONG readBlock ( char * data, Q_ULONG maxlen )
> But that function actually removes the data from the QIODevice which I'm
> trying to avoid.
You can achieve the same thing as what Qt 4 does by calling ungetch() on the
data you receive for sequential devices, or seek() back for random-access
devices. That's what Qt 4 does, too.
Andreas
--
[ signature omitted ]
Message 4 in thread
Murphy, Sean M. wrote:
> Ok, so if I wanted to peek at the first 12 bytes, I could pull the first
> 12 bytes out into my own buffer, either by running through a loop calling
> getch() 12 times, or by calling readBlock(myBuffer, 12). Then I would
> immediately run through my buffer backwards calling ungetch() 12 times?
> Something like:
> char myBuffer[12];
> QSocket socket;
> socket.readBlock(myBuffer, 12);
> for (int i=11; i >=0; i--)
> socket.ungetch(myBuffer[i]);
Yes, something like that.
Andreas
--
[ signature omitted ]
Message 5 in thread
Hi,
is anyone has any experience about drag&drop managment in a Qt4 app that
use a tablet?
It seams that D&D using the native D&D protocol, it's not possible to
have any control about D&D operation when We use a tablet and want to
D&D from/to a tablet and the screen?
if someone did something like this and can give some report about
feasability, limitations?...
thank for any tips, info, link...
Veronique.
--
[ signature omitted ]
Message 6 in thread
Hello Veronique,
whats D&D ???
Maybe we could help you, if we know what you're talking about ;)
Greets,
Chris
--
[ signature omitted ]
Message 7 in thread
sorry, D&D for Drag and Drop
Christian Dähn a écrit :
>Hello Veronique,
>
>whats D&D ???
>
>Maybe we could help you, if we know what you're talking about ;)
>
>Greets,
>Chris
>
>
>--
>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 ]
Message 8 in thread
Hi,
I need from an URL, do the following in an automatic way:
- to connect to the http server
- from the (known and always identical) page I need to set the value of
a combo box (<option>) and of a text field
- "Press" the button that launches a search on the server
- Read the result page (in another frame) and extract data from it
The preceding should be done automatically without any user input. I
don't even need any GUI, just simulate all these actions to get the
result page.
Which Qt classes or solutions are the more efficient way to do this?
Thanks
--
[ signature omitted ]
Message 9 in thread
veronique.lefrere@xxxxxx wrote:
> Hi,
>
> I need from an URL, do the following in an automatic way:
> - to connect to the http server
> - from the (known and always identical) page I need to set the value of
> a combo box (<option>) and of a text field
> - "Press" the button that launches a search on the server
> - Read the result page (in another frame) and extract data from it
>
> The preceding should be done automatically without any user input. I
> don't even need any GUI, just simulate all these actions to get the
> result page.
> Which Qt classes or solutions are the more efficient way to do this?
Usually your option HTML widget is within a <form>. This form specifies
an action what should happen when it is submitted. Usually the form
values are then passed along to some PHP script, another
*.asp/*.jsp/*.html page or whatever (see <form action="..."> details).
The actual values of the form children are passed as arguments to the
receiver, for example in your browser you would see (assuming a PHP
script here):
http://www.myurl.net/search.php?option=3
Now your solution is simple: you simply call this URL (receiver) with
the desired argument(s) (the arguments are the names of the form
children and their value, after the ?). I assume this would look like this:
// adapted from QHttp class documentation
QHttpRequestHeader header("GET", "/search.php?option=3");
header.setValue("Host", "www.myurl.net");
http->setHost("www.myurl.net");
http->request(header);
(maybe you need to change GET to POST, not sure... in fact I have never
used the QHttp/Request class myself, so the above might be complete
nonsense! ;)
Hope that helps, Oliver
--
[ signature omitted ]
Message 10 in thread
Till Oliver Knoll wrote:
> veronique.lefrere@xxxxxx wrote:
>
>> Hi,
>>
>> I need from an URL, do the following in an automatic way:
>> - to connect to the http server
>> - from the (known and always identical) page I need to set the value
>> of a combo box (<option>) and of a text field
>> - "Press" the button that launches a search on the server
>> - Read the result page (in another frame) and extract data from it
>> ...
> Now your solution is simple: you simply call this URL (receiver) with
> the desired argument(s) (the arguments are the names of the form
> children and their value, after the ?). I assume this would look like this:
>
> // adapted from QHttp class documentation
> QHttpRequestHeader header("GET", "/search.php?option=3");
> header.setValue("Host", "www.myurl.net");
> http->setHost("www.myurl.net");
> http->request(header);
Look at the form settings in the page, usually a form is defined like this:
<form method="post" action="http://www.myurl.net/search.php">
<input type="radio" name="option" value="1"> Foo<br /></input>
<input type="radio" name="option" value="2"> Bar<br /></input>
<input type="radio" name="option" value="3"> Zoo</input>
<input type="submit" value="Submit" />
</form>
According to the QHttp docs you can shorten the example in my first post
like this:
http->setHost ("www.myurl.net");
http->post ("/search.php?option=3"); // "Zoo" has been selected
After a while the server will send the resulting page, which QHttp will
signal with QHttp::readyRead. Then you can read the answer with
QHttp::readAll() which will give you a QByteArray which you can parse
for the expected results.
Have never tried it, but it might actually work ;)
Cheers, Oliver
--
[ signature omitted ]