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 );
Related
I am working on a Windows application using MFC and Visual Studio C++ 17.
I have multiple tabs in the application, one of which is currently implemented using CListBox and needs to be reimplemented using CCheckListBox.
CCheckListBox is a child class of CListBox.
I have a vector of unique CString's I want to display in the box.
To start simple, I tried making the tab with CListBox and by using CListBox::AddString(), this worked exactly as I wanted it to. It sorted the strings alphabetically, and automatically added a scroll bar on the side when the vector had too many CString's to display all at once in the list.
However, when swapping the CListBox variable to a CCheckListBox variable, I have come across the error when I press run along the lines of:
Debug Assertion Failed! ..... \mfc\winctrl3.cpp Line: 588
I found this GitHub link that has the winctrl3.cpp file and on line 588, there is a function called OnLButtonDblClk which is somewhat explained here.
The trouble is I am unsure of how to swap a variable from a parent class to a child class. Is it so different for Windows classes? In the courses and programs I have taken and written in the past, switching from a parent to child variable was straightforward but this is quite the opposite !
Any help is appreciated, thank you in advance ! :D
There is no assertion in line 588 of the source file in your link. That github upload dates back to 2014. Why not search the winctrl3.cpp source file in your own Visual Studio installation instead? In my own installation, it is in function PreSubclassWindow() and there is indeed an assertion there:
// CCheckListBoxes must be owner drawn
ASSERT(GetStyle() & (LBS_OWNERDRAWFIXED | LBS_OWNERDRAWVARIABLE));
That is the CCheckListBox must be owner-drawn. Find the CCheckListBox constructor code above, you will notice that it calls the CListBox (parent-class) constructor, applying either of the two owner-drawn styles. Instead, the CListBox constructor calls CWnd::Create() with the "LISTBOX" Windows Class-Name as a parameter. That is, it seems to be a MFC-implemented control, overriding the CListBox class, with an owner-drawn style. There is no mention of a native "Check-ListBox" class or style in the Win32 documentation either. Also the CCheckListBox documentation (in the link you posted) clearly states: CCheckListBox is only for owner-drawn controls because the list contains more than text strings.
Therefore:
If you are creating the control using a resource script, add an owner-drawn style (eg LBS_OWNERDRAWFIXED) to the control (or set the Owner-Drawn property in the property editor).
If you are creating the control programmatically make sure you are calling the CCheckListBox constructor, not the CListBox one.
Not sure what you mean about the scroll-bar (and why you mention it), doesn't the list-box display a scroll-bar automatically (WS_VSCROLL style - or property), do you have to do something on your own?
EDIT:
Forgot to mention, if you are creating the control using a resource script use the Class Wizard to add a member variable (of "Control" type, not "Value") to the dialog class. The new variable must be of type CCheckListBox (MFC class). This will subclass the control. If the old project already had a CListBox member variable change it to CCheckListBox.
this is my first question on this website, but I will try to cover everything that is needed. Apologies if I forgot something. I encountered the problem using QT Creator, but I suppose it would be the same using Visual Studio, or just C++ in general.
I've got a couple of classes: Mainwindow, Track and AddForm. Mainwindow is what it is called. The main form. Track is a custom class based on QObject which contains just a single QString variable (just for now, since I am still experimenting with QT). And AddForm is a class for another form that can be created by clicking a button in my MainWindow form. That form only contains a single line-edit to fill the string and a button that says "Add". Whenever that button is pressed the text from the line-edit will be put into the QString variable from the Track-class. That QString variable is called "artist".
Apart from assigning the text from the line-edit to the variable "artist" for the Track-object, the form will also emit a signal that sends that entire object. A slot within my mainwindow will react to that signal and collect the Track-object. So far so good.
Here is my question. Within my mainwindow-header I have created a private QVector named trackVector, which I can then call within my mainwindow.cpp. What I want to do is append / push_back the QVector with that Track-object. Sort of like this:
trackVector.push_back(trackObject);
I get the following error message when building the application:
click here for a screenshot
Now ofcourse with an integer or any other variable this is very straightforward. You would just do something like this I suppose:
QVector<int> myVector;
myVector.push_back(3);
I think that whenever you append a QVector (or a standard non-QT vector) you need to do so with the constructor of that class. But how can I make a constructor in which you can just put an already existing object?
Please explain with as much simple words as possible since I am no native English speaker :) Thanks a lot in advance!
You've posted insufficient code (so your post is liable to be closed as off topic -- a classical beginners error on SO), but I guess the appropriate solution here is to use some auto pointer type. If your TrackVector is to keep ownership of the Track objects, then the best solution is have std::unique_ptr<Track> elements:
std::vector<std::unique_ptr<Track>> TrackVector;
// filled like
TrackVector.emplace_back(new Track(args));
If, on the other hand ownership lies somewhere else, you may either use std::shared_ptr or even raw pointers (provided your layout guarantees that the pointed to Track objects' lifetime exceeds that of the TrackVector).
I'm currently starting to learn how to use C++ Builder. However, I'm stuck on doing something basic, which is to open a window when I click on an element of the menu. I'm ok with the event management, but when I try to display it with the method Show(), it's written when compiling that "the method is not reachable" (I have it in french so I'm not sure about the exact translation). I've tried it different ways, also with the popup element, but I always get this message. Here is the short code that I use to display the window :
TFrame1 * NewPageFormer = new TFrame1(this);
NewPageFormer->Show();
delete NewPageFormer;
NewPageFormer = NULL;
Do you have any idea where the problem comes from?
Thank you
Try with:
TForm1 * NewPageFormer = new TForm1(this);
NewPageFormer->Show();
What you should Show() is a TForm (e.g. take a look at How do I open a new form with a button, using C++ Builder?).
Frames are combinations of components placed on a form-like object, which are considered a cohesive whole.
A frame (TFrame), like a form, is a container for other components. It uses the same ownership mechanism as forms for automatic instantiation and destruction of the components on it, and the same parent-child relationships for synchronization of component properties.
However a frame is more like a customized component than a form, so you cannot directly call the Show() method of a frame.
I should find another interest because this one is taking the life out of me quickly. Seems like a lot of people are confused about the intricacies of MFC code, including me. I have an MFC Dialog Box application that creates several dialogs that you navigate to using the typical back or next function. Along the way you collect data via radio group buttons, list boxes and various other controls. For the most part I understand how to get a handle on the data by using the m_ variables provided by the AFX maps throughout the code for each distinct dialog. At the end - and sometimes during - the data collection/selection process gathered by dialogs, I need to do things with what has been collected. I may need to take the data from one dialog and modify the next based on the previous. It seems like when you move through the dialogs the data from the last is lost unless you save it somehow. I know that there are dozens of ways to do this and I have toyed with several of them, from object passing, to creating new classes, new structures, global variables, pointers, whatever.... My concern is, I need a data structure of some sort to stay up and active in memory long enough for my user code to do something with it. That is the problem I think, I don't know in MFC how to deal with this. I have currently decided to go with a struct called dlg_DataHandler (to house collected data from each dialog) with a few test members in a .h file. It has been typedef'd as a pointer. I am creating a variable of this type and setting it = new dlg_DataHandler, but the data isn't getting passed around like I want from dialog to dialog. One thing that I wonder about is, I don't know exactly where to place the "new" statement for creating the variable. Its as if data is not flowing to and from the structure as it should. Anyway here is some of the code:
// file1.h
typedef struct dlg_DataHandler {
int var;
char* String;
int RepetitionRadio; // radio button data
constructor here
} *dlgDataHandler;
extern dlgDataHandler DlgData;
//*****************
// file2.cpp
dlg_DataHandler DlgData = new dlg_DataHandler; // not located anywhere in peticular just in the code since I DON'T KNOW where to put it. DlgData->member gets loaded in the dialog .cpp files to try collect data, but it doesnt seem to be passing data across the different windows.
Put the variable in your main application class (the one derived from CWinApp) and call new in InitInstance(). You can then use AfxGetApp() to gain access to the application instance, and so your variable, from anywhere else in the code.
i can't understand what's the benefit of setting parent for a QMessageBox, for instance in the following code:
void mainWindow::showMessage(QString msg) {
QMesageBox::information(this, "title", msg); //'this' is parent
}
can somebody help me ?
Probably a few things. First of all QMessageBox inherits from QDialog. Since QDialog has a concept of a parent, QMessageBox should too for consistency.
Specifically, the documentation says:
parent is passed to the QDialog constructor.
At the very least, a new dialog is often displayed centered in top of its parent.
However, there is more!
According to the documentation it can effect actually functionality. For example:
On Mac OS X, if you want your message box to appear as a Qt::Sheet of
its parent, set the message box's window modality to Qt::WindowModal
or use open(). Otherwise, the message box will be a standard dialog.
Also, there is a concept of both "Window Modality" and "Application Modality", where the former only prevents input in the parent window, the latter prevents input for the whole application. This obviously requires the concept of a parent to be known.
Finally, for certain static functions such as ::about(...), the first place it looks for an icon to use is parent->icon().
So, if you want to get nice platform specific behavior and have your code be cross platform, you are better off passing a sane parent to it.
The parent-child hierarchy of dialogs defines the window stacking behavior in the various platforms. If you pass dialog P as parent of dialog C, C will appear above P on all (desktop) platforms. If you pass 0, the window stacking will differ and usually not behave as wanted. The worst such issues I've seen on OS X, where some message boxes showed up behind the main window, which was disabled as the message boxes being modal, without any way to get to the message box (neither shortcuts nor moving windows via mouse helped).
In short, my suggestion: always pass a sensible parent.
The other answers are probably better, but my own little reason is that it puts the message box at the centre of the parent instead of the centre of the screen...
Don't forget to mention that QMessageBox will inherit of the palette and the style-sheets of its parent. Believe me when you use custom complex style-sheets you don't want you message to pop like they doesn't belong to your application ...
It is also useful for memory management if you don't use static functions, but actually create an instance of QMessageBox. When the parent is deleted your instance will be deleted too.