General and Desktop

Class name and object name can be the same, it does not matter. You can see, whether the streamList is in the child list at all: @ foreach(const QObject *obj, this->children()) { qDebug() << obj; } @ Check if the streamList is in the debug output.

The query may not be executed in the transaction, I would suppose, probably depending on the driver.

The table implicitly has a selction model, get with <code>tableView->selectionModel()</code>, you don't need to create a new one.

Tank you for a quick answer peppe. @m_lblImage = new QLabel(centralWidget);@ @ m_lblImage->setObjectName(QString::fromUtf8("m_lblImage"));@ i forgot to declare something thats right, i looked and looked, but i think it was to late, and after some sleep i found it. i have written @m_ilblImage = new QLabel(centralWidget);@ and that dons't work out ;)

Actually I was looking at possible structure as mentioned here "Parallel structure":http://easycsm.sourceforge.net/SM_5.png .

If you want to "connect the dots", so to speak, why did you decide to use an ellipse, rather than a line segment?

Thank you for all the feedback: Some more information: Clarification: I understand that the signals from one widget come in the order of the connect statements but as Andre correctly stated, my problem relates to single signals from multiple widgets. Motivation: the problem typically appears when a edit control needs to do some computations when the focus is lost and the results are shown in another field. In this case "our" program logic expects that those computations are already done (during focus lost) before we process the push button (click). [quote author="Andre" date="1324461511"]Perhaps you can avoid any depence on this order, if you use QApplication::focusChanged instead of relying on the order. However, this signal (this is a signal) is send only after both widgets have already been send the FocusEvent. [/quote] I absolutely agree that this should be the way to go and this is also what we generally try to do but especially when there are complex relationships between the edit fields (stuff like default values that need to calculated from others fields but can later be changed by the user) this gets really complicated. Some questions that might help to better understand: 2.1) What should setting the focus policy of a QWidget as a main window for other controls do ? 2.2) When and why should the focus policy been changed in general ? 2.3) Is there any sequence of signals/events that we can rely on in Qt or is it just "random" ?

Hm, this hack is exactly what I was trying not to do. It might work, though. Thanks, Andre!

it's about setVersion: [quote author="http://developer.qt.nokia.com/doc/qt-4.8/QGLFormat.html" date="0"] Set the OpenGL version to the major and minor numbers. If a context compatible with the requested OpenGL version cannot be created, a context compatible with version 1.x is created instead. [/quote]

If you put together a minimal testcase you could submit a bug report, although I'm not sure you're in a supported case there (cf. [[doc:moc]] limitations).

hello Andre thanks a lot... now i am able to display progress bar with two different colors at a time using style sheets. @ progress->setStyleSheet(QString("QProgressBar::chunk:horizontal {background: qlineargradient(x1: 0, y1: 0.5, x2: 1, y2: 0.5, stop: 0 grey, stop: 1 grey);}")+QString("QProgressBar::horizontal {border: 1px solid gray; border-radius: 3px; background: yellow; padding: 0px; text-align: left; margin-right: 4ex;}")); @

Thanks a lot for all of u...:) i did like this @ std::cout<<"the first word of the line :"<<line.at(0).toAscii()<<endl; @

solved. I have to add another qmake location to the options in qt designer

Ah, peppe, I see. I guess you don't even have to subclass the view - it works something like this: http://programmingexamples.net/wiki/Qt/ModelView/ListViewComboBox

use regsvr32 to register the dll on the command line/batch file also check if you have the Qt dlls in the same directory as the com-dll so the com server can be executed

Thanks a lot! Both problems have been solved :)

No, C is a valid locale. Basically it is "use no translation at all". Check the environment you are running your application in for the LC_* and LANG variables. Maybe something is forcing them to C. We do that in Qt Creator sometimes when we need to make sure to get parse-able output from the applications we run (e.g. the compiler).

I had the same problem. Olorin's code worked for me. Thanks for the follow up.