Just to get a clear view of what you want to achieve: Why do you want to subclass the QNetworkReply?

yes, and in that subclass there is the problem with isFinished and isRunning

That was not an answer to my question :). After a quick review the whole implementation leads me to believe the QNetworkReply isn’t there to be subclassed (by non-qnetwork code that is). If you really need to subclass this thing, you should have it depend on on the non-public API, I’m afraid.

That is why I wanted to know why you are trying to subclass it — what are you trying to achieve that you need this subclass for?

ah sorry i didnt get the why in your question :)
several reasons: the first is to provide my own network protocol (QNetworkAccessManager provides a virtual createRequest method)
the second is to rewrite the Ftp part to enable resumePut and resumeGet which isnt provided by the default implementation

When you’re done with your work, you must emit signal finished().

You cannot do that in the constructor of your QNetworkReply subclass, because at that time the signal/slot connections in your client code were not setup!

Some more info on this in the Qt mailing list [lists.trolltech.com]

i am emitting finished. That is noth the problem. I am talking about QNetworkReply::isFinished() not about the SIGNAL QNetworkReply::finished() .

I found no line in the Qt source where this Signal is connected internally. Also connecting it internally wouldnt solve my problem, since in QNetworkReplyPrivate the method isFinished always returns false. I cant change that private class to have a late binding on that function.

I overlooked that. That’s a bug, indeed. It’s already addressed and fixed by Nokia, see QTBUG-11737 [bugreports.qt.nokia.com], although it will be public not until Qt 4.8.0.

thank you volker for the link.

Anyone has a suggestion for a workaround for now?

If you do not rely on a prebuilt Qt you can get the patch (there’s a link to the git commit on the bugtracker) and apply it to your sources.