On Mon, Jul 09, 2012 at 04:21:04PM -0600, David Beck wrote:
> > Try pyrcc4 -h
>
> Just did, it just gave me the help options, which I've already seen.
Phil's point is that it explains the syntax, which you have got quite
wrong. Start over and follow the help carefully.
__
On Sun, Jul 08, 2012 at 07:02:27PM -0300, Diego wrote:
> When a row is selected in the QTreeView, I need to be able to access
> the object whose attributes are being displayed in that row. I don't
> know how to properly do that, and the only thing that worked for me is
> to store the original objec
On Sat, Jun 23, 2012 at 09:57:56AM +0100, Phil Thompson wrote:
> Why? Does Debian need it to be called CPPFLAGS specifically rather than
> the already supported CXXFLAGS?
I'm going to guess that you've made the common mistake. CPPFLAGS is
the preprocessor flags, not the C++ compiler flags. Hence i
On Tue, Jun 19, 2012 at 06:10:31PM -0700, Doogster wrote:
> On both Arch Linux (PyQt 4.9) and Windows (4.8.1, I believe), the
> attached code sample segfaults the Python interpreter.
It's probably the usual garbage-collection problem: your
QHttpMultiPart is being destroyed before the network manag
On Thu, May 03, 2012 at 08:15:26AM -0400, Mark Mordeca wrote:
> while(query.next()):
>
> idString=str(query.value(0).toString())
>
> passwordString=str(query.value(1).toString())
>
>
>
> query.value() returns a QVariant, so you use .toString() to convert it to
> a QString, then use
On Mon, Apr 30, 2012 at 09:25:52AM +0200, Hans-Peter Jansen wrote:
> following Eriks suggestion of disabling the GC altogether would have given a
> valuable data point for your issue.
Oh, I did try that. Everything works fine when GC is disabled.
> Vanishing still referenced local
> variables i
On Sun, Apr 29, 2012 at 03:51:43PM +0100, Phil Thompson wrote:
> You might try keeping explicit references to any objects involved in the
> query where you might be expecting PyQt to keep the reference for you.
At the point when it gets collected, it's still in scope as a local
variable of the pyt
On Sat, Apr 28, 2012 at 01:05:37PM +0200, Erik Janssens wrote:
> which version of PyQt are you using ?
>
> When in older versions (I think something like 2 releases ago),
> the garbage collection kicks in in a thread and it deletes
> a QObject from another thread, this object was deleted
> immedia
On Sat, Apr 28, 2012 at 12:57:47AM +0300, Ville M. Vainio wrote:
> I have a qml file invoking methods on a QObject subclass. I have used
> @pyqtSlot decorator to expose the methods as slots.
>
> I can see that the methods are run; however, the return values seem to
> be discarded.
Qt slots don't
query = QtSql.QSqlQuery()
if not query.prepare('select %s from %s where %s' %
(','.join(field_names), table, self.key_expr(table))):
I get 'RuntimeError: underlying C/C++ object has been deleted' on the
second line, with low probability. Sometimes it just segfaults instead
while i
I'd rather like to be able to write code like this:
for name in dir(obj):
a = getattr(obj, name)
if isinstance(a, QtCore.pyqtSignal):
setattr(self, name, a)
Unfortunately, signals of objects are of class pyqtBoundSignal and I
can't find a class object to pass to isinstance - does it exist
http://bugs.python.org/issue14432
Looks like python will crash if you do any of the operations affected
by restricted execution (create file objects, meddle with __dict__,
etc) from a generator that was created in an older iteration of the
event loop.
The main python thread should be safe, since
Pretty sure it's a pyqt bug, in deleteSlotProxies:
if (QThread::currentThread() == up->thread())
delete up;
else
up->deleteLater();
http://qt-project.org/doc/qt-4.8/qobject.html#dtor.QObject
"Warning: Deleting a QObject while pending events
On Sun, Apr 15, 2012 at 11:45:02AM +0100, Phil Thompson wrote:
> On Sat, 14 Apr 2012 22:33:02 +0100, Andrew Suffield
> wrote:
> > On Sat, Apr 14, 2012 at 03:14:28PM +0100, Phil Thompson wrote:
> >> Once the C++ disconnect() has completed then it shouldn't matter if the
On Sat, Apr 14, 2012 at 03:14:28PM +0100, Phil Thompson wrote:
> Once the C++ disconnect() has completed then it shouldn't matter if the
> proxy is still around or not. Has the disconnect() actually succeeded?
Hmm, interesting question. How do I tell?
I should note that it's difficult to test bec
I've been having grief with a class of problems that looks like this
valgrind error:
==28760== Invalid write of size 4
==28760==at 0x6C26DED: PyQtProxy::unislot(void**) (in
/usr/lib/python2.7/dist-packages/PyQt4/QtCore.so)
==28760==by 0x6C26EC1: PyQtProxy::qt_metacall(QMetaObject::Call, i
The attached script creates a threading.local within a QThread, and
stores a value in it. It then reads this value back immediately, and
later from an event handler.
Unexpectedly, by the time we get to the event handler, the contents of
the threading.local has been destroyed.
I suspect there are
17 matches
Mail list logo
