implementing a dynamic display

[mzimmers]

I'm getting requests to expand the functionality of the app I'm working on for a second customer. I'm thinking of creating a section of the UI specifically for this additional functionality, and making it visible/invisible depending on the target device that my app encounters on startup. Can anyone think of a reason I shouldn't do this?

[SGaist]

Hi,

Do you mean add new widgets per device ?

One thing against only one app is that it will become larger for your devices with code that doesn't even necessarily need to be present..

[mzimmers]

@SGaist hi Samuel - yes, that's what I mean. A point of clarification, though: when I used the term "target device," I was referring to a headless embedded system. My Qt app runs on a desktop or a laptop (or maybe a tablet).

It's a good point you bring up, though...I should try to keep size down. Are you suggesting something like conditional compilation?

[SGaist]

Can you describe your system a bit more ?

[mzimmers]

OK. My company makes various products used in VOIP and POS applications. Most of these products use very basic embedded systems, and I'm writing a host interface to one of them. This app performs basic status and control functions on the embedded devices, communicating with them via networking or a serial interface. The serial interface is intended only for a few operations, whereas the network interface is used for all operations.

My first job here was to write the serial interface app. It has probably about 20 widgets (not counting layouts) and is entirely contained within a single window that can be shrunk to 300x300 or so. The management would like to extend the use of this app to a second product we make. This second product involves additional security layers to configure. My plan was to determine the kind of embedded device we're talking to at host app startup, and configure the UI accordingly.

I'm also anticipating the eventual request for increasing the functionality considerably further, which will entail the need for tabs, or secondary (dialog) windows. So I'm trying to keep the app design relatively open.

I'd greatly prefer a single source base for this. Since the app's functionality will vary based on user and the target device, there could potentially be a lot of permutations, and I'd prefer not to branch the code for this if possible.

[SGaist]

So the serial port has a reduce set of possible interactions but they are all available through the network interface, correct ?

Are all your devices connected to both a serial port and the network when operated ?

[mzimmers]

@SGaist said in implementing a dynamic display:

So the serial port has a reduce set of possible interactions but they are all available through the network interface, correct ?
Correct.

Are all your devices connected to both a serial port and the network when operated ?

No. In fact, both connections are brief. The serial port functionality is used for preliminary configuration, either at the factory, or by an OEM technician. The network interface is used for diagnostics or for changing configurations.

[SGaist]

Ok, it's clearer, so in fact you could have a QListView with all of your available devices and then when you select it, you can show the "configuration" widget loaded with the information of that specific device.

[mzimmers]

Ahh...that sounds like a good idea. Might be overkill, but I'm willing to go with it.

So, before the main display is drawn, I'll have a preliminary display with which the user makes a product selection?

I've never worked with multiple windows before. Do I create a form analogous to that defined in my widget.ui file? And would this be in another .ui file?

[kshegunov]

Sorry to interject, but it's still not quite clear to me if you have a way to determine what kind of device you're connected to through either interface? Or are you supposed to chose that and then establish the connection?

Btw, I'd've put both type of interfaces in one application. It's a matter of designing the class hierarchy but you could in principle put it all - communication interfaces and application types - together and with abstract classes adding implementations should be rather easy. At a later stage you could even load the actual implementations on demand via plugins.

[mzimmers]

There may be multiple products (of varying types) on the network. The user needs to know which one, by product name, he wishes to access. When he chooses one, I can then determine what UI components to display.

[SGaist]

So indeed, a plugin based architecture might be best suited for that.

[tekojo]

Kind of an unrelated note.
It sounds like the application is for specialist use only. Can you go and ask one of the end users what they really want to do and in what order they would like to do it?

So the products broadcast or reply to a broadcast on the network, so they can be identified? This would make it much easier for the network case.

From the architecture side, a plugin approach makes most sense, especially as you expect future additions and changes.

[mzimmers]

@tekojo I wish I could poll the user community on this matter -- I always like hearing from end-users before implementing an app. Unfortunately that option isn't available to me at this time.

