> You have two viable approaches here:
> * break up the saving method into chunks. That is, do a small part of the
> work of the saving, queue the next piece of work to be done, and return to
> the eventloop. The eventloop will then trigger the next queued piece of the
> work being done. This way,
On segunda-feira, 18 de novembro de 2013 08:15:48, Konrad Rosenbaum wrote:
> it is always safe to call processEvents yourself.
No, it's not. There are a lot of situations when doing that will cause you
problems elsewhere.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
Den 17-11-2013 17:29, Tomasz Siekierda skrev:
> As said: getters and setters:)
Add a signal to inform about changes to one of the settings plus declare
each setting with Q_PROPERTY, and we're there.
Bo.
--
Bo Thorsen, European Engineering Manager, ICS
Integrated Computer Solutions. Delivering W
Hi,
it is always safe to call processEvents yourself. If the QProgressDialog has
display issues it obviously does not get enough CPU to update itself, calling
processEvents more often may(!!) help.
When I want to see a QProgressDialog early I normally force the issue by
calling show() immediat
Etienne Sandré-Chardonnal schreef op 15-11-2013 14:05:
Dear all,
I have a long file saving function (gigabytes - several minutes) and I
am trying to use QProcessDialog. I am using it the Modal way as
explained in the documentation. However, the dialog appears after
about 50 seconds, despite h
AFAIK you can't prevent other windows goes below one by using any window flag,
this kind of behavior is implemented by Window Manager
III Escuela Internacional de Invierno en la UCI del 17 al 28 de f
On domingo, 17 de novembro de 2013 20:24:31, Oleg Shalnev wrote:
> To tell the truth I don't understand why there is no reaction on thi
> message.
> May be this problem is not a problem, or it's not interesting to the people
> in this list,
> or it's a well known feature, or my English is so bad an
On 11/17/2013 9:29 AM, Tomasz Siekierda wrote:
> On 17 November 2013 14:53, Tim Hoffmann wrote:
>> Are there any best practices for working with QSettings in larger
>> projects with many settings?
> I'm not claiming the ones I will list are "the best", but they do work
> quite well in several pro
On 17 November 2013 21:53, Tim Hoffmann wrote:
> Hi all,
>
> Are there any best practices for working with QSettings in larger
> projects with many settings?
>
> In particular:
> - How do you efficiently synchronize settings with widgets in an options
> dialog.
- How do you efficiently detect ch
On 17 November 2013 14:53, Tim Hoffmann wrote:
> Hi all,
Hi
> Are there any best practices for working with QSettings in larger
> projects with many settings?
I'm not claiming the ones I will list are "the best", but they do work
quite well in several projects I'm involved in.
> In particular:
Hello all again.
To tell the truth I don't understand why there is no reaction on thi
message.
May be this problem is not a problem, or it's not interesting to the people
in this list,
or it's a well known feature, or my English is so bad and poor.
I have no idea.
2013/11/14 Oleg Shalnev
> He
Hi all,
Are there any best practices for working with QSettings in larger
projects with many settings?
In particular:
- How do you efficiently synchronize settings with widgets in an options
dialog.
- How do you efficiently detect changes made in an option dialog. (I
have some options that nee
12 matches
Mail list logo
