[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_pt

Re: [Interest] QXmlStreamReader and qDebug()

Il 27/07/2013 00:51, Alexander Syvak ha scritto: operator<< is evaluated from the left to the right each time returning QDebug object. That's only half of the story. When in your code you have something like this: qDebug() << a << b << c; that will get parsed by the compiler into someth

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_el

Re: [Interest] Support for multiple 'out' parameters in qdbusxml2cpp

On sexta-feira, 26 de julho de 2013 16:35:24, Matt Hoosier wrote: > Okay, I agree that I could pin down the parent class name and get automatic > dispatch wired up. But I'd like to understand why the normal > QMetaObject::invokeMethod() dispatch isn't allowed in this case (that is, > more than one

Re: [Interest] QXmlStreamReader and qDebug()

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 sa

[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 obje

Re: [Interest] Support for multiple 'out' parameters in qdbusxml2cpp

Hi Thiago, Thanks for replying. I'd traced through the logic in qdbusxml2cpp's source as well before posting, and saw the same chunk of logic that determines whether to emit only the placeholder. Okay, I agree that I could pin down the parent class name and get automatic dispatch wired up. But I'

Re: [Interest] App. is running after an exception is thrown.

On sábado, 27 de julho de 2013 00:58:19, Constantin Makshin wrote: > The exception prevents show() from finishing its work so your windows > remains invisible. But it still exists (it wasn't shown, but nobody closed > it either), so exec() happily runs the event loop, not knowing the > application

Re: [Interest] App. is running after an exception is thrown.

The "show" event is synchronous, i.e. it's not queued and showEvent() is called almost directly from show()'s internals. That means things in your code happen in this order: 1) you call show(); 2) at one place inside show() there is a call to QCoreApplication::sendEvent() which in turn calls your s

Re: [Interest] Support for multiple 'out' parameters in qdbusxml2cpp

On sexta-feira, 26 de julho de 2013 15:27:21, Matt Hoosier wrote: > I've observed that qdbusxml2cpp doesn't emit the QMetaCall that would > forward a D-Bus method-call message from the adaptor along to the "business > logic" class that provides slots to implement all the various methods. > E.g., if

Re: [Interest] App. is running after an exception is thrown.

>From the documentation for QCoreApplication::exit: "After this function has been called, the application leaves the main event loop and returns from the call to exec(). The exec() function returns returnCode. If the event loop is not running, this function does nothing." QCoreApplication::q

[Interest] Support for multiple 'out' parameters in qdbusxml2cpp

I've observed that qdbusxml2cpp doesn't emit the QMetaCall that would forward a D-Bus method-call message from the adaptor along to the "business logic" class that provides slots to implement all the various methods. E.g., if I have: the adaptor code for this method ends up l

Re: [Interest] App. is running after an exception is thrown.

On sexta-feira, 26 de julho de 2013 21:40:42, Alexander Syvak wrote: > I caught and threw again. Catch and don't rethrow. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message

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 Con

Re: [Interest] App. is running after an exception is thrown.

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" wrote: > Hello, > > after calling w.show() there's method redefined void event_dlg::showEvent( > QShowE

Re: [Interest] App. is running after an exception is thrown.

I caught and threw again. 2013/7/26 Thiago Macieira > 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 t

Re: [Interest] Fwd: Qt 4.8, MetaType

On sexta-feira, 26 de julho de 2013 20:20:57, Alexander Syvak wrote: > About the last statement. If an object uses internally slots and signals, > it should inherit QObject. Correct. > QObject is not copyconstructible, thus, the descendant as well. Correct. > If the object requires queued signa

Re: [Interest] App. is running after an exception is thrown.

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

[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 CopyConstru

[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 (eve

Re: [Interest] Qt 4.8, MetaType

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 t

Re: [Interest] DBus on X11 using Qt5

On sexta-feira, 26 de julho de 2013 08:11:18, Ramakanthreddy Kesireddy wrote: > Yes Reply.type() is QDBusMessage::ReplyMessage Ok. So what were the contents of the reply? Please print Reply.signature(). If you want more information, please do this: 1) add outside your function: namespace QDBusUti

Re: [Interest] QMap and thread-safe.

On Fri, Jul 26, 2013 at 12:30 PM, Thiago Macieira wrote: > On sexta-feira, 26 de julho de 2013 10:27:28, Mandeep Sandhu wrote: > > > Doing both at the same time is not atomic anywhere unless you use > > > specialised > > > fetch-and-add instructions, which the compiler never generates for you. >

[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 qRegisterMetaType which says "...After a type has been

Re: [Interest] QMap and thread-safe.

On sexta-feira, 26 de julho de 2013 12:09:43, Mandeep Sandhu wrote: > Well, thats why I asked the previous question, i.e if foo is of machine > word size or less, _then_ will the compiler generate the atomic fetch and > add instruction or will that have to be done explicitly by the programmer? And

Re: [Interest] QMap and thread-safe.

On sexta-feira, 26 de julho de 2013 10:27:28, Mandeep Sandhu wrote: > > Doing both at the same time is not atomic anywhere unless you use > > specialised > > fetch-and-add instructions, which the compiler never generates for you. > > By both here, you mean fetch AND add, right? Right > And in x