Am 02.02.2012 um 15:49 schrieb Sujan Dasmahapatra <sujan.dasmahapa...@gmail.com>:
> May Thorson you're right, I'll do a flush on the stream and see. Also I'll > follow Andreas suggestion check it by debugging. It should work. Thanks for > your valuable suggestions. No. That cannot possibly work. Even if the file is being polled (that is handled *synchronously* by the Qt event queue) imagine if the poll interval was one minute! Your method would have long returned before (and hence the signal blocker destroyed) before the Qt event queue would be informed either via a QTimer based polling (synchronous) or (asynchronously) via some OS event. In any case the Qt event queue can only handle such an event *after* your method has returned (and have the QFileWatcher emit its signal): no Qt event interrupts your method execution, so the QFileWatcher would not emit any signals while your method is being executed anyway! So I cannot imagine how that could have worked with Bo's solution in the first place - unless off course we are talking about multiple threads, but even then chances are that your method (where you try to block the signal from QFileWatcher) would finish *before* the OS gets a chance to notify the application and you would *still* get the signal (at some random time in the future) later on. So unless you write some application-specific values (an encrypted signature for example which only your process can create, in the extreme case) into the file I don't see how you could detect whether it was your or some other process that modified the file last! Cheers, Oliver _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
