Thiago Macieira schreef op 16-4-2015 om 18:16:
On Thursday 16 April 2015 12:35:36 Boudewijn Rempt wrote:
2) use it to catch exceptions and continue execution?
or use it to catch and abort?
We don't continue after an exception, but catch, log and abort.
Like I replied to Björn,
On Friday 17 April 2015 08:41:35 André Somers wrote:
Thiago Macieira schreef op 16-4-2015 om 18:16:
On Thursday 16 April 2015 12:35:36 Boudewijn Rempt wrote:
2) use it to catch exceptions and continue execution?
or use it to catch and abort?
We don't continue after an
On Friday 17 April 2015 09:03:08 Thiago Macieira wrote:
On Friday 17 April 2015 17:53:40 Guido Seifert wrote:
I know, but it still is not too convenient. In the console I get only
something like terminate called after throwing an instance of
'whatever'. No indication where the exception was
Thanks, got it Just a bit different than you proposed :-)
My problem was to get the thrown object in the terminate handler.
I searched for that, but it looks like there really is no such
function.
However, with this trick in the custom terminate it is possible
to get the desired object
It prints the exception type to stderr. If you want to log something
different,
install a different terminate handler.
Does this work? I don't see how a terminate handler gets the thrown object. A
terminate
handler takes no parameter and returns void. I am using notify only with use
case
On Friday 17 April 2015 17:27:39 Guido Seifert wrote:
It prints the exception type to stderr. If you want to log something
different, install a different terminate handler.
Does this work? I don't see how a terminate handler gets the thrown object.
There's a function to get the current
I have no need of knowing
which functions those are and how they operate because I don't use
exceptions,
so I can't help further.
:-)
And I don't because I usually use Qt. And in the few of my projects, which did
not use qt,
exceptions were forbidden.
You don't need a log output for
On 17 Apr 2015, at 2:46 pm, Alejandro Exojo s...@badopi.org wrote:
4) filter events being delivered (remove from queue / compress)?
We do this.
Could you elaborate a bit on how do you do it?
My answer was a bit short, wasn't it? I was responding to the part about
filtering. We use only
El Thursday 16 April 2015, John Weeks escribió:
4) filter events being delivered (remove from queue / compress)?
We do this.
Could you elaborate a bit on how do you do it?
Filtering events is easy, but when I searched a bit in the past about this, I
found that there is no public API for
On Wednesday 15 April 2015 16:45:57 Thiago Macieira wrote:
Hello
We're running into problems with QCoreApplication::notify() and auxiliary
threads in Qt. Details can be found in [1] and [2].
[1] http://lists.qt-project.org/pipermail/development/2015-April/021053.html
[2]
On Friday 17 April 2015 17:53:40 Guido Seifert wrote:
I know, but it still is not too convenient. In the console I get only
something like terminate called after throwing an instance of
'whatever'. No indication where the exception was thrown. To see this I
have to find and examine the core,
hi,
As part of trying to design the solution, I'd like to know what people
override QCoreApplication::notify() for.
we have 3rd party plugins - beside our own crude code, sometimes - called in
threads and in q(core)application in various situations, which throw
exceptions. errors, yes, but
On Wed, 15 Apr 2015, Thiago Macieira wrote:
So, if you do override, do you:
1) use it to log exceptions that were caught?
2) use it to catch exceptions and continue execution?
or use it to catch and abort?
3) log/profile/debug events being delivered?
We do something like 3)
4) filter
To catch and abort.
2015-04-16 8:11 GMT+02:00 alexander golks a...@golks.de:
hi,
As part of trying to design the solution, I'd like to know what people
override QCoreApplication::notify() for.
we have 3rd party plugins - beside our own crude code, sometimes - called
in threads and in
On 16/04/15 02:45, Thiago Macieira wrote:
As part of trying to design the solution, I'd like to know what people
override QCoreApplication::notify() for.
I override QApplication::notify() in order to catch media keys (volume
up/down, stop, play, etc.) on the application level, regardless of
On Wed, 15 Apr 2015, Thiago Macieira wrote:
Hello
We're running into problems with QCoreApplication::notify() and auxiliary
threads in Qt. Details can be found in [1] and [2].
As part of trying to design the solution, I'd like to know what people
override QCoreApplication::notify() for.
On Thursday 16 April 2015 12:35:36 Boudewijn Rempt wrote:
2) use it to catch exceptions and continue execution?
or use it to catch and abort?
We don't continue after an exception, but catch, log and abort.
Like I replied to Björn, std::terminate already does that.
--
Thiago Macieira
John Weeks and I are working on the same application, so don't double count
this, but I wanted to clarify:
On Wed, Apr 15, 2015 at 4:45 PM, Thiago Macieira thiago.macie...@intel.com
wrote:
2) use it to catch exceptions and continue execution?
or use it to catch and abort?
If we catch
Hello
We're running into problems with QCoreApplication::notify() and auxiliary
threads in Qt. Details can be found in [1] and [2].
As part of trying to design the solution, I'd like to know what people
override QCoreApplication::notify() for.
So, if you do override, do you:
1) use it to log
4) filter events being delivered (remove from queue / compress)?
We do this.
We also maintain our own z-order window list and use the notify event to
intercept WindowActivated and WindowDeactivated events.
The application includes a programming language that users can use to create,
destroy
20 matches
Mail list logo
