[Interest] Making screenshot of a primary screen. Qt 4.8.4, openSUSE 12.3
Hello, the code below makes a screenshot of all screens QPixmap http://harmattan-dev.nokia.com/docs/library/html/qt4/qpixmap.html::grabWindow(QApplication http://harmattan-dev.nokia.com/docs/library/html/qt4/qapplication.html::desktop()-winId()); How to make a screenshot of a primary screen? Regards, Alexander. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QTcpServer. Connecting.Sending data.
Hello,
here's the code of the redefined method run() of QThread class =
void run() override
{
srv = new (std::nothrow) tcp_server(ised_win_raw_ptr);
#ifdef DEBUG
qDebug() listener's thread = thread();
#endif
terminate_ = false;
while ( !terminate_ ) if ( !srv-isListening() )
srv-listen(QHostAddress::Any, port);
#ifdef DEBUG
qDebug() Deleting the ised_tcp_server object.;
#endif
srv-close(); // Closes the server. The server will no longer
listen for incoming connections.
delete srv;
}
The program connects to 9000 port for listening.
Using the netcat command
nc -vv 127.0.0.1 9000
yields
PC_NAME [127.0.0.1] 9000 (?) open
Then I typed start and hit Enter.
The break point has been set in incomingConnection which is redefined
in the tcp_server class inheriting QTcpServer.
Debugger did not paused in the method body when netcat connected to the port.
Solutions?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Fwd: Windows::QDir::mkpath()
After the connection type was changed to BlockingQueuedConnection it worked well. 2013/10/6 Thiago Macieira thiago.macie...@intel.com On domingo, 6 de outubro de 2013 00:34:39, Alexander Syvak wrote: Hello, in the app. there're threads. Each of them is using the QDir::mkpath method creating new directories in common for them directory. Once upon a time each of them is stopped by emitting a signal (default connection) where the corresponding slot stops the thread timer and quits the event loop. Signals don't stop threads, especially not AutoConnection ones (the default). After emitting the signal the QThread::wait is called which returns false time to time. Also it happenes time to time that the files in the common directory are deleted. The assumption is that the thread is stopped in the middle of a mkpath invocation. Any other assumptions? Your only assumption is wrong. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Windows::QDir::mkpath()
Hello, in the app. there're threads. Each of them is using the QDir::mkpath method creating new directories in common for them directory. Once upon a time each of them is stopped by emitting a signal (default connection) where the corresponding slot stops the thread timer and quits the event loop. After emitting the signal the QThread::wait is called which returns false time to time. Also it happenes time to time that the files in the common directory are deleted. The assumption is that the thread is stopped in the middle of a mkpath invocation. Any other assumptions? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] qrgexpvalidator and qregexp
Hi, compiling the line QRegExpValidator valtor(QRegExp([1-9][0-9]*)); yields an error: no matching function for call to QRegExpValidator::QRegExpValidator(QRegExp). It's done on openSUSE. On Win7 it's compiled successfully. Where is the gist? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QThread, correct exit.
Hello, how to correctly stop a QThread execution? I am using thread.quit(); thread.terminate(); thread.wait(500); Without terminate() thread wait forever. Each thread is executing an event loop only (object is moved into thread). ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThread, correct exit.
Each thread emits blocking queued singnals to the main thread where button stop executes the code in the previous mail. 2013/9/28 Mandeep Sandhu mandeepsandhu@gmail.com On Sat, Sep 28, 2013 at 3:14 PM, Alexander Syvak alexander@gmail.comwrote: Hello, how to correctly stop a QThread execution? I am using thread.quit(); thread.terminate(); Don't terminate. Quitting and waiting should be sufficient. thread.wait(500); Without terminate() thread wait forever. Each thread is executing an event loop only (object is moved into thread). Is there anything else the thread could be stuck on? Busy looping somewhere? Waiting for a syscall? HTH, -mandeep ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QImage, multithreaded app.
Hello, the method save_screenshot() is used to save a QImage object using bool QImage::save ( const QStringhttp://doc.crossplatform.ru/qt/4.6.x/qstring.html *fileName*, const char * *format* = 0, int *quality* = -1 ) const Howver, it appears that QImage is working with one I/O device and returns false if it's busy, i.e. a thread paused at a moment of executing the save method. Is it better to use bool QImage::save ( QIODevicehttp://doc.crossplatform.ru/qt/4.6.x/qiodevice.html* *device*, const char * *format* = 0, int *quality* = -1 ) const method instead with its own I/O device for each thread or to create QMutexLocker in the save_screenshot() method? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QImage, multithreaded app.
Each object is of type event_analizer. Each such object contains a QImage
buffer (non-static). The event_analizer sends signal
need_screenshot(event_analizer*) where the receiving object uses the
pointer to store the made screenshot. Thuse, no, not on the same QImage
object.
Each thread is storing screenshots in RAM and its folder on HD after some
analysis of each screenshot.
2013/9/27 Thiago Macieira thiago.macie...@intel.com
On sexta-feira, 27 de setembro de 2013 23:13:44, Alexander Syvak wrote:
This is the code of the function saving screenshots. This code is used
in
threads analizing screenshots.
Debugging the app. when one thread has been paused inside QImage save
method and other thread wake up invoking the lines below
On the *same* QImage?
Like I said, I need to know what each thread is doing. Saving a QImage from
any thread should be acceptable, provided no other thread is using the same
QImage.
QFile screenshot_iodev(mk_screenshot_path(screenshot_idx++));
return screenshot.save( screenshot_iodev, format_raw_ptr );
where QImage::save returns false failing here
bool QImageWriter::canWrite() const
{
if (d-device !d-handler (d-handler =
createWriteHandlerHelper(d-device, d-format)) == 0) {
d-imageWriterError = QImageWriter::UnsupportedFormatError;
d-errorString = QT_TRANSLATE_NOOP(QImageWriter,
QLatin1String(Unsupported
image format));
return false;
}
2013/9/27 Thiago Macieira thiago.macie...@intel.com
On sexta-feira, 27 de setembro de 2013 16:12:37, Alexander Syvak wrote:
Hello,
the method save_screenshot() is used to save a QImage object using
bool QImage::save ( const
QStringhttp://doc.crossplatform.ru/qt/4.6.x/qstring.html
*fileName*, const char * *format* = 0, int *quality* = -1 ) const
Howver, it appears that QImage is working with one I/O device and
returns
false if it's busy, i.e. a thread paused at a moment of executing the
save
method.
Any thread? What is this other thread doing? Also, threads don't pause
except
if you're using the debugger.
It's far more likely that your mistake can be found in what this other
thread
is doing.
Is it better to use
bool QImage::save (
QIODevicehttp://doc.crossplatform.ru/qt/4.6.x/qiodevice.html*
*device*, const char * *format* = 0, int *quality* = -1 ) const
method instead with its own I/O device for each thread or
to create QMutexLocker in the save_screenshot() method?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Detecting any desktop state change
Hello, the requirement is to detect a desktop window visual change starting from a defined time moment. In the QPaintEvent documentationhttp://qt-project.org/doc/qt-4.8/qpaintevent.html#detailsthere's no exact information when it should be sent. However, I assume that it is sent whenever a widget is - resized; - moved; - exposed because a covering widget was moved. N.B. !!! I do not make assumptions whether a widget should be repainted in Qt if it is either partially or fully covered by a widget. However, since the desktop widget is the widget constituting the area for all widgets after an user is logged in and assumed that the widgets are children of the desktop widget, the desktop widget is the first QPaintEvent receival point. Hence, it should receive the QPaintEvent message when it is partially or fully covered. The idea is to use the QDesktopWidget class with an event filter expecting a paint event. I need thorough information (with sources) whether the assumptions are correct. If there is an input regarding the idea or another solution it would be greatly appreciated. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThread and QPixmap::grabWindow()
It's done as following, the thread wrapper (the class holding the QThread object and the pointer to be moved into the thread-worker) connects the class to be moved into the worker-thread with the main thread slot 'make_screenshot(pointer to the class which emits the signal)'. The main thread slot puts into the pointer the made screenshot. However, pictures are received are half damaged. When there's only one thread worker, the screenshots are OK. Any variants? 2013/8/8 Rainer Wiesenfarth rainer_wiesenfa...@trimble.com Am 08.08.2013 00:11, schrieb Alexander Syvak: [...] auto const this_thread = this-thread (); moveToThread (QApplication::instance()-**thread()); screenshot = QPixmap::grabWindow( QApplication::desktop()-**winId() ); moveToThread(this_thread); [...] I think you might have a problem in understanding threads and the thread context as used in Qt. moveToThread() does NOT change the thread the current code runs in! It only changes the target for events sent to this object. In your example, the thread that executes this-thread() is identical to the one that executes QPixmap::grabWindow(). You will have to implement synchronization between the main (GUI) thread and your workers. The workers send an event to the main thread each time they need a screenshot, the main thread picks up the event, takes the screenshot and sends an event back to the caller. The addressed worker thread then picks up this event and processes the screenshot. If you have only one worker, you might wrap up your processing in a single method and use QtConcurrent::run(). Best Regards / Mit freundlichen Grüßen Rainer Wiesenfarth -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/**imaging/ http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QThread and QPixmap::grabWindow()
Hello,
there's a need for each thread to make screenshots and to compare them with
loaded picture using QImage.
Since there's only on GUI thread, I moved the the thread context to the
main thread to make the screenshot in there.
Here's the code snipper from the worker-threads:
QPixmap screenshot;
try
{
auto const this_thread = this-thread();
moveToThread(QApplication::instance()-thread());
screenshot = QPixmap::grabWindow( QApplication::desktop()-winId() );
moveToThread(this_thread);
screenshots.append(screenshot);
// Compare it with the trigger if there was no match before.
if ( !matched event_p event_p-get_trigger_path().size()
images_comparator::cmp( screenshot.toImage(), QImage(
event_p-get_trigger_path() ), pattern() ) )
{
qDebug() !!! matched !!!;
matched = true;
However, the grabWindow returns null QPixmap always.
Who knows how to achive what's needed here?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QTimer and QThread
Here's the snippet below from implementation of the run method. The class inherits a class inheriting QThread. ... screenshot_qtmr = new QTimer;//(this); screenshot_qtmr-moveToThread(this); qDebug() connect(screenshot_qtmr, SIGNAL(timeout()), this, SLOT(on_screenshot_timeout())); qDebug() connect(this, SIGNAL(kill_tmr()), screenshot_qtmr, SLOT(stop())); screenshot_qtmr-start(freq*1000); anal_qmr = new QTimer;//(this); anal_qmr-moveToThread(this); qDebug() connect(anal_qmr, SIGNAL(timeout()), SLOT(on_analize_timeout())); qDebug() connect(this, SIGNAL(kill_tmr()), anal_qmr, SLOT(stop())); anal_qmr-start(state_analizer_tmr_interval); if ( !state_analizer_tmr_id ) return; exec();while ( !stop ); } Here's an ouput run() ./13_7_31_10_49_2_974 ./13_7_31_10_49_2_974 exists ./13_7_31_10_49_2_974 has 'write' permission for other ./13_7_31_10_49_2_974/S0 directory was created true true true true run() ./13_7_31_10_49_2_974 ./13_7_31_10_49_2_974 exists ./13_7_31_10_49_2_974 has 'write' permission for other ./13_7_31_10_49_2_974/S1 directory was created true true true true It never enters those method specified on timeout(). Why? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Full screen dialogs with modal input dialogs
Windows 7 x64 2013/7/30 Rutledge Shawn shawn.rutle...@digia.com Please search bugreports.qt-project.org, and if you can't find an existing bug about that, you can write up a new one and provide an example to demonstrate (preferably zip or tarball with .pro file ready to build). Also, which platform? On 29 Jul 2013, at 3:25 PM, Alexander Syvak wrote: Hello, there's a dialog calling a dialog as following p.setWindowFlags(Qt::FramelessWindowHint);//Qt::Popup); // N.B. !!! Popup doesn't require a title bar and a parent. auto const full_screen_rect = QApplication::desktop()-screenGeometry(); // N.B. !!! Returns the geometry of the screen with index screen. // The default screen is used if screen is -1. p.setGeometry(full_screen_rect); p.showMaximized(); int const usr_answer = p.exec(); When the p dialog inheriting QDialog calls any of QMessageBox, QInputDialog, QFileDialog, it's hidden and after user chooses a file in any of those 3 inputs, the dialos is still not shown. And using QFileDialog yields RPC not avaialble error ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] OpenSUSE, Qt 4.7, QtCreator 2.8, GDB, C++11: no debug mode is available
A console appilcation breaks at a breakpoint, however when a GUI application transfered from Windows 7 is to be compiled there's no Debug mode to be chosen below at the left side of the screen, only Release. In the Tool Chains list item of the Option submenu gdb is automatically detected with Qt 4.7 and g++ 4.8. Does anybody know the root of the issue? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Linux and Windows 7. Full screen widget.
But the geometry takes the whole screen in this example. And on Windows showMaximized() took the whole screen, so it took the fixed part as you said. Contradiction. 2013/7/30 Thiago Macieira thiago.macie...@intel.com On terça-feira, 30 de julho de 2013 23:10:02, Alexander Syvak wrote: When the showMaximized() is used in Windows 7, it indeed takes the whole screen, but on OpenSUSE, e.g. it shows the taskbar. When showFullScreen() is called, it works. Can anybody explain it step by step in details? Maximised means use all the available space, not including the fixed parts of the screen, like panels and top menu bars. Full screen means use the entire screen. So you've described the behaviour that is expected. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Full screen dialogs with modal input dialogs
Hello, there's a dialog calling a dialog as following p.setWindowFlags(Qt::FramelessWindowHint);//Qt::Popup); // N.B. !!! Popup doesn't require a title bar and a parent. auto const full_screen_rect = QApplication::desktop()-screenGeometry(); // N.B. !!! Returns the geometry of the screen with index screen. // The default screen is used if screen is -1. p.setGeometry(full_screen_rect); p.showMaximized(); int const usr_answer = p.exec(); When the p dialog inheriting QDialog calls any of QMessageBox, QInputDialog, QFileDialog, it's hidden and after user chooses a file in any of those 3 inputs, the dialos is still not shown. And using QFileDialog yields RPC not avaialble error ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QPainter, elastic rectangles
It's fixed. The question is closed.
There's another one.
Look at the next piece of code
void event_dlg::create_pattern()
{
qDebug() create_pattern() slot's been called!;
pattern_qualifier ptrn_qualifier_wdg(this);
ptrn_qualifier_wdg.setWindowFlags(Qt::FramelessWindowHint|Qt::Popup);
// N.B. !!! Popup doesn't require a title bar and a parent.
auto const full_screen_rect =
QApplication::desktop()-screenGeometry(); // N.B. !!! Returns the
geometry of the screen with index screen.
// The default screen is used if screen is -1.
ptrn_qualifier_wdg.setGeometry(full_screen_rect);
ptrn_qualifier_wdg.showMaximized();
int usr_anwer = ptrn_qualifier_wdg.exec();
}
The event_dlg is of type QDialog. The pattern_qualifier may be
anything from QWidget, QDialog, QMainWindow.
#1. When it inherits QWidget it's not visible or it's not even
started. I don't understand this.
#2. When it inherits QDialog without Qt::Popup flag set, the event_dlg
window is blocked except the title bar thereof.
#3. After the Qt::Popup flag is set it is shown and it works.
Why in #1 it's not shown at all?
Why in #2 it's blocking its parent but not visible
Why in #3 it's working fine with Qt::Popup?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
Do not use QtGui again. If an exception unwound the stack in QtGui, then QtGui is now in an undefined state, which means your application could do worse things than crash. How would you then handle std::bad_alloc in case there're a new widget made during an event clicked()? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 4.8, MetaType
Good day! In the book C++ GUI Programming with Qt 4 (2nd Edition) there's not much information about QMetaType and the Qt's internal subsystem. There's the statement at qRegisterMetaTypehttp://qt-project.org/doc/qt-5.0/qtcore/qmetatype.html#qRegisterMetaType which says ...After a type has been registered, you can create and destroy objects of that type dynamically at run-time. To use the type T in QVarianthttp://qt-project.org/doc/qt-5.0/qtcore/qvariant.html, using Q_DECLARE_METATYPEhttp://qt-project.org/doc/qt-5.0/qtcore/qmetatype.html#Q_DECLARE_METATYPE() is sufficient. To use the type T in queued signal and slot connections, qRegisterMetaTypeT() must be called before the first connection is established . After reading qmetatype.cpp and qmetatype.h everything Q_DECLARE_METATYPE does is specialization of QMetaTypeId template structure. QVariant inside the static function compare in qvariant.cpp uses QMetaType::IsRegistered method which in fact checks if the type was registered in customTypes using either qRegisterMetaType or QMetaTypeIdT::qt_metatype_id() after Q_DECLARE_METATYPE. Why is it sufficient then to use Q_DECLARE_METATYPE for any template using the declared type? qRegisterMetaType only puts the type to be registered into customTypes vector registering constructor and destructor for the type with an ID (optionally an user may register operator and operator for the type). Why is it needed to use queued signal and slot connections and QObject::property() API? Furthermore, Q_OBJECT is required for a type using slots/signals. QObject does not meet CopyConstructible requirement for using either Q_DECLARE_METATYPE or qRegisterMetaType. I'd like to ask you to clearify this. Thank you. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] App. is running after an exception is thrown.
Hello,
after calling w.show() there's method redefined void event_dlg::showEvent(
QShowEvent *). In this method there's an exception thrown. The process does
not terminate.
Can anyone througly explain why is the job running after calling either
close() of the only one and thus the last window (event_dlg w) or quit() of
the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Fwd: Qt 4.8, MetaType
About the last statement. If an object uses internally slots and signals, it should inherit QObject. QObject is not copyconstructible, thus, the descendant as well. If the object requires queued signals or QObject::property() API then qRegisterMetaType() should be called, which requires CopyConstructible property of the object. It's a cycle here. Where is a misunderstanding? 2013/7/26 Thiago Macieira thiago.macie...@intel.com On sexta-feira, 26 de julho de 2013 09:22:07, Alexander Syvak wrote: Why is it sufficient then to use Q_DECLARE_METATYPE for any template using the declared type? Because those template functions you referred to will do the registration for you if necessary, before accessing the information that is stored with the registration (namely, the functions to create and destroy). qRegisterMetaType only puts the type to be registered into customTypes vector registering constructor and destructor for the type with an ID (optionally an user may register operator and operator for the type). Why is it needed to use queued signal and slot connections and QObject::property() API? Because at that point there is no code that will do the registration for you. It needs to access the constructor and destructor and all it knows at that point is the name of the type (as found in the meta object). This is fixed in Qt 5.0. Furthermore, Q_OBJECT is required for a type using slots/signals. QObject does not meet CopyConstructible requirement for using either Q_DECLARE_METATYPE or qRegisterMetaType. Correct. That is not a question. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
I caught and threw again. 2013/7/26 Thiago Macieira thiago.macie...@intel.com On sexta-feira, 26 de julho de 2013 20:19:58, Alexander Syvak wrote: after calling w.show() there's method redefined void event_dlg::showEvent( QShowEvent *). In this method there's an exception thrown. The process does not terminate. Please consider all event handlers and slots (when called via the signal-slot mechanism) as nothrow / noexcept. If you throw or fail to catch something, it's undefined behaviour. From that point on, your application is doomed. It will most likely crash. But, as you discovered, it may do something else. Fix the problem by catching the exception. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] App. is running after an exception is thrown.
So the a.exec() enters the event loop. Then the handler showEvent(QEvent*)
is executed. The std::runtime_error is thrown out of the handler to the
point of the previous call.
The exception is caught inside the main() function. The dialog is thus not
shown, but start executing again.
2013/7/26 Constantin Makshin cmaks...@gmail.com
QCoreApplication::quit(), being an alias to QCoreApplication::exit(0),
does nothing outside an event loop which in your case is started afterwards.
On Jul 26, 2013 10:20 PM, Alexander Syvak alexander@gmail.com
wrote:
Hello,
after calling w.show() there's method redefined void event_dlg::showEvent
(QShowEvent *). In this method there's an exception thrown. The process
does not terminate.
Can anyone througly explain why is the job running after calling either
close() of the only one and thus the last window (event_dlg w) or quit() of
the QApplication a?
#include event_dlg.h
#include QApplication
#include QMessageBox
#include QDebug
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
event_dlg w;
try
{
w.set_config_file(./events.xml);
w.show();
}
catch ( std::runtime_error e )
{
//QMessageBox msgBox;
//msgBox.setText(e.what());
//msgBox.exec();
//qDebug() w.close();
a.quit();
}
return a.exec();
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QXmlStreamReader and qDebug()
Here're 2 code snippets with different outputs: #1 qDebug() pxml-start_element() pxml-name(); qDebug() pxml-read_element_text(); #2 qDebug() pxml-start_element() pxml-name() pxml-read_element_text(); pxml is a pointer to the class incapsulating the QXmlSteamReader object. start_element() = isStartElement() name() = name().toString() read_element_text() = readElementText() The first snippet yields true NAME CONTENT The second snippet yields false NAME Why? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QXmlStreamReader and qDebug()
Inside the qdebug.h qDebug() creates QDebug object with QTextStream object encapsulated. operator is evaluated from the left to the right each time returning QDebug object. Why would there be any randomness? And start_element() with name() should not influent on the execution reult of the read_element_text() only because they are queries. 2013/7/27 Thiago Macieira thiago.macie...@intel.com On sábado, 27 de julho de 2013 00:04:36, Alexander Syvak wrote: qDebug() pxml-start_element() pxml-name(); qDebug() pxml-read_element_text(); #2 qDebug() pxml-start_element() pxml-name() pxml-read_element_text(); Why? The functions aren't called in the same order. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QStackedWidget and QListView
There's a model inherited from the QAbstractListModel. The dialog lay out
is implemented as following
main_layout_raw_ptr = new (std::nothrow) QVBoxLayout;
create_toolbar();
main_layout_raw_ptr-addLayout(toolbars_layout_raw_ptr);
create_central_layout();
main_layout_raw_ptr-addLayout(central_layout_raw_ptr);
this-setLayout(main_layout_raw_ptr);
The central layout is QHBoxLayout with two widgets: QListView and
QStackedWidget.
central_layout_raw_ptr = new (std::nothrow) QHBoxLayout;
listview_raw_ptr = new (std::nothrow) QListView;
listview_raw_ptr -setModel(list_model_raw_ptr);
central_layout_raw_ptr-addWidget(listview_raw_ptr );
stacked_pages_raw_ptr = new (std::nothrow) QStackedWidget;
central_layout_raw_ptr-addWidget(stacked_pages_raw_ptr, 1); //
stretch factor is set
connect(listview_raw_ptr ,SIGNAL(currentRowChanged(int)),
stacked_pages_raw_ptr, SLOT(setCurrentIndex(int)) );
When the dialog is shown the next function body is executed
emit beginResetModel();
try
{
obs = psr.parse(events_src_file);
}
catch ( std::runtime_error )
{
emit endResetModel();
throw;
}
emit endResetModel();
However, the result is [image: Встроенное изображение 1]
Where is a mistake?
p.PNG___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
