Qt-interest Archive, October 2006
running out of Windows handles
Pages: Prev | 1 | 2 | Next
Message 1 in thread
If my application runs out of Windows handles everything starts to
flicker until I kill the process. very disconcerting for the user. I
would like it to handle this situation more gracefully, but I am not
sure of the best way. I can't find anything in qt-interest or the
documentation.
Is there some way to trap this? It doesn't cause a Windows exception and
I assume it doesn't cause a C++ exception either. Testing the winId() of
every widget created isn't practical.
thanks in advance
Andy Brice
--
[ signature omitted ]
Message 2 in thread
Andy,
I had the same problem a little while ago, see thread "QTable and setCell" from
august this year. I also discussed it with Trolltech and they are not providing
a solution for it, they advised me to paint the non active cells by myself. The
discussion with Trolltech has been recorded as issue N124911 (ATable and setCell
problem).
The problem has to do with the maximum number of User objects, I found in the
Microsoft Knowledge base an article how to increase the number of user objects
(KB 326591). The possible increase was in my case insufficient. If you find a
solution how to signal the problem I'm very much interested.
Regards,
Albert van der Meer
Andy Brice wrote:
> If my application runs out of Windows handles everything starts to
> flicker until I kill the process. very disconcerting for the user. I
> would like it to handle this situation more gracefully, but I am not
> sure of the best way. I can't find anything in qt-interest or the
> documentation.
>
> Is there some way to trap this? It doesn't cause a Windows exception and
> I assume it doesn't cause a C++ exception either. Testing the winId() of
> every widget created isn't practical.
>
> thanks in advance
>
> Andy Brice
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
--
[ signature omitted ]
Message 3 in thread
Albert van der Meer wrote:
> Andy,
>
> I had the same problem a little while ago, see thread "QTable and
> setCell" from august this year. I also discussed it with Trolltech and
> they are not providing a solution for it, they advised me to paint the
> non active cells by myself. The discussion with Trolltech has been
> recorded as issue N124911 (ATable and setCell problem).
> The problem has to do with the maximum number of User objects, I found
> in the Microsoft Knowledge base an article how to increase the number of
> user objects (KB 326591). The possible increase was in my case
> insufficient. If you find a solution how to signal the problem I'm very
> much interested.
Albert,
I get the same behaviour (flicker, infinite loop, widgets appearing at
top left). But in this case the problem is other apps (such as FireFox)
using up all the handles, so it isn't a Qt bug.
Have you considered only displaying widgets in the QTable when the user
clicks on that cell? - thats what I do.
best regards
Andy Brice
--
[ signature omitted ]
Message 4 in thread
Andy,
That is more or less the suggestion Trolltech made, I want always be able to see
the content of the widgets /cell. I've not yet had the time to implement it (I
have to dive into the matter deeper and find an example on how to paint the cell
by myself).
Ok, I see the real problem is thus that other applications get to many handles
and none )or insufficient) are left for Qt. The KB article gives a small relief
(10000 -> 18000) but you will always hit the barrier again.
regards,
Albert
Andy Brice wrote:
> Albert van der Meer wrote:
>
>> Andy,
>>
>> I had the same problem a little while ago, see thread "QTable and
>> setCell" from august this year. I also discussed it with Trolltech and
>> they are not providing a solution for it, they advised me to paint the
>> non active cells by myself. The discussion with Trolltech has been
>> recorded as issue N124911 (ATable and setCell problem).
>> The problem has to do with the maximum number of User objects, I found
>> in the Microsoft Knowledge base an article how to increase the number
>> of user objects (KB 326591). The possible increase was in my case
>> insufficient. If you find a solution how to signal the problem I'm
>> very much interested.
>
>
> Albert,
>
> I get the same behaviour (flicker, infinite loop, widgets appearing at
> top left). But in this case the problem is other apps (such as FireFox)
> using up all the handles, so it isn't a Qt bug.
>
> Have you considered only displaying widgets in the QTable when the user
> clicks on that cell? - thats what I do.
>
> best regards
>
> Andy Brice
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
--
[ signature omitted ]
Message 5 in thread
Albert van der Meer wrote:
> That is more or less the suggestion Trolltech made, I want always be able to see
> the content of the widgets /cell. I've not yet had the time to implement it (I
> have to dive into the matter deeper and find an example on how to paint the cell
> by myself).
When not editing the cell a static display (i.e. a pixmap)
of a snapshot of the widget's contents might suffice...
Andre'
--
[ signature omitted ]
Message 6 in thread
André,
Nice suggestion, but the data is not static so I have to make pixmaps from all
cells and then display them. Or do I miss the clue ?
Albert
André Pönitz wrote:
> Albert van der Meer wrote:
>
>>That is more or less the suggestion Trolltech made, I want always be able to see
>>the content of the widgets /cell. I've not yet had the time to implement it (I
>>have to dive into the matter deeper and find an example on how to paint the cell
>>by myself).
>
>
> When not editing the cell a static display (i.e. a pixmap)
> of a snapshot of the widget's contents might suffice...
>
> Andre'
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
--
[ signature omitted ]
Message 7 in thread
> Nice suggestion, but the data is not static so I have to make pixmaps from all
> cells and then display them. Or do I miss the clue ?
I missed the beginning of the thread (got unsubscribe twice from
the mailing list and am too lazy/underpowered to use the web access...)
but it appeared to me that the handles you ran out of are the widget
itself (one per cell) including their children.
Replacing the 'inactive' widgets with pixmap should at least get
rid of the child widget handles.
If not, I could even imagine a custom delegate storing enough
imformation for a mock display without using any system handles
at all.
Andre'
--
[ signature omitted ]
Message 8 in thread
There is no need to use pixmaps to draw cells, infact the QStyle system
is made to solve this exact scaling issue. You can draw fake widgets
like this (Qt4 code. Qt3's concept is similar, but not syntax)
QStyleOptionComboBox opts;
opts.rect = someRect;
opts.palette = somePalette;
opts.state = QStyle::State_Enabled ;
opts.editable = true;
opts........
QApplication::style().drawComplexControl(QStyle::CC_ComboBox, opts,
somePainter, NULL); <qstyle.html#drawComplexControl>
Considering this is the exact same code that the QComboBox uses to draw
there will be no visual or performance issues and you will have massive
gains in cutting widget count and cutting memory usage.
--Justin
André Pönitz wrote:
>> Nice suggestion, but the data is not static so I have to make pixmaps from all
>> cells and then display them. Or do I miss the clue ?
>>
>
> I missed the beginning of the thread (got unsubscribe twice from
> the mailing list and am too lazy/underpowered to use the web access...)
> but it appeared to me that the handles you ran out of are the widget
> itself (one per cell) including their children.
>
> Replacing the 'inactive' widgets with pixmap should at least get
> rid of the child widget handles.
>
> If not, I could even imagine a custom delegate storing enough
> imformation for a mock display without using any system handles
> at all.
>
> Andre'
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:(ICS) Integrated Computer Solutions ;Engineering
adr:;;54B Middlesex Turnpike;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Senior Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
x-mozilla-html:FALSE
url:http://www.ics.com
version:2.1
end:vcard
Message 9 in thread
Justin Noel wrote:
> There is no need to use pixmaps to draw cells, infact the QStyle system
> is made to solve this exact scaling issue. You can draw fake widgets
> like this (Qt4 code. Qt3's concept is similar, but not syntax)
>
> QStyleOptionComboBox opts;
> opts.rect = someRect;
> opts.palette = somePalette;
> opts.state = QStyle::State_Enabled ;
> opts.editable = true;
> opts........
> QApplication::style().drawComplexControl(QStyle::CC_ComboBox, opts,
> somePainter, NULL); <qstyle.html#drawComplexControl>
>
> Considering this is the exact same code that the QComboBox uses to draw
> there will be no visual or performance issues and you will have massive
> gains in cutting widget count and cutting memory usage.
I don't think this works equally easy with widgets with 'real' children
(and layouts...)
Of course, I don' know what the OP actually needs, so the style
approach might be completely sufficient.
Andre'
--
[ signature omitted ]
Message 10 in thread
André Pönitz wrote:
> Justin Noel wrote:
>> There is no need to use pixmaps to draw cells, infact the QStyle system
>> is made to solve this exact scaling issue. You can draw fake widgets
>> like this (Qt4 code. Qt3's concept is similar, but not syntax)
>>
>> QStyleOptionComboBox opts;
>> opts.rect = someRect;
>> opts.palette = somePalette;
>> opts.state = QStyle::State_Enabled ;
>> opts.editable = true;
>> opts........
>> QApplication::style().drawComplexControl(QStyle::CC_ComboBox, opts,
>> somePainter, NULL); <qstyle.html#drawComplexControl>
>>
>> Considering this is the exact same code that the QComboBox uses to draw
>> there will be no visual or performance issues and you will have massive
>> gains in cutting widget count and cutting memory usage.
>
> I don't think this works equally easy with widgets with 'real' children
> (and layouts...)
It also doesn't work with sliders. I tried doing this once and it
crashed, because the style code expected a QWidget pointer to the slider
which I didn't have.
I'm wondering why the OP needs to SHOW widgets, and not just the text
values, unless they are graphical in nature.
--
[ signature omitted ]
Message 11 in thread
Albert van der Meer wrote:
> If you find a solution how to signal the problem I'm very
> much interested.
This appears to work:
bool
MyApplication::notify( QObject* receiver, QEvent* e )
{
if ( e->type() == QEvent::Show && receiver &&
receiver->isWidgetType() )
{
if ( ( (QWidget*)receiver )->winId() == 0 )
myMainWin()->handleInsufficientResources();
}
return QApplication::notify( receiver, e );
}
handleInsufficientResources() displays a QMessageBox that was created
(but not shown) very early on, hopefully before we ran out of handles,
and then exits.
best regards
Andy Brice
--
[ signature omitted ]
Message 12 in thread
Andy,
Thank you for thii I'm gone see if I can incorporatte this into my application.
Regards,
ALbert
Andy Brice wrote:
> Albert van der Meer wrote:
>
>> If you find a solution how to signal the problem I'm very much
>> interested.
>
>
> This appears to work:
>
> bool
> MyApplication::notify( QObject* receiver, QEvent* e )
> {
> if ( e->type() == QEvent::Show && receiver &&
> receiver->isWidgetType() )
> {
> if ( ( (QWidget*)receiver )->winId() == 0 )
> myMainWin()->handleInsufficientResources();
> }
> return QApplication::notify( receiver, e );
> }
>
> handleInsufficientResources() displays a QMessageBox that was created
> (but not shown) very early on, hopefully before we ran out of handles,
> and then exits.
>
> best regards
>
> Andy Brice
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
--
[ signature omitted ]
Message 13 in thread
Andy Brice wrote:
> If my application runs out of Windows handles everything starts to
> flicker until I kill the process. very disconcerting for the user. I
> would like it to handle this situation more gracefully, but I am not
> sure of the best way. I can't find anything in qt-interest or the
> documentation.
Perhaps it sounds as a matter of course - but maybe a redesign of your
application might turn out to be the best solution. I've done it with my
current project for exactly the same reason.
Of course, you have to pay for everything. To my design the simple
relationship between data and widgets (1:1) has been replaced by some
n:1 variant, introducing additional complexity regarding the maintenance
of the widgets state (switching depending on underlying data, pretty
non-trivial for user-editable widgets).
Micha
--
[ signature omitted ]
Message 14 in thread
We had a similar problem a few weeks ago. It turned out that our application
was not properly deleting Qt objects that we replaced (changed menu items in
our case). Once we properly deleted objects we were no longer using, the
problem went away.
The basic rule is to clean up after yourself. :) If you are done with an
object or replacing it with a new one, delete it and zero the pointer to it
before putting a new object in its place.
Keith
On 10-16-2006 1:40 AM, "Andy Brice" wrote:
> If my application runs out of Windows handles everything starts to
> flicker until I kill the process. very disconcerting for the user. I
> would like it to handle this situation more gracefully, but I am not
> sure of the best way. I can't find anything in qt-interest or the
> documentation.
>
> Is there some way to trap this? It doesn't cause a Windows exception and
> I assume it doesn't cause a C++ exception either. Testing the winId() of
> every widget created isn't practical.
>
> thanks in advance
>
> Andy Brice
--
[ signature omitted ]
Message 15 in thread
Keith Esau wrote:
> We had a similar problem a few weeks ago. It turned out that our application
> was not properly deleting Qt objects that we replaced (changed menu items in
> our case). Once we properly deleted objects we were no longer using, the
> problem went away.
>
> The basic rule is to clean up after yourself. :) If you are done with an
> object or replacing it with a new one, delete it and zero the pointer to it
> before putting a new object in its place.
Its not my application that is using up the handles.
I just want a way to cope gracefully when other apps have used them all.
Currently on my machine FireFox and Norton antui-virus are using over
3000 handles *each*.
best regards
Andy Brice
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
