PDA

View Full Version : Window size problem after Qt version update



Krachs
19th November 2014, 21:03
First off I have to say I a still very new at using Qt and I inherited all the applications I am working on.

I have been working on updating three applications from using Qt version 4.4.3 to 5.3 and these applications worked just fine before hand. These applications have two components as far a qt is concerned, a common library for Qt application widgets and a application layer that contains the specific widgets and other gui components for that application. Although the three application layer components are different there are structured in the same way and have a lot of duplicate code. So far I have managed to update the common library and two of the application layer components and they are working great, then there is the third application. I went through the exact same process as i did on the other two applications but for some reason I cannot get this one to start properly. The error i am getting is:

QWindowsWindow::setGeometry: Unable to set geometry 6186674x454+0+0 on QWidgetWindow/'lightPaneWindow'. Resulting geometry: 65519x454+0+0 (frame: 8, 30, 8, 8, custom margin: 0, 0, 0, 0, minimum size: 524297x454, maximum size: 16777215x16777215).

If the application were to open correctly it should result in a gui about 6x6 inches or so, but instead it seem to be trying to extent the width of the gui off into the horizon. While trying to debug this issue I have found that disabling the signals for one of the QComboBoxes in the application layer seems to allow the application to start correctly, or at least with the right dimensions.

Any help or guidance for this issue would be greatly appreciated.

wysota
19th November 2014, 22:12
Could you show connect() statements for those signals and body of the slots they are connected to?

Krachs
20th November 2014, 00:09
//TabInstr extends QWidget

//idRing is of a type the extends QComboBox
void TabInstr::createConnections(void)
{
connect(idRing, SIGNAL(currentIndexChanged(int)), this, SLOT(sendNewInst()));
connect(idRing, SIGNAL(currentIndexChanged(QString)), this, SLOT(updateInfoBox(QString)));

....

}

void TabInstr::sendNewInst()
{
QString temp = idRing->currentText();
emit instrChanged(temp);
return;
}

//instInfoMap is of type QMap
//infoBox is of a type that extends QLineEdit
void TabInstr::updateInfoBox(QString address)
{
infoBox->setText(instInfoMap[address]);
return;
}

//from generated moc file
// SIGNAL 0
void TabInstr::instrChanged(QString _t1)
{
void *_a[] = { 0, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) };
QMetaObject::activate(this, &staticMetaObject, 0, _a);
}



Is this what you are asking for?

when I comment out the two connect statements show the application is able to show its gui with normal dimensions.

wysota
20th November 2014, 00:56
How long are the entries in instInfoMap? What is the instrChanged() signal connected to? Does it help if you hide() infoBox widget?

Krachs
20th November 2014, 18:08
instInfoMap is of type QMap<QString, QString>
the key is always about 25 characters
the value is also always about 25 characters
instInfoMap contains about 6 entries

hiding the infoBox widget does not seem to help
I have tried hiding all the widgets that act as containers all the way up the chain from infoBox and short of not showing the main window nothing seem to help.

As for what the instrChanged() signal is connected to I followed it back to a function in the main application code. While stepping through this code something doesn't seem right. Let me look into it and get back to you. This might be the issue.

When I was tying to trace where the signal path ended I could not understand how Qt sets this up or how to trace the signal back. I was force to step through the qt code to see what functions were called. Can you explain what it is that I want to look at to understand how the signal are moving back up though the containers to the application window.

Krachs
20th November 2014, 20:53
To make a long story short I think i fixed my problem. In the end Qt was just doing what it was told.

The function i mentioned in my previous post contained another function call that took a QString and tried to convert it into a c_str. The implementation for this function was different from the other two applications that I converted successfully. This implementation assumed it was dealing with a unicode string, while the others implemented a generic conversion to a c_str. Needless to say the resulting string was junk after the conversion. This string was then used by a underlying driver for an attribute query, since the string used for the query was bad the driver call returned an error and the attribute's value was undefined. The return value for this call was never checked and the attribute's value was then used to calculate the size need for a QGridLayout and a widget.