summaryrefslogtreecommitdiffstats
path: root/config.tests/unix/opengles1
diff options
context:
space:
mode:
authorMiikka Heikkinen <miikka.heikkinen@digia.com>2011-08-12 12:29:20 (GMT)
committerMiikka Heikkinen <miikka.heikkinen@digia.com>2011-08-12 13:17:58 (GMT)
commit1dc0a2ccd645abd26b13fd67313a03bbc722a74d (patch)
tree3d67cf3b6fa877a6baf6796257e3b8d7e22e17f1 /config.tests/unix/opengles1
parent15b44c1ea04c3beebe4d7f6d9f45b81127c3c8f9 (diff)
downloadQt-1dc0a2ccd645abd26b13fd67313a03bbc722a74d.zip
Qt-1dc0a2ccd645abd26b13fd67313a03bbc722a74d.tar.gz
Qt-1dc0a2ccd645abd26b13fd67313a03bbc722a74d.tar.bz2
Fix softkeys cleanup
QSoftKeyManager's keyedActions and softKeyCommandActions hashes were not properly cleaned up, resulting in randomly incorrect softkeys as already deleted cached actions were assigned to softkeys if the new action happened to be in the same address as the previously deleted action. Two bugs related to this were fixed: 1) qobject_cast can't be used in "destroyed" signal handler, as the cast will return NULL pointer in this case. Changed the cast to static_cast, which is safe here as the pointer is only used as a hash key. 2) If softkey action was created with QSoftKeyManager::createAction instead of QSoftKeyManager::createKeyedAction, the "destroyed" signal was not connected to cleanupHash slot, leaving such actions in softKeyCommandActions hash after deletion. Ensured the signal was connected properly in both cases. Task-number: QTTH-1442, QTBUG-20214 Reviewed-by: Gareth Stockwell
Diffstat (limited to 'config.tests/unix/opengles1')
0 files changed, 0 insertions, 0 deletions