Custom Query (8 matches)

Version 1.0.16:

Refreshing an open folder multiple times will lead to nested invocations of "wpRefresh" that compete with each other (and starting multiple refresh threads).

I suggest this change, so that "wpRefresh" will not be called nested (src\classes\xfldr.c):

SOM_Scope BOOL  SOMLINK xf_wpRefresh(XFolder *somSelf,
                                     ULONG ulView,
                                     PVOID pReserved)
{
    BOOL        rc;
    ULONG fFlags;

    // XFolderData *somThis = XFolderGetData(somSelf);
    XFolderMethodDebug("XFolder","xf_wpRefresh");

    fFlags = _wpQueryFldrFlags(somSelf);

    if (fFlags & (FOI_REFRESHINPROGRESS | FOI_POPULATEINPROGRESS))
    {
       return FALSE;
    }

   _wpModifyFldrFlags(somSelf, FOI_REFRESHINPROGRESS,FOI_REFRESHINPROGRESS);

    rc = XFolder_parent_WPFolder_wpRefresh(somSelf, ulView, pReserved);

    fdrForEachOpenInstanceView(somSelf,
                               stb_UpdateCallback,
                               2);           // update

    xthrPostWorkerMsg(WOM_REFRESHFOLDERVIEWS,
                      (MPARAM)somSelf,
                      (MPARAM)FDRUPDATE_TITLE);

   _wpModifyFldrFlags(somSelf, FOI_REFRESHINPROGRESS,0);

    return rc;
}

It might also be better to move the "_wpModifyFldrFlags(somSelf, FOI_REFRESHINPROGRESS,0);" call to the window function invoked by "xthrPostWorkerMsg" (src\filesys\xthreads.c):

MRESULT EXPENTRY fnwpWorkerObject(HWND hwndObject, ULONG msg, MPARAM 
mp1, MPARAM mp2)
{
    MRESULT mrc = NULL;

    switch (msg)
    {
...
        case WOM_REFRESHFOLDERVIEWS:
        {
            XFolder     *pFolder = NULL,
                        *pCalling = (XFolder*)(mp1);

            for ( pFolder = _wpclsQueryOpenFolders(_WPFolder, NULL, QC_FIRST, FALSE);
                  pFolder;
                  pFolder = _wpclsQueryOpenFolders(_WPFolder, pFolder, QC_NEXT, FALSE))
            {
                if (    (wpshCheckObject(pFolder))
                     && (_somIsA(pFolder, _WPFolder))
                   )
                {
                    if (    (!pCalling)
                         || (wpshResidesBelow(pFolder, pCalling))
                       )
                    {
                        // folder applies:
                        fdrUpdateAllFrameWindows(pFolder, (ULONG)mp2);
                    }
                }
            }
            if (pCalling)
            {
               _wpModifyFolderFlags(pCalling,FOI_REFRESHINPROGRESS,0);
            }
        }
        break;
...

using XWP 1.0.13:

there are three named event semaphores that are using by the "WinWaitForShell" API function so that this function can block on (or being polled for) these 3 events: Desktop created, Desktop opened, Desktop populated.

The named event semaphores are: \SEM32\WORKPLAC\SHELL1WT.SEM (for Desktop created) \SEM32\WORKPLAC\SHELL2WT.SEM (for Desktop opened) \SEM32\WORKPLAC\SHELL3WT.SEM (for Desktop populated)

These 3 event semaphores are created by the 1. instance of PMSHELL.EXE but they are opened and set by the 2. instance of PMSHELL.EXE.

The problem is, that on XWP function "WPS restart", the 2. instance is just terminating thread 1 (which leads to process termination) without resetting these event semaphores. If the WPS is then restarted and an application also starting up (or the WPS) is using "WinWaitForShell" waiting for the desktop to be created/opened/populated respectively, the "WinWaitForShell" API call will return immediately without blocking because the event semaphores are still set. This typically leads to hang problems and the like because the WPS is typically not in the state that the application/WPS class expects it to be after returning from "WinWaitForShell". One indication of such might be WPS classes installed via WarpIn and requiring a WPS restart to become active where the WPS restart will lead to a system hang.

I propose to reset these 3 event semaphores shortly before the 2. instance of PMSHELL.EXE terminates its thread 1 (on a "WPS restart").

Hello

On machines with higher resolutions like 1,920 x 1,080, I usually increase the size of XCenter to a more confortable size. But there is the issue that icons size on any widget remains the same.

I was wondering if something can be done so the user can increase the size of the icons of XCenter.

Regards