exit).
I find it simpler, and much less likely to trigger an antivirus than a
vbs file :)
--
Julien Cugnière
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Le mer. 9 sept. 2020 à 15:38, Andrei Golubev a écrit :
>
> I don't understand what this means. Am I supposed to reserve a
> container to its current size before erasing elements
> from it, if I don't want the erase to shrink it?
>
> Yes.
For what it's worth, as a user, I think this would violate
Le ven. 21 févr. 2020 à 12:29, Giuseppe D'Angelo via Development
a écrit :
>
> Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> >> without any annotation is not what we want. We'd miss vital information
> >> and reduce readability.
> > Can you please explain what that vital information is?
>
>
luation: how
does this interact with the "onPropertyChanged" signal? In QML, one
sometimes sees code like :
onFullnameChanged: {
console.log("the fullname changed!");
foo.bar();
}
At first glance, this doesn't seem compatible wi
ebug() << v.size(); // crash
QString s;
qDebug() << s.indexOf("foo"); // crash
What about std::string and std::vector ?
--
Julien Cugnière
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
7 in
> > the config this doesn't build for me, even though I don’t use auto in the
> > template paramter list).
> >
> >
> > Cheers,
> > Volker
> >
> >
> > [1] which was requested to be made public in
> > https://bugreports.qt.io/browse/QTBUG-38575
Julien Cugnière
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
2015-04-16 1:30 GMT+02:00 Thiago Macieira :
> My idea is to provide you with the ability to:
> - decide whether to catch or not
> - supply a handler that will be called if an exception is caught
> - decide whether a caught exception resumes execution or aborts the
>application (after your ha
hich
> means they may call your notify() during the destructor, including just after
> it finished and ~QApplication began.
It's a background service, so not really. But I suppose sooner or
later we'll run into problems if some other part of Qt starts to use
threads.
By the way,
2015-04-14 20:39 GMT+02:00 Thiago Macieira :
>
> We removed the try/catch and replaced with stack objects that will unwind
> properly. If you're lucky, an exception will simply unwind QCoreApplication
> out of exec(), so a try/catch around exec() may work.
>
> But this is untested and unsupported.
pplication object when this behavior is required ?
Julien Cugnière
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
10 matches
Mail list logo
