[PATCH 1/3] shell32/tests: Test that ShellView picks up external file changes
Signed-off-by: Nigel Baillie <metreckk(a)gmail.com> --- dlls/shell32/tests/shlview.c | 89 ++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) diff --git a/dlls/shell32/tests/shlview.c b/dlls/shell32/tests/shlview.c index f5d96c8d44..4d0cf641a7 100644 --- a/dlls/shell32/tests/shlview.c +++ b/dlls/shell32/tests/shlview.c @@ -1502,6 +1502,94 @@ todo_wine IUnknown_Release(unk); } +static void do_events(void) +{ + MSG msg; + while(PeekMessageA(&msg, NULL, 0, 0, PM_REMOVE)){ + TranslateMessage(&msg); + DispatchMessageA(&msg); + } +} + +static void test_external_change(void) +{ + IShellFolder *desktop, *folder; + FOLDERSETTINGS settings; + IShellView *view; + IShellBrowser *browser; + IFolderView *fv; + HWND hwnd_view; + LPITEMIDLIST pidl; + HRESULT hr; + HANDLE file; + INT count; + RECT r; + BOOLEAN b; + static const WCHAR test_folder_path[] = + {'C',':','\\','s','h','l','v','i','e','w','_','t','e','s','t',0}; + static const WCHAR test_file_path[] = + {'C',':','\\','s','h','l','v','i','e','w','_','t','e','s','t','\\','f','.','t','x','t',0}; + + /* create test folder, get a PIDL to it */ + b = CreateDirectoryW(test_folder_path, NULL); + ok(b, "failed to create test directory\n"); + + pidl = ILCreateFromPathW(test_folder_path); + ok(pidl != NULL, "couldn't get a PIDL to the test directory\n"); + + /* Get an IFolderView for the test folder */ + hr = SHGetDesktopFolder(&desktop); + ok(hr == S_OK, "got (0x%08x) when trying to grab desktop folder\n", hr); + + hr = IShellFolder_BindToObject(desktop, pidl, NULL, &IID_IShellFolder, (void**)&folder); + ok(hr == S_OK, "got (0x%08x) from BindToObject\n", hr); + + hr = IShellFolder_CreateViewObject(folder, NULL, &IID_IShellView, (void**)&view); + ok(hr == S_OK, "got (0x%08x) from CreateViewObject\n", hr); + + hr = IShellView_QueryInterface(view, &IID_IFolderView, (void**)&fv); + ok(hr == S_OK, "got (0x%08x) when trying to get an IFolderView interface\n", hr); + + /* create window */ + browser = IShellBrowserImpl_Construct(); + settings.ViewMode = FVM_ICON; + settings.fFlags = 0; + hwnd_view = (HWND)0xdeadbeef; + SetRect(&r, 0, 0, 100, 100); + hr = IShellView_CreateViewWindow(view, NULL, &settings, browser, &r, &hwnd_view); + ok(hr == S_OK, "got (0x%08x) when trying to create view window\n", hr); + ok(IsWindow(hwnd_view), "got %p instead of a valid HWND\n", hwnd_view); + + /* item count should be zero */ + IFolderView_ItemCount(fv, SVGIO_ALLVIEW, &count); + ok(count == 0, "count should've been 0, but was %i\n", count); + + /* create test file */ + file = CreateFileW(test_file_path, 0, + FILE_SHARE_READ | FILE_SHARE_WRITE, + NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); + ok(file != INVALID_HANDLE_VALUE, "failed to create test file\n"); + if (file != INVALID_HANDLE_VALUE) + CloseHandle(file); /* we don't actually need the file open */ + + /* let the shlview figure out that it was created */ + Sleep(1000); + do_events(); + + /* it should now show the new file! */ + IFolderView_ItemCount(fv, SVGIO_ALLVIEW, &count); + ok(count == 1, "count should've been 1, but was %i\n", count); + + /* cleanup */ + hr = IShellView_DestroyViewWindow(view); + DeleteFileW(test_file_path); + RemoveDirectoryW(test_folder_path); + IShellBrowser_Release(browser); + IFolderView_Release(fv); + IShellView_Release(view); + IShellFolder_Release(desktop); +} + START_TEST(shlview) { OleInitialize(NULL); @@ -1518,6 +1606,7 @@ START_TEST(shlview) test_SHCreateShellFolderView(); test_SHCreateShellFolderViewEx(); test_newmenu(); + test_external_change(); OleUninitialize(); } -- 2.19.1
There was an issue where "new folder" operations didn't show the new folder when performed in certain locations. That issue was caused by a work-around for a another issue where pasting files in certain locations wouldn't show up until a refresh. The reason for those two issues stem from the fact that SHChangeNotifyRegister and SHChangeNotify operate on PIDLs, and there can be multiple PIDLs for a single path. |My Computer|C:\|users| and |/|home|users| for instance. Here we make shell views listen for external changes to their current location (if there's actually a filesystem path associated with it) by spinning up a thread that waits on FindFirstChangeNotification. When a change notification comes in, a message is posted to tell the shell view to update its list view (without re-sorting the list so as to not confuse the user too much -- similar to how Windows does it). As a result, SHChangeNotify is no longer necessary to get ShellViews to update their contents when files change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=30752 Signed-off-by: Nigel Baillie <metreckk(a)gmail.com> --- dlls/shell32/shlview.c | 140 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 131 insertions(+), 9 deletions(-) diff --git a/dlls/shell32/shlview.c b/dlls/shell32/shlview.c index c0c027fbd3..b31b81664e 100644 --- a/dlls/shell32/shlview.c +++ b/dlls/shell32/shlview.c @@ -100,6 +100,9 @@ typedef struct UINT uState; UINT cidl; LPITEMIDLIST *apidl; + WCHAR current_path[MAX_PATH]; + HANDLE fs_listener_thread; + HANDLE change_handle; LISTVIEW_SORT_INFO ListViewSortInfo; ULONG hNotify; /* change notification handle */ HANDLE hAccel; @@ -169,6 +172,7 @@ static inline IShellViewImpl *impl_from_IShellFolderViewDual3(IShellFolderViewDu #define ID_LISTVIEW 1 #define SHV_CHANGE_NOTIFY WM_USER + 0x1111 +#define SHV_UPDATE WM_USER + 0x1112 /*windowsx.h */ #define GET_WM_COMMAND_ID(wp, lp) LOWORD(wp) @@ -573,7 +577,7 @@ static int LV_FindItemByPidl( return -1; } -static void shellview_add_item(IShellViewImpl *shellview, LPCITEMIDLIST pidl) +static void shellview_add_item(IShellViewImpl *shellview, LPCITEMIDLIST pidl, INT index) { LVITEMW item; UINT i; @@ -581,7 +585,7 @@ static void shellview_add_item(IShellViewImpl *shellview, LPCITEMIDLIST pidl) TRACE("(%p)(pidl=%p)\n", shellview, pidl); item.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_PARAM; - item.iItem = 0; + item.iItem = index; item.iSubItem = 0; item.lParam = (LPARAM)pidl; item.pszText = LPSTR_TEXTCALLBACKW; @@ -591,7 +595,7 @@ static void shellview_add_item(IShellViewImpl *shellview, LPCITEMIDLIST pidl) for (i = 1; i < shellview->columns; i++) { item.mask = LVIF_TEXT; - item.iItem = 0; + item.iItem = index; item.iSubItem = 1; item.pszText = LPSTR_TEXTCALLBACKW; SendMessageW(shellview->hWndList, LVM_SETITEMW, 0, (LPARAM)&item); @@ -654,7 +658,7 @@ static HRESULT ShellView_FillList(IShellViewImpl *This) while ((S_OK == IEnumIDList_Next(pEnumIDList, 1, &pidl, &fetched)) && fetched) { if (IncludeObject(This, pidl) == S_OK) - shellview_add_item(This, pidl); + shellview_add_item(This, pidl, 0); } SendMessageW(This->hWndList, LVM_SORTITEMS, (WPARAM)This->pSFParent, (LPARAM)ShellView_CompareItems); @@ -665,6 +669,106 @@ static HRESULT ShellView_FillList(IShellViewImpl *This) return S_OK; } +/********************************************************** +* ShellView_UpdateList() +* +* similar to ShellView_FillList, but only adds new items and deletes absent items +*/ +static HRESULT ShellView_UpdateList(IShellViewImpl *This) +{ + LPENUMIDLIST pEnumIDList; + LPITEMIDLIST pidl; + BOOLEAN *items_to_keep = NULL; + INT item_count, index; + DWORD fetched; + HRESULT hr; + + TRACE("(%p)\n", This); + + /* see how many items we currently have */ + item_count = SendMessageW(This->hWndList, LVM_GETITEMCOUNT, 0, 0); + if (item_count > 0) + { + items_to_keep = SHAlloc(item_count); + ZeroMemory(items_to_keep, item_count); + } + + /* get the itemlist from the shfolder */ + hr = IShellFolder_EnumObjects(This->pSFParent, This->hWnd, SHCONTF_NONFOLDERS | SHCONTF_FOLDERS, &pEnumIDList); + if (hr != S_OK) + return hr; + + /* add new items to the list and keep track of items that are already present */ + while ((S_OK == IEnumIDList_Next(pEnumIDList, 1, &pidl, &fetched)) && fetched) + { + index = LV_FindItemByPidl(This, ILFindLastID(pidl)); + + if (index == -1) + { + if (IncludeObject(This, pidl) == S_OK) + shellview_add_item(This, pidl, item_count); + } + else + items_to_keep[index] = TRUE; + } + + /* remove items that are no longer present. + iterate backward to keep list view indices consistent with items_to_keep */ + for (index = item_count-1; index >= 0; index--) + if (!items_to_keep[index]) + SendMessageW(This->hWndList, LVM_DELETEITEM, index, 0); + + if (items_to_keep != NULL) + SHFree(items_to_keep); + + IEnumIDList_Release(pEnumIDList); + return S_OK; +} + +/********************************************************** +* ShellView_FsChangeListener +*/ +static DWORD CALLBACK ShellView_FsChangeListener(void *parameter) +{ + IShellViewImpl *This = (IShellViewImpl *)parameter; + DWORD wait_status; + + This->change_handle = FindFirstChangeNotificationW(This->current_path, FALSE, + FILE_NOTIFY_CHANGE_FILE_NAME | + FILE_NOTIFY_CHANGE_DIR_NAME); + + if (This->change_handle == INVALID_HANDLE_VALUE || This->change_handle == NULL) + { + ERR("Failed to listen for external filesystem changes\n"); + return 1; + } + + while (TRUE) { + wait_status = WaitForSingleObject(This->change_handle, INFINITE); + + switch (wait_status) + { + case WAIT_OBJECT_0: + if (!PostMessageW(This->hWnd, SHV_UPDATE, 0, 0)) + { + ERR("Failed to post SHV_UPDATE\n"); + return 2; + } + + if (!FindNextChangeNotification(This->change_handle)) + { + ERR("Failed to find next change notification\n"); + return 3; + } + break; + + default: + ERR("Encountered unknown wait status\n"); + return 4; + } + } +} + /********************************************************** * ShellView_OnCreate() */ @@ -692,6 +796,8 @@ static LRESULT ShellView_OnCreate(IShellViewImpl *This) } /* register for receiving notifications */ + This->fs_listener_thread = INVALID_HANDLE_VALUE; + This->change_handle = INVALID_HANDLE_VALUE; hr = IShellFolder_QueryInterface(This->pSFParent, &IID_IPersistFolder2, (LPVOID*)&ppf2); if (hr == S_OK) { @@ -718,6 +824,11 @@ static LRESULT ShellView_OnCreate(IShellViewImpl *This) ntreg.fRecursive = TRUE; This->hNotify = SHChangeNotifyRegister(This->hWnd, SHCNRF_InterruptLevel, SHCNE_ALLEVENTS, SHV_CHANGE_NOTIFY, 1, &ntreg); + + if (SHGetPathFromIDListW(raw_pidl, This->current_path)) + This->fs_listener_thread = CreateThread(NULL, 0, ShellView_FsChangeListener, + (void *)This, 0, NULL); + SHFree((LPITEMIDLIST)ntreg.pidl); SHFree(computer_pidl); } @@ -729,6 +840,17 @@ static LRESULT ShellView_OnCreate(IShellViewImpl *This) return S_OK; } +static void ShellView_OnDestroy(IShellViewImpl *This) +{ + RevokeDragDrop(This->hWnd); + SHChangeNotifyDeregister(This->hNotify); + + if (This->fs_listener_thread != INVALID_HANDLE_VALUE && This->fs_listener_thread != NULL) + TerminateThread(This->fs_listener_thread, 0); + if (This->change_handle != INVALID_HANDLE_VALUE && This->change_handle != NULL) + FindCloseChangeNotification(This->change_handle); +} + /********************************************************** * #### Handling of the menus #### */ @@ -1629,7 +1751,7 @@ static LRESULT ShellView_OnChange(IShellViewImpl * This, const LPCITEMIDLIST *pi case SHCNE_MKDIR: case SHCNE_CREATE: pidl = ILClone(ILFindLastID(pidls[0])); - shellview_add_item(This, pidl); + shellview_add_item(This, pidl, 0); break; case SHCNE_RMDIR: case SHCNE_DELETE: @@ -1678,6 +1800,8 @@ static LRESULT CALLBACK ShellView_WndProc(HWND hWnd, UINT uMessage, WPARAM wPara GET_WM_COMMAND_CMD(wParam, lParam), GET_WM_COMMAND_HWND(wParam, lParam)); case SHV_CHANGE_NOTIFY: return ShellView_OnChange(pThis, (const LPCITEMIDLIST*)wParam, (LONG)lParam); + case SHV_UPDATE: ShellView_UpdateList(pThis); + return 0; case WM_CONTEXTMENU: ShellView_DoContextMenu(pThis, LOWORD(lParam), HIWORD(lParam), FALSE); return 0; @@ -1689,10 +1813,8 @@ static LRESULT CALLBACK ShellView_WndProc(HWND hWnd, UINT uMessage, WPARAM wPara case WM_SETFONT: return SendMessageW(pThis->hWndList, WM_SETFONT, wParam, lParam); case WM_GETFONT: return SendMessageW(pThis->hWndList, WM_GETFONT, wParam, lParam); - case WM_DESTROY: - RevokeDragDrop(pThis->hWnd); - SHChangeNotifyDeregister(pThis->hNotify); - break; + case WM_DESTROY: ShellView_OnDestroy(pThis); + break; case WM_ERASEBKGND: if ((pThis->FolderSettings.fFlags & FWF_DESKTOP) || -- 2.19.1
On 1/9/19 4:52 AM, Nigel Baillie wrote:
There was an issue where "new folder" operations didn't show the new folder when performed in certain locations. That issue was caused by a work-around for a another issue where pasting files in certain locations wouldn't show up until a refresh. The reason for those two issues stem from the fact that SHChangeNotifyRegister and SHChangeNotify operate on PIDLs, and there can be multiple PIDLs for a single path. |My Computer|C:\|users| and |/|home|users| for instance.
Here we make shell views listen for external changes to their current location (if there's actually a filesystem path associated with it) by spinning up a thread that waits on FindFirstChangeNotification. When a change notification comes in, a message is posted to tell the shell view to update its list view (without re-sorting the list so as to not confuse the user too much -- similar to how Windows does it). As a result, SHChangeNotify is no longer necessary to get ShellViews to update their contents when files change.
I think it's conceptually wrong to rely on file paths here, because ShellView should be oblivious to the nature of underlying shell folder. You mentioned unix vs windows path pidls being the issue here, could this be addressed instead, to provide consistent change notifications?
On Wed, Jan 9, 2019 at 12:02 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
I think it's conceptually wrong to rely on file paths here, because ShellView should be oblivious to the nature of underlying shell folder.
You mentioned unix vs windows path pidls being the issue here, could this be addressed instead, to provide consistent change notifications? I see what you're saying.
When I started tackling this, my first instinct actually was to just make SHChangeNotify and SHChangeNotifyRegister "normalize" all incoming pidls into unix-style pidls whenever possible. I wrote a test that calls SHChangeNotifyRegister on |C:\|Users|whatever|My Documents|, then calls SHChangeNotify on the special |My Documents| pidl (from SHGetFolderLocation), but it actually didn't work on Windows. My Windows 10 install, at least, didn't receive notifications when SHChangeNotify and SHChangeNotifyRegister were called with pidls with different-but-equivalent paths. Do you think that's a better solution, though? I can submit that as a patch, too if you'd like. It still somewhat relies on file paths because (do correct me if wrong!) the only way to turn a non-unix-style pidl into a unix-style pidl is to turn it into a file path, then back into a pidl. I decided to go with this FindFirstChangeNotification solution because it doesn't break compatibility (I dunno how crucial SHChangeNotify compatibility is) and has the added benefit of making file browsers respond to external changes just like most native file browsers.
On 1/9/19 9:33 AM, Nigel Baillie wrote:
On Wed, Jan 9, 2019 at 12:02 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
I think it's conceptually wrong to rely on file paths here, because ShellView should be oblivious to the nature of underlying shell folder.
You mentioned unix vs windows path pidls being the issue here, could this be addressed instead, to provide consistent change notifications? I see what you're saying.
When I started tackling this, my first instinct actually was to just make SHChangeNotify and SHChangeNotifyRegister "normalize" all incoming pidls into unix-style pidls whenever possible. I wrote a test that calls SHChangeNotifyRegister on |C:\|Users|whatever|My Documents|, then calls SHChangeNotify on the special |My Documents| pidl (from SHGetFolderLocation), but it actually didn't work on Windows. My Windows 10 install, at least, didn't receive notifications when SHChangeNotify and SHChangeNotifyRegister were called with pidls with different-but-equivalent paths.
That's different case though, it shows that it does not match between path pidl and special folder pidl, when special folder is actual filesystem folder. The issue as I understand is that unixfs is notifying with unix path pidl, while registration was done for windows path. Is it possible to make unixfs notify with windows path pidls instead? I don't know what could possibly break because of that, it needs some testing. Also it's possible to use a number of different flags during registration, no idea what that affects results, but testing that could be helpful too.
Do you think that's a better solution, though? I can submit that as a patch, too if you'd like. It still somewhat relies on file paths because (do correct me if wrong!) the only way to turn a non-unix-style pidl into a unix-style pidl is to turn it into a file path, then back into a pidl. I decided to go with this FindFirstChangeNotification solution because it doesn't break compatibility (I dunno how crucial SHChangeNotify compatibility is) and has the added benefit of making file browsers respond to external changes just like most native file browsers.
I think it's better, because it does not rely on kind of folder you're viewing. I definitely remember testing application that was using default shellview implementation with custom shellfolder instances managed by application itself. Testing custom case like that could also answer the question about how notifications are delivered, which is appropriate to use at shellview side, etc.
On 01/09/19 08:56, Nikolay Sivov wrote:
The issue as I understand is that unixfs is notifying with unix path pidl, while registration was done for windows path. Is it possible to make unixfs notify with windows path pidls instead? I don't know what could possibly break because of that, it needs some testing. Also it's possible to use a number of different flags during registration, no idea what that affects results, but testing that could be helpful too.
Isn't that going to break with wine prefixes that don't have a Z:\ drive and you use an inaccessible windows path? You can still access the files via \\?\unix\ prefix, but they'll be unixfs, right?
On 1/9/19 2:12 PM, Gabriel Ivăncescu wrote:
On 01/09/19 08:56, Nikolay Sivov wrote:
The issue as I understand is that unixfs is notifying with unix path pidl, while registration was done for windows path. Is it possible to make unixfs notify with windows path pidls instead? I don't know what could possibly break because of that, it needs some testing. Also it's possible to use a number of different flags during registration, no idea what that affects results, but testing that could be helpful too.
Isn't that going to break with wine prefixes that don't have a Z:\ drive and you use an inaccessible windows path? You can still access the files via \\?\unix\ prefix, but they'll be unixfs, right? I don't know, have you tried? If the issue is actually about comparing different kinds of pidls, without Z:\ you still get current behavior. Is it even possible to get a IShellFolder for \\?\unix\ path and use it with shell view?
On 01/09/19 13:18, Nikolay Sivov wrote:
On 1/9/19 2:12 PM, Gabriel Ivăncescu wrote:
On 01/09/19 08:56, Nikolay Sivov wrote:
The issue as I understand is that unixfs is notifying with unix path pidl, while registration was done for windows path. Is it possible to make unixfs notify with windows path pidls instead? I don't know what could possibly break because of that, it needs some testing. Also it's possible to use a number of different flags during registration, no idea what that affects results, but testing that could be helpful too.
Isn't that going to break with wine prefixes that don't have a Z:\ drive and you use an inaccessible windows path? You can still access the files via \\?\unix\ prefix, but they'll be unixfs, right? I don't know, have you tried? If the issue is actually about comparing different kinds of pidls, without Z:\ you still get current behavior. Is it even possible to get a IShellFolder for \\?\unix\ path and use it with shell view?
Well currently, parsing \\?\unix doesn't seem to work with the shell, but we do have a pidl for / (unix root), so such a pidl could theoretically be constructed (I'd say it's a current limitation of the shell but obviously an application could enumerate the Desktop and get the pidl for the / folder). But I mean, in such case, what are we going to replace a pidl like |/|usr| into (assuming it's not accessible via any drive letter), as a windows path pidl? Or maybe I'm misunderstanding something?
On Wed, Jan 9, 2019 at 6:23 AM, Gabriel Ivăncescu <gabrielopcode(a)gmail.com> wrote:
Well currently, parsing \\?\unix doesn't seem to work with the shell, but we do have a pidl for / (unix root), so such a pidl could theoretically be constructed (I'd say it's a current limitation of the shell but obviously an application could enumerate the Desktop and get the pidl for the / folder).
But I mean, in such case, what are we going to replace a pidl like |/|usr| into (assuming it's not accessible via any drive letter), as a windows path pidl? Or maybe I'm misunderstanding something? Even if we do have a Z:\ drive, we'd have to decide between C:\ and Z:\ paths. I suppose it could just notify on every equivalent path, defaulting to just using the unix pidl if Z:\ doesn't exist.
On 01/09/19 08:56, Nikolay Sivov wrote:
Also it's
what that affects results, but testing that could be helpful too. possible to use a number of different flags during registration, no idea
That's a good point actually. In the Microsoft docs(1), SHCNRF_InterruptLevel mentions notificatiosn from the *file system* as opposed to the *shell*. Perhaps it'd make sense for shell32/changenotify.c to listen for filesystem events, and dish out shell notifications to listeners with that flag. I'll do some testing on Windows to see if my interpretation of the docs is correct. Does that sound like a better way to approach this? 1: https://docs.microsoft.com/en-us/windows/desktop/api/shlobj_core/nf-shlobj_c...
Looks like that second quote got totally mangled. Sorry about that!
Now that shell views can detect external filesystem changes, it doesn't actually matter whether or not SHChangeNotify from copy/paste comes through. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=30752 Signed-off-by: Nigel Baillie <metreckk(a)gmail.com> --- dlls/shell32/shlview.c | 24 +++++------------------- 1 file changed, 5 insertions(+), 19 deletions(-) diff --git a/dlls/shell32/shlview.c b/dlls/shell32/shlview.c index b31b81664e..e88d1b677d 100644 --- a/dlls/shell32/shlview.c +++ b/dlls/shell32/shlview.c @@ -801,36 +801,22 @@ static LRESULT ShellView_OnCreate(IShellViewImpl *This) hr = IShellFolder_QueryInterface(This->pSFParent, &IID_IPersistFolder2, (LPVOID*)&ppf2); if (hr == S_OK) { - LPITEMIDLIST raw_pidl; + LPITEMIDLIST current_pidl; SHChangeNotifyEntry ntreg; - hr = IPersistFolder2_GetCurFolder(ppf2, &raw_pidl); + hr = IPersistFolder2_GetCurFolder(ppf2, ¤t_pidl); if(SUCCEEDED(hr)) { - LPITEMIDLIST computer_pidl; - SHGetFolderLocation(NULL,CSIDL_DRIVES,NULL,0,&computer_pidl); - if(ILIsParent(computer_pidl,raw_pidl,FALSE)) - { - /* Normalize the pidl to unixfs to workaround an issue with - * sending notifications on dos paths - */ - WCHAR path[MAX_PATH]; - SHGetPathFromIDListW(raw_pidl,path); - SHParseDisplayName(path,NULL,(LPITEMIDLIST*)&ntreg.pidl,0,NULL); - SHFree(raw_pidl); - } - else - ntreg.pidl = raw_pidl; + ntreg.pidl = current_pidl; ntreg.fRecursive = TRUE; This->hNotify = SHChangeNotifyRegister(This->hWnd, SHCNRF_InterruptLevel, SHCNE_ALLEVENTS, SHV_CHANGE_NOTIFY, 1, &ntreg); - if (SHGetPathFromIDListW(raw_pidl, This->current_path)) + if (SHGetPathFromIDListW(current_pidl, This->current_path)) This->fs_listener_thread = CreateThread(NULL, 0, ShellView_FsChangeListener, (void *)This, 0, NULL); - SHFree((LPITEMIDLIST)ntreg.pidl); - SHFree(computer_pidl); + SHFree(current_pidl); } IPersistFolder2_Release(ppf2); } -- 2.19.1
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=46203 Your paranoid android. === wxppro (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w2003std (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === wvistau64 (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === wvistau64_zh_CN (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === wvistau64_fr (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === wvistau64_he (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w2008s64 (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w7pro64 (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w1064 (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === wvistau64 (64 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w2008s64 (64 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w7pro64 (64 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === w1064 (64 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === debian9 (32 bit report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === debian9 (32 bit French report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === debian9 (32 bit Japanese:Japan report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === debian9 (32 bit Chinese:China report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === debian9 (32 bit WoW report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0 === debian9 (64 bit WoW report) === shell32: shlview.c:1581: Test failed: count should've been 1, but was 0
participants (4)
-
Gabriel Ivăncescu -
Marvin -
Nigel Baillie -
Nikolay Sivov