The types messages when constructed from the list view contents may have a

different sorting order. Therefor store that message in the original data
info instead the types message retrieved from the node. This fixes the
FileType window from requesting a save operation on quit even if nothing
changed (probably with certain app infos only where the sorting happened to
be different. Was the case with Firefox for example). Fixes #XXXX (Trac is
broken again... sigh)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28720 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Stephan Aßmus 2008-11-22 18:31:16 +00:00
parent b990fd9244
commit 9aed61212a

View File

@ -602,9 +602,6 @@ ApplicationTypeWindow::_SetTo(const BEntry& entry)
else
flags = B_MULTIPLE_LAUNCH;
BMessage supportedTypes;
info.GetSupportedTypes(&supportedTypes);
version_info versionInfo;
if (info.GetVersionInfo(&versionInfo, B_APP_VERSION_KIND) != B_OK)
memset(&versionInfo, 0, sizeof(version_info));
@ -653,6 +650,9 @@ ApplicationTypeWindow::_SetTo(const BEntry& entry)
// supported types
BMessage supportedTypes;
info.GetSupportedTypes(&supportedTypes);
for (int32 i = fTypeListView->CountItems(); i-- > 0;) {
BListItem* item = fTypeListView->RemoveItem(i);
delete item;
@ -702,7 +702,10 @@ ApplicationTypeWindow::_SetTo(const BEntry& entry)
fOriginalInfo.signature = signature;
fOriginalInfo.flags = flags;
fOriginalInfo.versionInfo = versionInfo;
fOriginalInfo.supportedTypes = supportedTypes;
fOriginalInfo.supportedTypes = _SupportedTypes();
// The list view has the types sorted possibly differently
// to the supportedTypes message, so don't use that here, but
// get the sorted message instead.
fOriginalInfo.iconChanged = false;
fOriginalInfo.typeIconsChanged = false;