Am 08.08.2013 00:11, schrieb Alexander Syvak:
[...]
auto const this_thread = this->thread ();
moveToThread (QApplication::instance()->thread());
screenshot = QPixmap::grabWindow( QApplication::desktop()->winId() );
moveToThread(this_thread);
[...]
I think you might have a proble
On quinta-feira, 8 de agosto de 2013 01:54:05, ZHONG Zhu wrote:
> Hi everyone,
>
> I've seen below error message print out to my DOS console (believe it's from
> stderror). Anyone happened to know which Qt class print this error message?
>
> "No memory valid."
There's no such string in the Q
Hi everyone,
I've seen below error message print out to my DOS console (believe it's from
stderror). Anyone happened to know which Qt class print this error message?
"No memory valid."
___
Interest mailing list
Interest@qt-project.org
http://lists.
I remember having problem with combobox when QT was built as static
libraries with static CRTs.
That is was one of the reason we gave up on static builds, is it your
case?
Alex
On Mon, Aug 5, 2013 at 6:53 PM, Mehrdad Momeny wrote:
> Hi everyone,
> Recently I encountered a weird issue on Window
On quinta-feira, 8 de agosto de 2013 01:11:09, Alexander Syvak wrote:
[cut all code]
Answering your subject: you cannot mix QThread and QPixmap. QPixmap can only
be used from the main (GUI) thread.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Tech
As far as I understand you need to make sure that window is grabbed in the
main thread.
So the clean way to do it - do it in the main threat without changing
affinity .
and wait until picture is taken in the threat you need a picture at.
This will also remove race conditions you are facing - your
Hello,
there's a need for each thread to make screenshots and to compare them with
loaded picture using QImage.
Since there's only on GUI thread, I moved the the thread context to the
main thread to make the screenshot in there.
Here's the code snipper from the worker-threads:
QPixmap scr
On 07-Aug-2013, at 12:50 AM, Nils Jeisecke wrote:
>> But I don't see a clear way to file bugs- is there a way?
> Just file a bug report http://bugreports.qt-project.org for component
> "Single Application".
Done: https://bugreports.qt-project.org/browse/QTSOLBUG-171
-John Weeks
___
On quarta-feira, 7 de agosto de 2013 12:22:39, Frans Klaver wrote:
> Could Shawn or Gunnar comment on this?
You have to post to the development mailing list to reach them. Anyway, your
topic looks very much like a development question -- running nested event
loops is a bad idea and it seems like
On quarta-feira, 7 de agosto de 2013 09:38:40, Michel Rosien wrote:
> According to the documentation, repaint() doesn’t repaint when the widget
> is hidden.
> So probably the show() call needs the event queue to execute first before
> it is fully shown?
Yes. It possibly also waits for the window m
2013/8/7 Cornelius Hald
> I've used the QML profiler to gather more information. Basically the
> only thing that is going on is painting via "Animation Timer Update".
>
> The profiler tells me that framerates are around 50 to 60 fps, so I
> think it should still look smooth. Unfortunately it does
Hello All,
I recently upgraded to Qt5.1 (from Qt4.8) and started noticing strange
behavior with signal handling.
It looks like signals are being handled while another signal is still being
handled.
In this call stack:
Qt5Guid.dll!QWindowSystemInterface::flushWindowSystemEvents() Line 554 C++
Hello All,
I have some old code that uses a QWidget::show(), followed by a
QWidget::repaint() to show a window (with a message) before a time
consuming operation starts.
In Qt4.8 this had the intended effect of fully showing the window before
continuing.
In Qt5.1 this does not show the window full
13 matches
Mail list logo
