We just came along the question if there is a per-version list of QT_...
defines that could be used when building applications based on Qt.
I know that in 5.3.2 there is QT_NO_CAST_FROM_ASCII, mentioned in the
QString docs, I saw QT_DISABLE_DEPRECATED_BEFORE on the QtGlobal page and
I know about
Hi,
Please let me know the Android and IOS versions that are being supported by
latest Qt5.4.
Thanks and Regards,
Ramakanth
Disclaimer: This message and the
This is the more complicated way.
Just use deleterLater(). It has the same effect. After the next round the
eventloop the object will be deleted.
I'm not trying to delete the serial port object, I'm just trying to close the
serial port so that I stop listening.
Sean
Closing a device within a read slot sounds dodgy anyway. In these cases, I
usually do
QTimer::singleShot(0, ...) and do the close in that slot.
I thought about doing the single shot as well.
Is there a more concrete reason (other than it sounding dodgy) that you feel
like the way I'm
Hello folk !
I've got a trouble I don't understand : the bind on the QUdpSocket doesn't
conplains but I don't receive anything if I put my IP Address in
_bindAddress. So the binding on AnyIPv4 works but not for adresses.
(the soft I'm working on is multi OS (Linux/Windows) I develop and test on
Hi:
We want to block the widget's WindowActivate and FocusIn event triggered by
calling its show() function, with Qt4, we used to do that by setting flag
before and after show() and filter out the event in eventfilter based on
the flag. But with Qt5, the events are processed asynchronously, we
Hello,
I'm trying to find a way to prevent focus-stealing on Mac OS X in KDE4
applications when a notification is posted through a helper process
(daemon/service/agent). The most elegant way would be to determine the active
window when the notification is created, and reactivate it when the
Sorry, I mis-understood you and thought wanted to delete the object. This is
definitely a no-no inside the slot.
I saw you on windows which creates a thread for handling the device.
I have not looked into it, but it could be that it is trying to stop/delete
this thread when closing. This could
Seam wrote:
Sent: Friday, 31 October 2014 12:43 AM
Closing a device within a read slot sounds dodgy anyway. In these
cases, I usually do QTimer::singleShot(0, ...) and do the close in that
slot.
I thought about doing the single shot as well.
Is there a more concrete reason (other