[Interest] More on table problem
Here's more info on the weird QTableWidget problem we're seeing. One of our data entry fields uses combination of widgets: a QLineEdit subclass with a linked QToolButton subclass next to it, and a QListWidget subclass that drops down underneath. It acts kinda like a combo box, but better for really long lists. The whole assembly works properly in regular data entry screens. Clicking on button or list changes values in the line edit field. We use setCellWidget to put the same QLineEdit subclass into a QTableWidget cell. The button and list appear properly, but the button does not catch mouse clicks. They go to the cell behind the button instead. We use signals/slots to connect the clicked signal, but don't fiddle with events otherwise. Casey McD ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on table problem
> On 11 Jun 2021, at 13:52, Turtle Creek Software
> wrote:
>
> Here's more info on the weird QTableWidget problem we're seeing.
>
> One of our data entry fields uses combination of widgets: a QLineEdit
> subclass with a linked QToolButton subclass next to it, and a QListWidget
> subclass that drops down underneath. It acts kinda like a combo box, but
> better for really long lists. The whole assembly works properly in regular
> data entry screens. Clicking on button or list changes values in the line
> edit field.
>
> We use setCellWidget to put the same QLineEdit subclass into a QTableWidget
> cell. The button and list appear properly, but the button does not catch
> mouse clicks. They go to the cell behind the button instead.
>
> We use signals/slots to connect the clicked signal, but don't fiddle with
> events otherwise.
>
> Casey McD
This works fine:
#include
class CellWidget : public QWidget
{
public:
CellWidget()
{
QLineEdit *le = new QLineEdit;
QToolButton *tb = new QToolButton;
QMenu *toolMenu = new QMenu;
toolMenu->addAction(new QAction("Action 1", this));
toolMenu->addAction(new QAction("Action 2", this));
toolMenu->addAction(new QAction("Action 3", this));
tb->setPopupMode(QToolButton::InstantPopup);
tb->setMenu(toolMenu);
QHBoxLayout *hbox = new QHBoxLayout;
hbox->addWidget(le);
hbox->addWidget(tb);
setContentsMargins(0, 0, 0, 0);
hbox->setContentsMargins(0, 0, 0, 0);
setLayout(hbox);
}
QSize minimumSizeHint() const { return QSize(100, 100); }
};
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QTableWidget table(10, 10);
table.setCellWidget(5, 5, new CellWidget);
table.show();
return app.exec();
}
Volker
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options
To close this thread, a bunch of changes that fix this in the least intrusive way have been merged for Qt 6.2. In ExtendedSelection, Ctrl+Press does not deselect items that could also be dragged, Ctrl+Release does; Ctrl+Press on an unselected item selects the item, then you can drag it as part of a previous selection. An equivalent change n MultiSelection (minus the Ctrl): * https://codereview.qt-project.org/c/qt/qtbase/+/351595/8 * https://codereview.qt-project.org/c/qt/qtbase/+/352401 Thanks for the comments and reviews. Qt 6.2 should be available as snapshot packages already, and the Alpha is around the corner as well. Early feedback to those (and several other changes and fixes to Qt Widgets from the last couple of weeks [1]) would be most welcome. Cheers, Volker [1] https://codereview.qt-project.org/q/is:merged+branch:dev+path:%255Esrc/widgets/.*+after:2021-05-31 > On 1 Jun 2021, at 21:43, Volker Hilsheimer wrote: > > But git history will remember the fool that broke all the things :P > > Anyway, a bunch of patches in the chain currently ending at > > https://codereview.qt-project.org/c/qt/qtbase/+/351595/3 > > in case anyone wants to give it a swing. MultiSelection is not changed yet, > and it looks like we might get away with a minimal change for > ExtendedSelection. > > There’s no intention to bring those changes to Qt 5. > > Volker > > >> On 28 May 2021, at 19:01, Elvis Stansvik wrote: >> >> Yea man, just change it. No one remembers a coward! :) >> >> Den fre 28 maj 2021 kl 17:07 skrev David M. Cotter : >>> >>> assuming your change "does the right thing in all cases" then i think it >>> should be the default. >>> >>> nobody WANTS the currently-bad behavior. >>> >>> -dave >>> On May 28, 2021, at 5:55 AM, Volker Hilsheimer wrote: Cross-posting from the development mailing list in case any of you have a strong opinion about this. Volker > On 28 May 2021, at 13:10, Volker Hilsheimer > wrote: > > Hey Widget fans, > > I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888 > > The UX resulting from our (strange) choice to trigger selection changes > on mouse press rather than mouse release is indeed quite horrible, as > explained in the ticket. > > The options to fix that seem to be: > > 1) change the default behavior - always change selection on mouse release > 2) change the default behavior if drag (as per dragDropMode) > 3) make the "selection trigger" a property > > None of those options would IMHO result in a change that qualifies for > stable branches. I’ve for now implemented option 3. This introduces new > API, so if we agree that this is the way to go then it would ideally be > merged before 6.2 feature freeze next Friday. > > https://codereview.qt-project.org/c/qt/qtbase/+/351595 > > However, the possible property values seem oddly specific to this > problem, and give that this is a 6.2 only change anyway, perhaps it would > be best to simply change the default, which would then also make Qt > matching native UIs better (ie Windows Explorer or macOS Finder)? > > Cheers, > Volker > > ___ > Development mailing list > developm...@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest >>> >>> ___ >>> Interest mailing list >>> Interest@qt-project.org >>> https://lists.qt-project.org/listinfo/interest >> ___ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on table problem
If I understand this code correctly, it's putting the button inside the
cell. Unfortunately, there isn't enough room to do that.
The table only shows the QLineEdits. When you click in a cell to edit, the
button appears next to it, over the neighboring cell(s).
However, maybe there is a container we can put the button into, that will
act as a click barrier. Something less extreme than a dialog.
Casey McD
On Fri, Jun 11, 2021 at 10:05 AM Volker Hilsheimer
wrote:
> > On 11 Jun 2021, at 13:52, Turtle Creek Software
> wrote:
> >
> > Here's more info on the weird QTableWidget problem we're seeing.
> >
> > One of our data entry fields uses combination of widgets: a QLineEdit
> subclass with a linked QToolButton subclass next to it, and a QListWidget
> subclass that drops down underneath. It acts kinda like a combo box, but
> better for really long lists. The whole assembly works properly in regular
> data entry screens. Clicking on button or list changes values in the line
> edit field.
> >
> > We use setCellWidget to put the same QLineEdit subclass into a
> QTableWidget cell. The button and list appear properly, but the button does
> not catch mouse clicks. They go to the cell behind the button instead.
> >
> > We use signals/slots to connect the clicked signal, but don't fiddle
> with events otherwise.
> >
> > Casey McD
>
>
> This works fine:
>
> #include
>
> class CellWidget : public QWidget
> {
> public:
> CellWidget()
> {
> QLineEdit *le = new QLineEdit;
> QToolButton *tb = new QToolButton;
> QMenu *toolMenu = new QMenu;
> toolMenu->addAction(new QAction("Action 1", this));
> toolMenu->addAction(new QAction("Action 2", this));
> toolMenu->addAction(new QAction("Action 3", this));
> tb->setPopupMode(QToolButton::InstantPopup);
> tb->setMenu(toolMenu);
>
> QHBoxLayout *hbox = new QHBoxLayout;
> hbox->addWidget(le);
> hbox->addWidget(tb);
> setContentsMargins(0, 0, 0, 0);
> hbox->setContentsMargins(0, 0, 0, 0);
>
> setLayout(hbox);
> }
>
> QSize minimumSizeHint() const { return QSize(100, 100); }
> };
>
> int main(int argc, char **argv)
> {
> QApplication app(argc, argv);
>
> QTableWidget table(10, 10);
> table.setCellWidget(5, 5, new CellWidget);
>
> table.show();
>
> return app.exec();
> }
>
>
> Volker
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Multi-Selection behavior of item views breaks drag'n'drop UX - options
Nice work Volker! Elvis Den fre 11 juni 2021 16:18Volker Hilsheimer skrev: > To close this thread, a bunch of changes that fix this in the least > intrusive way have been merged for Qt 6.2. > > In ExtendedSelection, Ctrl+Press does not deselect items that could also > be dragged, Ctrl+Release does; Ctrl+Press on an unselected item selects the > item, then you can drag it as part of a previous selection. An equivalent > change n MultiSelection (minus the Ctrl): > > * https://codereview.qt-project.org/c/qt/qtbase/+/351595/8 > * https://codereview.qt-project.org/c/qt/qtbase/+/352401 > > Thanks for the comments and reviews. Qt 6.2 should be available as > snapshot packages already, and the Alpha is around the corner as well. > Early feedback to those (and several other changes and fixes to Qt Widgets > from the last couple of weeks [1]) would be most welcome. > > > Cheers, > Volker > > [1] > https://codereview.qt-project.org/q/is:merged+branch:dev+path:%255Esrc/widgets/.*+after:2021-05-31 > > > > On 1 Jun 2021, at 21:43, Volker Hilsheimer > wrote: > > > > But git history will remember the fool that broke all the things :P > > > > Anyway, a bunch of patches in the chain currently ending at > > > > https://codereview.qt-project.org/c/qt/qtbase/+/351595/3 > > > > in case anyone wants to give it a swing. MultiSelection is not changed > yet, and it looks like we might get away with a minimal change for > ExtendedSelection. > > > > There’s no intention to bring those changes to Qt 5. > > > > Volker > > > > > >> On 28 May 2021, at 19:01, Elvis Stansvik wrote: > >> > >> Yea man, just change it. No one remembers a coward! :) > >> > >> Den fre 28 maj 2021 kl 17:07 skrev David M. Cotter : > >>> > >>> assuming your change "does the right thing in all cases" then i think > it should be the default. > >>> > >>> nobody WANTS the currently-bad behavior. > >>> > >>> -dave > >>> > On May 28, 2021, at 5:55 AM, Volker Hilsheimer < > volker.hilshei...@qt.io> wrote: > > Cross-posting from the development mailing list in case any of you > have a strong opinion about this. > > Volker > > > > On 28 May 2021, at 13:10, Volker Hilsheimer > wrote: > > > > Hey Widget fans, > > > > I need your opinions on https://bugreports.qt.io/browse/QTBUG-59888 > > > > The UX resulting from our (strange) choice to trigger selection > changes on mouse press rather than mouse release is indeed quite horrible, > as explained in the ticket. > > > > The options to fix that seem to be: > > > > 1) change the default behavior - always change selection on mouse > release > > 2) change the default behavior if drag (as per dragDropMode) > > 3) make the "selection trigger" a property > > > > None of those options would IMHO result in a change that qualifies > for stable branches. I’ve for now implemented option 3. This introduces new > API, so if we agree that this is the way to go then it would ideally be > merged before 6.2 feature freeze next Friday. > > > > https://codereview.qt-project.org/c/qt/qtbase/+/351595 > > > > However, the possible property values seem oddly specific to this > problem, and give that this is a 6.2 only change anyway, perhaps it would > be best to simply change the default, which would then also make Qt > matching native UIs better (ie Windows Explorer or macOS Finder)? > > > > Cheers, > > Volker > > > > ___ > > Development mailing list > > developm...@qt-project.org > > https://lists.qt-project.org/listinfo/development > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > >>> > >>> ___ > >>> Interest mailing list > >>> Interest@qt-project.org > >>> https://lists.qt-project.org/listinfo/interest > >> ___ > >> Interest mailing list > >> Interest@qt-project.org > >> https://lists.qt-project.org/listinfo/interest > > > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on table problem
I tried putting the button inside a QFrame, but it has the same problem.
Casey McD
On Fri, Jun 11, 2021 at 10:05 AM Volker Hilsheimer
wrote:
> > On 11 Jun 2021, at 13:52, Turtle Creek Software
> wrote:
> >
> > Here's more info on the weird QTableWidget problem we're seeing.
> >
> > One of our data entry fields uses combination of widgets: a QLineEdit
> subclass with a linked QToolButton subclass next to it, and a QListWidget
> subclass that drops down underneath. It acts kinda like a combo box, but
> better for really long lists. The whole assembly works properly in regular
> data entry screens. Clicking on button or list changes values in the line
> edit field.
> >
> > We use setCellWidget to put the same QLineEdit subclass into a
> QTableWidget cell. The button and list appear properly, but the button does
> not catch mouse clicks. They go to the cell behind the button instead.
> >
> > We use signals/slots to connect the clicked signal, but don't fiddle
> with events otherwise.
> >
> > Casey McD
>
>
> This works fine:
>
> #include
>
> class CellWidget : public QWidget
> {
> public:
> CellWidget()
> {
> QLineEdit *le = new QLineEdit;
> QToolButton *tb = new QToolButton;
> QMenu *toolMenu = new QMenu;
> toolMenu->addAction(new QAction("Action 1", this));
> toolMenu->addAction(new QAction("Action 2", this));
> toolMenu->addAction(new QAction("Action 3", this));
> tb->setPopupMode(QToolButton::InstantPopup);
> tb->setMenu(toolMenu);
>
> QHBoxLayout *hbox = new QHBoxLayout;
> hbox->addWidget(le);
> hbox->addWidget(tb);
> setContentsMargins(0, 0, 0, 0);
> hbox->setContentsMargins(0, 0, 0, 0);
>
> setLayout(hbox);
> }
>
> QSize minimumSizeHint() const { return QSize(100, 100); }
> };
>
> int main(int argc, char **argv)
> {
> QApplication app(argc, argv);
>
> QTableWidget table(10, 10);
> table.setCellWidget(5, 5, new CellWidget);
>
> table.show();
>
> return app.exec();
> }
>
>
> Volker
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] QNetwork classes for submitting google forms
Hi,
I am trying to submit google forms programmatically via C++ and Qt classes
I am basing my study on the following
https://stackoverflow.com/questions/17964429/google-forms-response-with-python#17965510
I got the Python version running and returned a 200 response.
I tried converting the code to C++ and Qt but was not successful. I get a
response of '0' zero
I would like to know if I am using the Qt QNetwork classes correctly to
submit a post to a URL that is a Google form
=
#include
#include
#include
#include
#include
int main()
{
QUrlQuery postData;
postData.addQueryItem("emailAddress", "abc@gmail.com");
postData.addQueryItem("entry.2020959411", "Qt Query");
/*
*
url = '
https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse
'
form_data = {'entry.2020959411': '18+ sollte absolute Pflicht sein',
#'entry.2020959411': 'Alter sollte garkeine Rolle spielen',
#'entry.2020959411': '17+ wäre für mich vertretbar',
#'entry.2020959411': '16+ wäre für mich vertretbar',
#'entry.2020959411': '15+ wäre für mich vertretbar',
#'entry.2020959411': 'Ausnahmen von der Regel - Dafür?',
#'entry.2020959411': 'Ausnahmen von der Regel - Dagegen?',
#'entry.2020959411': '__other_option__',
#'entry.2020959411.other_option_response': 'test',
'draftResponse': [],
'pageHistory': 0} *
*/
QUrl serviceUrl("
https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse
");
// ...
QNetworkRequest request(serviceUrl);
//request.setHeader(QNetworkRequest::ContentTypeHeader,
//"application/x-www-form-urlencoded");
QNetworkAccessManager networkManager;
QNetworkReply* reply;
reply = networkManager.post(request,
postData.toString(QUrl::FullyEncoded).toUtf8());
QVariant statusCode = reply->attribute(
QNetworkRequest::HttpStatusCodeAttribute );
int status = statusCode.toInt();
qDebug() << status;
if ( status != 200 )
{
QString reason = reply->attribute(
QNetworkRequest::HttpReasonPhraseAttribute ).toString();
qDebug() << reason;
}
return 0;
}
--
Nicholas Yue
Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
https://vimeo.com/channels/naiadtools
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
Hello Nicholas,
I would like to know if I am using the Qt QNetwork classes correctly
to submit a post to a URL that is a Google form
From the docs[1]: QNetworkAccessManager has an asynchronous API.
That means you have to wait for a finished() signal before trying to
determine the status or read response data. The call to post() returns
right away, probably before the request is even sent.
The docs have a pretty basic example, but to put it into your context,
it would look something like this:
// ...
QNetworkAccessManager networkManager;
bool gotResponse = false;
QObject::connect(&networkManager, &networkManager::finished,
[&gotResponse](QNetworkReply *reply) {
int status = reply->attribute(
QNetworkRequest::HttpStatusCodeAttribute).toInt();
qDebug() << status;
// etc
gotResponse = true;
});
networkManager.post(request,
postData.toString(QUrl::FullyEncoded).toUtf8());
while (!gotResponse)
sleep(1) // or whatever sleep method, just waiting for a response.
return 0;
}
HTH,
-Max
[1]: https://doc.qt.io/qt-5/qnetworkaccessmanager.html
On 6/11/2021 4:22 PM, Nicholas Yue wrote:
Hi,
I am trying to submit google forms programmatically via C++ and Qt classes
I am basing my study on the following
https://stackoverflow.com/questions/17964429/google-forms-response-with-python#17965510
I got the Python version running and returned a 200 response.
I tried converting the code to C++ and Qt but was not successful. I get
a response of '0' zero
I would like to know if I am using the Qt QNetwork classes correctly to
submit a post to a URL that is a Google form
=
#include
#include
#include
#include
#include
int main()
{
QUrlQuery postData;
postData.addQueryItem("emailAddress", "abc@gmail.com
");
postData.addQueryItem("entry.2020959411", "Qt Query");
/*
*
url =
'https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse'
form_data = {'entry.2020959411': '18+ sollte absolute Pflicht sein',
#'entry.2020959411': 'Alter sollte garkeine Rolle
spielen',
#'entry.2020959411': '17+ wäre für mich vertretbar',
#'entry.2020959411': '16+ wäre für mich vertretbar',
#'entry.2020959411': '15+ wäre für mich vertretbar',
#'entry.2020959411': 'Ausnahmen von der Regel - Dafür?',
#'entry.2020959411': 'Ausnahmen von der Regel - Dagegen?',
#'entry.2020959411': '__other_option__',
#'entry.2020959411.other_option_response': 'test',
'draftResponse': [],
'pageHistory': 0} *
*/
QUrl
serviceUrl("https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse";);
// ...
QNetworkRequest request(serviceUrl);
//request.setHeader(QNetworkRequest::ContentTypeHeader,
// "application/x-www-form-urlencoded");
QNetworkAccessManager networkManager;
QNetworkReply* reply;
reply = networkManager.post(request,
postData.toString(QUrl::FullyEncoded).toUtf8());
QVariant statusCode = reply->attribute(
QNetworkRequest::HttpStatusCodeAttribute );
int status = statusCode.toInt();
qDebug() << status;
if ( status != 200 )
{
QString reason = reply->attribute(
QNetworkRequest::HttpReasonPhraseAttribute ).toString();
qDebug() << reason;
}
return 0;
}
--
Nicholas Yue
Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
https://vimeo.com/channels/naiadtools
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
QObject::connect(&networkManager, &networkManager::finished, ... Whoops, should really be QObject::connect(&networkManager, &QNetworkAccessManager::finished, ... -Max ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
```
int main()
{
QUrlQuery postData;
postData.addQueryItem("emailAddress", "abc@gmail.com");
postData.addQueryItem("entry.2020959411", "Qt Query");
QUrl
serviceUrl("https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse";);
QNetworkRequest request(serviceUrl);
QNetworkAccessManager networkManager;
bool gotResponse = false;
QObject::connect(&networkManager, &QNetworkAccessManager::finished,
[&gotResponse](QNetworkReply *reply) {
int status = reply->attribute(
QNetworkRequest::HttpStatusCodeAttribute).toInt();
qDebug() << status;
// etc
gotResponse = true;
});
networkManager.post(request,
postData.toString(QUrl::FullyEncoded).toUtf8());
while (!gotResponse) {
QThread::sleep(1); // or whatever sleep method, just waiting
for a response.
qDebug() << "Slept 1 second";
}
return 0;
}
```
It just sits there, I get the regular print out about 'Slept 1
second', other than that, it does not seems to be working
On Fri, 11 Jun 2021 at 14:18, Max Paperno wrote:
>
> > QObject::connect(&networkManager, &networkManager::finished, ...
>
> Whoops, should really be
> QObject::connect(&networkManager, &QNetworkAccessManager::finished, ...
>
> -Max
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
--
Nicholas Yue
Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
https://vimeo.com/channels/naiadtools
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
Ah yeah, it would help a lot to have a Qt event loop to actually deliver
the signals... silly me. Also forgot to delete the reply as per docs.
Tested, works:
int main(int argc, char**argv)
{
QCoreApplication app(argc, argv);
QUrlQuery postData;
postData.addQueryItem("entry.2020959411", "Qt Query");
QUrl serviceUrl("http://httpbin.org/post";);
QNetworkRequest request(serviceUrl);
QNetworkAccessManager networkManager;
QObject::connect(&networkManager, &QNetworkAccessManager::finished,
[&](QNetworkReply *reply) {
int status =
reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt();
qDebug() << "Got status:" << status << "Data:" << reply->readAll();
// etc
reply->deleteLater();
app.exit();
});
networkManager.post(request,
postData.toString(QUrl::FullyEncoded).toUtf8());
return app.exec();
}
Please reply to the list, not to me, thanks.
HTH,
-Max
On 6/11/2021 6:53 PM, Nicholas Yue wrote:
```
intmain()
{
QUrlQuerypostData;
postData.addQueryItem("emailAddress","abc@gmail.com
");
postData.addQueryItem("entry.2020959411","QtQuery");
QUrlserviceUrl("https://docs.google.com/forms/d/152CTd4VY9pRvLfeACOf6SmmtFAp1CL750Sx72Rh6HJ8/formResponse";);
QNetworkRequestrequest(serviceUrl);
QNetworkAccessManagernetworkManager;
boolgotResponse=false;
QObject::connect(&networkManager,&QNetworkAccessManager::finished,
[&gotResponse](QNetworkReply*reply){
intstatus=reply->attribute(
QNetworkRequest::HttpStatusCodeAttribute).toInt();
qDebug()> wrote:
> QObject::connect(&networkManager, &networkManager::finished, ...
Whoops, should really be
QObject::connect(&networkManager,
&QNetworkAccessManager::finished, ...
-Max
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
--
Nicholas Yue
Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
https://vimeo.com/channels/naiadtools
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
On Friday, 11 June 2021 14:10:57 PDT Max Paperno wrote: > while (!gotResponse) >sleep(1) // or whatever sleep method, just waiting for a response. NEVER EVER sleep. Insert a "return" here and let your slot be called when the time is right. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QNetwork classes for submitting google forms
On 6/11/2021 10:32 PM, Thiago Macieira wrote: On Friday, 11 June 2021 14:10:57 PDT Max Paperno wrote: while (!gotResponse) sleep(1) // or whatever sleep method, just waiting for a response. NEVER EVER sleep. Insert a "return" here and let your slot be called when the time is right. Right, too much Python lately... "should" have been `processEvents()` which is when I realized there were no events to process w/out a Qt loop in the first place. Returning from main() wouldn't have solved the issue though. -Max ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
