I have my Main Dialog and some minor dialogs opened by buttons in Main.
I got object X of class ABC declared as a member of Main Dialog.
I want to edit (get and set values) object X from any dialog.
How can I do it? I read that it impossible to declare variable globally (tryed it in MyApp.h, or in MyApp class but there was linker error with redefinition)
The only solution that came to my main is to add to buttons:
CNewDialog newdialog;
newdialog.A=A;
newdialog.DoModal();
A=newdialog.A;
Will it work? Or is there any other solution?
On the other hand, there will be visible changes in Main Dialog only after closing newdialog and I don't want this.
I would use Common Configuration Facility designed using Singleton pattern to solve your task.
The main dialog object can be accessed from anywhere by calling AfxGetMainWnd. Cast the returned pointer into a pointer to your main dialog class.
Related
This is a very simple problem, but I could not find a solution to it. I have a dialog A, which when clicked a button opens another dialog B with a single edit box. I want to add an integer variable to it.
The usual way of adding variables which is right clicking the edit box and "add variable" is greyed out. I presume that it's because I haven't declared a separate class for the dialog, since the variable is used only in Dialog A code I don't want to add a separate class for Dialog B.
What should I do?
Thanks.
If you want to customise the behaviour of dialog B in any way (including adding variables for controls), you must declare a class for it.
You say that the variable is only used in dialog A code, but that doesn't mean that dialog A is the owner of that variable. Dialog B owns it, so dialog B needs a class.
I've got some code in my CMyView class. There I open a dialog with DoModal():
AnotherDialog dlg;
dlg.DoModal();
Now I want to automatically run a function. The poblem is, whenever I call dlg.DoModal(), the compiler waits till I close the Dialog window again, to continue running my code into the CMyView class. The function can also automatically be called into my AnotherDialog class.
Can anyone tell me, how I can automatically run a function whenever I open another Dialog?
AnotherDialog has a constructor, AnotherDialog::AnotherDialog(). Any function called from there will be called every time a dialog is created without providing arguments. If you add constructor overloads, each constructor can have different behavior, and it's up to you to make your code not confusing. (I.e. just be consistent)
If AnotherDialog is not your class, you may want to derive from it instead: class MyOtherDialog : public AnotherDialog. You can now have a MyOtherDialog::MyOtherDialog constructor which is called after AnotherDialog::AnotherDialog().
You could also add code to DoModal(), again in the existing class or a derived class.
The code in your view class is waiting because you are using the DoModal () method. By definition, DoModal is synchronous so it will wait for the dialog to close before continuing. Without knowing too much about your design, I would guess that you should use a "modeless" dialog invocation instead.
I've a document class which has an object which is a connection to a database. The document class has a dialog box which is spawned from a menu, which contains a combo box. I'm currently using OnInitDialog to set the items in the combo box but want to use the database connection.
What is the best way of supplying the database connection object to the Dialog box object?
I don't think I can pass it in as an argument, and if I supply it after construction, I might have missed the call to the OnInitDialog. Is there a way of finding the parent object and calling a getMethod to obtain the database object or am I on the wrong track altogether and should be attempting something completely different?
Thanks for your help,
James
Normally you would subclass the dialog to create a custom constructor which includes whatever objects you want to work on e.g. your database object.
You should pass the database connection object in the dialog's constructor. Modify the dialog constructor or add another constructor accordingly. You may declare other plain constructors of the dialog as private so passing on the db connection becomes a requirement for the dialog.
I am not sure about architecture you are referring i.e. Dialog box inside the document class but I think you can add a member variable for database connection inside dialog box class and then set the db connection varaible in your dialog box constructor or
dlg->dbConnection = dbConn; before calling DoModal or ShowWindow
it seems that whenever I try to "store" a qt dialog screen into a static variable the program crashes. (With a debug error complaining that a QPaintDevice can't be created before the QMainApplication).
As this error happened before the main was loop was entered I took it the problem was with the static variables. (Well and it was the only thing I added since last build).
Let me first try to explain how I use it. Basically I have an tree (origination from some external -xml- files). I wish to display data from that tree. However depending on the actual place in the tree the data has to be drawn differently. (Using completely different dialogs).
So what I started to create was a static map. This map holds as key the tree "location" ("regexified" to something like "a * c d" - spaces denote branching). And as value the correct dialog should be pointed to.
The first idea was to simply use pointers to dialog screens. (And then the function that looks up the variable simply executes the dialog screen). However this resulted into the error shown above.
Now I started using an intermediate proxy function, where the function just creates the dialog screen and calls it. And the static map just holds a pointer to this function. Something like:
int AskGUIFn::GenStd(const GMProject::pTree& tOut, const GMProject::pTree& tIn) const {
std::unique_ptr<MW::GenStd> box(new MW::GenStd(&tOut, &tIn));
return box->exec();
}
However this seems very verbose (not only do I have to create all the modal windows, but I have to add another proxy function for each dialog screen). Is there a cleaner way to do this? I'd like to prevent using proxy functions?
Static QWidgets are not possible - the QApplication object must be created before the QWidget. Also, the undefined initialization and destruction order of static variables would cause troubles. Also note that you should always pass a parent to a modal dialog in case you have other windows visible (e.g. a main window), otherwise window stacking will show annoying behavior on some platforms (modal dialogs behind disabled windows etc.). Like kenrogers I would suggest to use a factory function like:
QDialog* createDialogForNodeType( const QString& type, ...tree data, QWidget* parent );
I've used MFC dialogs before where you do:
EnterNameDlg dlg;
dlg.DoModal();
string str = dlg.GetName();
However a dialog I have now actually looks at a list-box control in such a method and it's not working. Although the class instance clearly exists after DoModal(), does the actual dialog get destroyed? I noticed calling DoModal() a 2nd time leads to OnInitDialog() also being called again which seems to support this theory, the dialog is recreated from the template rather than simply made visible the 2nd time.
Yes, DoModal creates a dialog on each call and destroys the window before returning.
Only the data members will still be valid. Of course, you can add more data members in your EnterNameDlg class if you want to collect data during dialog's lifetime.
As soon as the dlg gets out of scope, everything will be deallocated.
After DoModal class instance still exists, but window and all its controls are destroyed. You can call only functions that don't work with dialog controls after DoModal. Inside of the dialog class, keep required values in class members like CString, when OK button is pressed. These members can be read after dialog is closed.
The entirety of MFC is built around an awkward pairing - the Windows window with its associated handle, and the MFC class object. The MFC classes are designed to outlast the window in most cases.