Regarding using plugins: that might be overkill, given that there are only two levels of user access, and only a few levels of app functionality. I also need to be concerned with distribution, and I'm not really familiar with plugins, but a plugin exists in a separate file, right? So can I still do a static build to create a monolithic distribution entity?

[mzimmers]

I've decided to implement the additional fields using a QDialog object. I created a second form for this dialog, but then realized I don't know how to access this form programmatically. Can someone point me to some directions on this? I've done some looking but haven't found anything that tells me how to connect up a second form.

Clarification: I know that I want the form to be enabled when a button push delivers a signal, but I don't know how to "point to" this form programatically. I hope this makes sense; I've been struggling to find the right words to explain what I'm looking for.

Thanks...

[SGaist]

You usually subclass QDialog and give it the necessary API to access what you want. Depending on what you want to add, you can also simply hide what should not be used.

[mzimmers]

@SGaist so each form would then have its own subclass?

[SGaist]

Just to be sure we are talking about the same thing, what do you mean by form ?

[mzimmers]

@SGaist by "form" I mean an entry under "Forms" in the project file; ie, a file with a .ui extension that is generated by Designer.

[SGaist]

Then that's the most common use case. You create as many "Forms" you need and give them the API you need.

[mzimmers]

I see. So, when I created this project, I selected Qt Widgets Application, and Creator automatically set up the form and the class for me. Should I use that class as a model for my new form?

I still don't quite understand how the program "knows" to use the .ui file. I don't see the connection anywhere in my code.

[SGaist]

It's just a starting point. Nothing forbids you to have several forms.

The .uil file is processed by uic to generate code (a bit like moc for QObject based classes) then the ui.setupUi(this); line does the "magic" to setup everything you prepared with Designer.

[mzimmers]

I've tried to implement a new class (patterned after my main form)...obviously I don't understand something.

Here's the header:

#ifndef CREDENTIALS_H
#define CREDENTIALS_H

#include <QWidget>

namespace Ui
{
    class Credentials;
}
class Credentials : public QWidget
{
    Q_OBJECT
public:
    explicit Credentials(QWidget *parent = nullptr);
private:
    Ui::Credentials *uiCredentials;
};

#endif // CREDENTIALS_H

and here's the source:

#include "credentials.h"
#include "ui_credentials.h"

Credentials::Credentials(QWidget *parent)
    : QWidget(parent),
      uiCredentials(new Ui::Credentials)

{
    uiCredentials->setupUi(this);
}

I'm getting an error "invalid use of incomplete type 'class Ui::Credentials'. Why is it incomplete?

[kshegunov]

#include "ui_credentials_form_file_name.h"

[mzimmers]

I think I'm already doing that -- in the source file:

#include "credentials.h"
 ***** #include "ui_credentials.h" *****
Credentials::Credentials(QWidget *parent)

[SGaist]

Did you re-run qmake after adding your new form ?

[mzimmers]

@SGaist Yes. (I just tried it again to be sure.) I even did a clean/qmake/build...same results.

[kshegunov]

And is the root object of your form called "Credentials" (look for it when you open the form in the designer - in the right, in the object tree the first object's name)?

[mzimmers]

Aha! That did the trick. Thanks, kshegunov. It was simply called "Dialog."

So, the step I missed was matching the name of the top-level object created in Designer with the new class I created manually to support it. I looked past this because the first form (and its supporting class) was created automatically when I started the project.

Thanks again.

[mrjj]

@mzimmers
Hi
Just as a note. you can add as many forms as you like and
have them auto created like mainwindow is.

It sounds you manually created Credentials ?

To get a new form, simply right click top of project, select "Add new" and then

In next window, you can choose if it should be MainWindow, Dialog or Widget.

This way you get .ui, cpp and h all ready to go.

maybe i misunderstood but just in case :)

[mzimmers]

@mrjj oh, that's good to know about. I looked right past that and just created the form from the line below. Thanks, mrjj...I'll remember that for the (not so distant) future.

[mrjj]

@mzimmers
Ah, yep that gives you just the ui file which is useful for hooking somes some interface up
with existing code. But not so much for a brand new window/dialog. :)

[MRen]

Just as a note. you can add as many forms as you like and
have them auto created like mainwindow is.

P.s.:Hi