Cannot access form - incoplete type - again
-
I did deleted // private , but still getting an error accessing the "UI::Common_Dialog"
What am I missing ?
public: explicit Common_Dialog(QWidget *parent = nullptr); ~Common_Dialog(); //private: Ui::Common_Dialog *ui;
-
You should usually not access the ui member directly from outside its class. That member is sort of an implementation detail and should be kept private. You would have to include the generated ui_common_dialog.h header for that to work, but that's extremely ugly, as you'd be exposing internal class stuff to the outside.
The proper way to do it is to create a setter method in your class that will do the appending e.g.
Common_Dialog::append(const QString& stuff).Btw. Are you deleting that dialog anywhere? Because it looks like you're leaking memory.
-
You should usually not access the ui member directly from outside its class. That member is sort of an implementation detail and should be kept private. You would have to include the generated ui_common_dialog.h header for that to work, but that's extremely ugly, as you'd be exposing internal class stuff to the outside.
The proper way to do it is to create a setter method in your class that will do the appending e.g.
Common_Dialog::append(const QString& stuff).Btw. Are you deleting that dialog anywhere? Because it looks like you're leaking memory.
@Chris-Kawa You have a good point as far as me removing the "private".... But if the object is used as a library why would it be "private" ? But that is probably wrong way to interpret "private ".
BTW these are "pop-up" dialogs and I will make sure they do not leak memory. -
"private" keyword means private in context of the class, not library. Encapsulation can take place on different levels - classes don't expose their internals to other classes, libraries don't expose their internals to other libraries, processes don't expose their internals to other processes, your computer doesn't expose its internals to other computers etc.
It's a good practice to minimize the interface of a class (the part that is visible to other classes). It's good for minimizing dependencies (like that include that you would need otherwise), good for maintenance (changes are more local), good for readability (user of that class doesn't need to worry what the heck is that ui stuff) etc. From conceptual point of view, looking at it from the outside, to append something to a list you don't need to know that there is a member ui that is the implementation of a ui compiler tool. You just care about appending, so that's what the interface of the class should be - an "append" method. The access to the ui member is an implementation detail and should be encapsulated within the class implementation. It's the "need to know" rule.
