General and Desktop

Gerolf, this is exactly what I wanted to hear, thank you both for your input, I'll do some reading. -- Thank you, William

You guys are awesome. Thanks so much. I didn't realize I could pass a functor. I had gotten an error before that led me to a StackOverflow posts that said you couldn't use member functions.

Hi kenbrot, this code perfectly compiles: @ class LogParser { public: int i; int j; QList<int> m; void start() {} }; int main(int argc, char argv[]) { QList<LogParser> logParsers; QListIterator<LogParser*> iterator(logParsers); while(iterator.hasNext()) { iterator.next()->start(); } return 0; } @ Perhaps LogParser is only predefined?

Thanks for giving a hand, i tried setting /DEBUG and /Zi in the library release build but nothing changed in the testapp result (still crash). i uploaded a simple testcase at http://rapidshare.com/files/456023127/testcase.rar no matter what setting i put on testdll (release build), testapp always has issues (in debug)

Thank you very much, I added: @INCLUDEPATH += D:/Distr/Network/WpdPack/Include LIBS += -L D:/Distr/Network/WpdPack/Lib -lwpcap - lpacket@ and it solved the problem.

K dude, i love you :-) 10x! PS Still, what i said earlier about having a property directly in the Qt socket class (at least for UDP) would definitely be nice, so i'll leave my "cry for help" there, maybe the Qt developers will take notice (yeah, that's a pretty long shot for chasing a short TTL, i know :)

Signals and slots can in a limited way be connected through the designer interface of Qt Creator. Only signals and slots inside the form you are creating (that is, between the widgets that you have put on the form) can be connected. For other signals and slots, you need to make the connections in code.

Thanks Tobias Hunger my post http://antyadev.blogspot.com/

OK, fair enough: "Make list of supported QTextDocumentWriter formats extendible":http://bugreports.qt.nokia.com/browse/QTBUG-18570 "Add support for RTF to QTextDocumentWriter":http://bugreports.qt.nokia.com/browse/QTBUG-18571

Another solution (which I personally prefer) is to make a "Controller" object (derived from QObject) which encapsulates the non Qt interface (your C-backend) in a "facade design pattern":http://en.wikipedia.org/wiki/Facade_pattern . This goes to the direction -Andrea- Andre posted before the state machine. This controller object then sends signals which can be connected to anyone, who needs to know them... This is something we do often here with COM interfaces we have to use. It works well. Edit: my name is Andre

okay I will look into those thank you.

You're absolutely right -- perhaps I expressed myself badly before. You CAN do it as of now using QNetworkAccessManager. The only culprit is that in 4.7 there's nothing to help you for making multipart/form-data POST requests. application/x-www-form-urlencoded POST requests are easy to deal with (by hand or using QUrl).

Ah OK I think I understand now. I am not entirely sure what the limiting factor is in the rate at which mouse mouse events are generated. It could well be tied into the resolution used by your X mouse driver - probably a setting in xorg.conf but depend on which version of X you have - one day they'll settle on a configuration method ;-). One thing to try would be to try changing the mouse driver resolution and seeing if that affects the frequency of your mouse move events. Let us know how you get on.

Actually I was replying to OP, edited the post to make that clear.

For what it's worth I agree with Raul, a serious waste of time, effort and no doubt money. If it's of any help make sure you link with the odbc libraries found in your Windows SDK. This should of course happen by default assuming your SDK's library path in referenced in your environment. -- Regards, William

Good point. I think you are right, and QTextDocument::find() is the way to go.

I have requested "bug 172":http://bugreports.qt.nokia.com/browse/QTBUG-172 be re-opened. That has been done. You can vote for it now, if you want. Don't count on this being fixed any time soon though, seeing that the priority is not that high.

Yes that is a good approach too. It depends on the relationship of your objects as to which is more suitable. Anyway you have a few options to try now. :-)

Yes, of course. It would only catch invocations through the signal/slot system. Sorry, I missed that part in your post.