You are not logged in.

Dear visitor, welcome to KDE-Forum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

DexterMagnific

Unregistered

1

Tuesday, April 27th 2004, 9:05am

Dialog construction strategy

Hi,

Is it preferable to call the dialogs' constructors each time the dialog is accessed or constructing all the dialogs at init time of the app and only showing them ?

e8johan

Beginner

Posts: 27

Location: Sweden

  • Send private message

2

Tuesday, April 27th 2004, 10:45am

RE: Dialog construction strategy

It all depends on how you are planning to use them. If you just pop it up and then gather the data from a single function I would prefer to create it and delete it each time.

axeljaeger

Beginner

Posts: 10

Location: Frankfurt Germany

Occupation: Student

  • Send private message

3

Tuesday, April 27th 2004, 1:57pm

I have two different strategies: For certain dialogs I use a static function to show them for example in my custem QFileDialog. These dialogs are created in the static function and they are deleted after use. I create other dialogs for example a settings window in demand: I set them to null in the constructor and check before showing the dialog if the pointer is still null: If yes I create the dialog, if no I show the already cerated dialog. This is the recommend strategy for Qt/Embedd to gain some startup performance but I think startup performance is also not bad on desktoop systems. From http://doc.trolltech.com/3.3/emb-performance.html#general :

Quoted


Create dialogs and widgets once, then QWidget::hide() and QWidget::show() them, rather than creating them and deleting them every time they are needed. This will use a little more memory, but will be much faster. Try to create them the first time "lazily" to avoid slow startup (e.g. only create a Find dialog the first time the user invokes it).
It's nice to be important but it's more important to be nice