Need a working example of promoting QWizardPage in Qt Designer

[ChrisW67]

In Designer you put a placeholder widget, generally of a similar type, in the space you want your custom widget to occupy. Then you tell Designer to "promote" that placeholder to another custom class. This has the effect of causing the UI compiler (uic) to generate code that creates (incarnates) the custom widget where it would otherwise have created the placeholder widget. From your description above you are already doing this. QWizard built this way would simply contain promoted placeholders for the pages.

Designer can be used to build the UI of the custom widget. This Designer UI is completely independent of any Designer UI that might eventually contain the custom widget. The implementation of the custom widget behaviours is done in C++ code not Designer.

[astodolski]

In Designer you put a placeholder widget, generally of a similar type, in the space you want your custom widget to occupy. Then you tell Designer to "promote" that placeholder to another custom class. This has the effect of causing the UI compiler (uic) to generate code that creates (incarnates) the custom widget where it would otherwise have created the placeholder widget. From your description above you are already doing this. QWizard built this way would simply contain promoted placeholders for the pages.

Designer can be used to build the UI of the custom widget. This Designer UI is completely independent of any Designer UI that might eventually contain the custom widget. The implementation of the custom widget behaviors is done in C++ code not Designer.

What's not clear then is how do you access objects created in the designer? That is, do you call it from the ui object or the objects created in the promoted classes? The promoted classes don't have scope into the ui object if you understand what I mean. I would have commented sooner but we just had a pretty bad hurricane hit us last week and now are in the middle of a snowy NorEaster.

[wysota]

All ui objects can be accessed through the wizard object (if you provide API for this of course) by casting the return value of QWizardPage::wizard() to your wizard class type. Furthermore you shouldn't need that since important fields can be registered by the wizard class and accessed from each page.

[astodolski]

All ui objects can be accessed through the wizard object (if you provide API for this of course) by casting the return value of QWizardPage::wizard() to your wizard class type. Furthermore you shouldn't need that since important fields can be registered by the wizard class and accessed from each page.

I'm sorry but that doesn't make sense to me. Let me explain. I have two pages in a wizard. I promoted both pages to their own separate classes. I now can override methods of each page like initializePage, nextId etc. So in PageOne::initializePage() I need to write to a label on that page. The only way to do that is by calling ui->labelOne which of course is not in scope. I am seeing that I have to promote each object in each page. But the alternate method you seem to suggest is to register those labels as a fields to be accessible. The question becomes accessible by the ui or by the promoted pages? Qt is quite a screwy paradigm for visual programming.

[wysota]

I'm sorry but that doesn't make sense to me.

Well... doing what you are doing doesn't make sense to me too.

Let me explain.

I understand what you are doing, there is nothing to explain.

So in PageOne::initializePage() I need to write to a label on that page. The only way to do that is by calling ui->labelOne which of course is not in scope.

No, that's not the only way. Your wizard is implemented as a subclass of QWizard that has the UI created in Designer applied on it. Therefore you can implement getters and setters for all the variables you need in this subclass. Or if you don't care about proper OOP, you can just make the wizard's "ui" member public instead of private.

But the alternate method you seem to suggest is to register those labels as a fields to be accessible. The question becomes accessible by the ui or by the promoted pages?

Both. See QWizard::field(). You just need to register all the fields first.

Qt is quite a screwy paradigm for visual programming.

No, you're just not using it in the way it was designed to be used.

[astodolski]

Well... doing what you are doing doesn't make sense to me too.


I understand what you are doing, there is nothing to explain.

You understand what I'm doing but it doesn't make sense? -- Hmm.

I admit I am not an expert in Qt. To the point of using it as designed. If you approach the designer to create a wizard with a number of pages, that is relatively easy to be successful. Works as designed. The other variants of creating wizards are just not well represented in the documentation or included examples. The other development environments by Microsoft and Borland share similar paradigms of creating graphical interfaces with code behind. Qt is very different.

Just trying to understand the way things work with Qt.

[wysota]

You understand what I'm doing but it doesn't make sense? -- Hmm.

Yes, exactly.

I admit I am not an expert in Qt.

Qt is not an issue here. Object oriented programming is. There is the object of the wizard that contains all the UI elements (as you chose to put them there in Designer). The wizard object also contains a number of page instances. Since the pages and UI elements are encapsulated in the wizard object, they are not aware of each other. One page can't access another page's items since it doesn't even know another page exists and it can't access the wizard's items since it doesn't know there is a wizard anywhere. In C++ (again, not anything related to Qt itself) you cannot inject code into existing classes therefore if you put some items in the wizard UI, its code cannot be injected into the classes you are externally creating. Again and again, this is nothing Qt-specific, it's simple object oriented programming.

If you really want to separate the logic of each page then do exactly that, extract the logic and not the page itself. Don't promote each page in Designer, instead create a couple of "algorithm" instances (working on the wizard class instance) in your wizard's constructor and when the wizard switches pages, assign the correct logic you want to be the "current" one. This way you follow both the "strategy" design pattern and the state machine paradigm. Both are standard, both are classic, no need to reinvent the wheel.

Qt is very different.

Qt follows object oriented programming paradigm. Borland is sh*t and M$ is always inventing its own "standards" that are incompatible with everyone else.

Just take a piece of paper and a pencil, draw each object and objects it encapsulates (which will visualize their access scope) and everything should become clear.