2da05e2324
Better workaround for the previous commit.
2012-03-23 01:29:50 +01:00
18094c66f0
Workaround for Windows XP: It appears that QThread::isRunning() may return TRUE even after the QThread object has already emitted the "finished" signal. For some reason this only occurs on Windows XP, but never occurs on my Windows 7 machine. As a workaround we will call QThread::yieldCurrentThread() and then try again. This seems to fix the issue on my Windows XP machine.
2012-03-22 22:26:54 +01:00
1d52b628d1
Show which AAC encoder is being used in the GUI.
2012-03-06 22:29:55 +01:00
2ee08c5f4b
Fixed a regression in d92fb7fbcc: We must not close the handle to the Job Object, as long as there still might be a process "tool" running. The regression caused child processes to be terminated unexpectedly sometimes! We now use reference counting in order to avoid this problem.
2012-03-01 02:45:21 +01:00
86e17a04ff
Bump version + update Changelog file.
2012-02-23 21:21:02 +01:00
3c1938af3c
Fixed a potential live-lock situation: Signals from the QThread can get lost, before we reach the QEventLoop->exec(), even if the required connections already exists. It seems that QApplication::processEvents() will discard signals for our QEventLoop, if that QEventLoop is not running yet! Without the QApplication::processEvents(), those signals would simply be enqueued until we call QEventLoop->exec(). In reality this bug was never triggered under normal circumstances, but it seems on some systems it can take longer to perform the "fade in" than to finish the initialization thread. In that situation the bug *was* triggered and caused the live-lock...
2012-02-23 17:00:22 +01:00
9b687fff9a
Happy New Year 2012!
2012-01-02 00:52:27 +01:00
1f001a65e2
Better handling of system shutdown. Now using the Qt event system to broadcast a special event when the system is going to shutdown (i.e. WM_QUERYENDSESSION or WM_ENDSESSION). This gives each top-level widget the chance to react to the system shutdown *before* we return from the message handler. Doing any clean-up after returning from the message handler is impossible, because Windows will kill the process immediately after WM_ENDSESSION has been processed. Note that Windows XP (and earlier) will NOT send WM_QUERYENDSESSION or WM_ENDSESSION to processes that have a console attached! Therefore, if we have a debug console attached, we cannot do anything on these systems. Our process will be killed without any notification...
...
Also improved LameXP's IPC mechanism: There now are several slots for IPC-commands in the shared memory area ("queue support"). This way, the sender can post several commands in sequence without getting blocked. The receiver can process those at a later time.
2011-12-29 14:42:20 +01:00
db587fe228
Prevent some more dialogs from blocking a quick system shutdown.
2011-12-27 13:51:01 +01:00
be410216a9
Reworked SplashScreen fade-in and fade-out code a bit.
2011-11-11 18:08:22 +01:00
5a32fc3b82
Implemented a more correct way to initialize the ITaskbarList3 interface. We now actually wait for the "TaskbarButtonCreated" message.
2011-11-07 17:13:41 +01:00
8977e0073f
Clean up #include directives: Don't include 'Windows.h' directly, as it's included from 'Global.h' header file.
2011-04-11 21:55:34 +02:00
96db5e86c2
Happy new year!
2011-01-01 17:04:25 +01:00
36ae27f5f3
first commit
2010-11-06 23:04:47 +01:00
