Menu items not always selectable

[Andy Willis]

When using the standalone lswitch.exe (not the xcenter widget) menu items for either killing tasks or switching between tasks are not always selectable.
Ctrl click on the dekstop icon on the taskbar to bring up the process list and click on a process to kill it. If there is no application beneath it (IOW just the desktop) it will work. However, if an application (such as 4os2, Firefox, pmcamera, etc) the mouse click will pass through to the application and give it focus. It does appear that up to the first 4 (starting at the button) will work even if there is something under them (though not always 4, sometimes only 2 or 3 but I have not been able to determine what is happening then).
This can also be reproduced by using shift click instead of ctrl click on the desktop button.
I will attach a screenshot, in it PmCamera/2 is behind part of the menu, any part that it is behind would cause the click to pass through to it to get focus but any part it is not behind (such as the left side of daytime.exe at the top of the menu) would work correctly as would all of xwpdaemn.exe. Sometimes, as my mouse goes over a section of the menu that is covering another application (esp. Seamonkey mail it seems) there may be bleed through so that I start seeing some of the application in the menu where.

[Andy Willis]

I have determined that the WinPopupMenu() that is calling the menu is in the following code section of taskbar.c:

    if (((msg==WM_BUTTON1UP && WinQueryMsgTime(plswData->hab)-ulBtnDnTime>WinQuerySysValue(HWND_DESKTOP,SV_DBLCLKTIME) && !bShiftKeyDown)||
        (msg==WM_BUTTON1CLICK && ((SHORT2FROMMP(mp2)&KC_SHIFT)^(SHORT2FROMMP(mp2)&KC_CTRL)))) &&
        IsDesktop(plswData->TaskArr[sItem].hwnd)) {
      SWP swp;
      POINTL ptl;
      SHORT sItems;
      USHORT usItemHgt,usFrameWid;
      LONG lMenuCol;
      BOOL bMenuProcMode;

      bMenuProcMode=(SHORT2FROMMP(mp2)&KC_CTRL);
      FillTaskMenu(plswData->hab, plswData->hwndTaskMenu,plswData->Settings.sTskBarCY,bMenuProcMode);
      WinQueryWindowPos(hwnd,&swp);
      ptl.x=swp.x; ptl.y=swp.y;
      if (plswData->Settings.bTaskBarTopScr) {
        if (bMenuProcMode) {
          POINTL aptl[TXTBOX_COUNT];
          HPS hps=WinGetPS(plswData->hwndTaskMenu);
          GpiQueryTextBox(hps,1,"M",TXTBOX_COUNT,aptl);
          usItemHgt = (aptl[TXTBOX_TOPLEFT].y-aptl[TXTBOX_BOTTOMLEFT].y)*6/5;
          WinReleasePS(hps);
        } else
          usItemHgt=WinQuerySysValue(HWND_DESKTOP,SV_CYICON)/2+2*BUTTONBORDERWIDTH+2;

        sItems=MenuItemCount(plswData->hwndTaskMenu);
        usFrameWid=WinQuerySysValue(HWND_DESKTOP,SV_CYDLGFRAME);
      }
      WinMapWindowPoints(WinQueryWindow(hwnd,QW_PARENT),HWND_DESKTOP,&ptl,1);
      if (plswData->Settings.b3DTaskBar) {
        LONG lTskBarCol = plswData->Settings.lTskBarRGBCol;
        lMenuCol = ((lTskBarCol&0xFF)+240)/2+(((lTskBarCol&0xFF00)>>8)+240)/2*256+(((lTskBarCol&0xFF0000)>>16)+240)/2*65536;
      } else
        lMenuCol = plswData->Settings.lNormalBtnRGBCol;
      WinSetPresParam(plswData->hwndTaskMenu,PP_MENUBACKGROUNDCOLOR, sizeof(lMenuCol), &lMenuCol);
      WinPopupMenu(HWND_DESKTOP, hwnd, plswData->hwndTaskMenu, ptl.x,
                   ptl.y+(plswData->Settings.bTaskBarTopScr?-sItems*usItemHgt-2*usFrameWid:swp.cy),
                   usHswActive, PU_HCONSTRAIN | PU_VCONSTRAIN | PU_MOUSEBUTTON1 | PU_KEYBOARD |
                   ((SHORT)WinSendMsg(plswData->hwndTaskMenu,MM_ITEMPOSITIONFROMID,MPFROM2SHORT(usHswActive,0),0)!=MIT_NONE?
                  PU_SELECTITEM:0));

I made that determination by changing the ptl so that it moved the menu around (which still exhibited the same issue).
I've tried changing:
WinMapWindowPoints(WinQueryWindow(hwnd,QW_PARENT),HWND_DESKTOP,&ptl,1);
to
WinMapWindowPoints(hwnd,HWND_DESKTOP,&ptl,1);
with no change (so much so no change I don't know why it is specifically looking for the frame window handle instead of just using the hwnd).
I also tried changing the owner of the menu:

plswData->hwndTaskMenu=WinCreateMenu(HWND_DESKTOP, NULL);

to

plswData->hwndTaskMenu=WinCreateMenu(hwnd, NULL);

this resulted in no change either (I don't understand why the owner isn't the hwnd instead of the desktop but I could tell no difference in the way it functioned... to the good or bad.
I also found an edm2 article that said that PU_NONE was needed with PU_SELECTITEM so I added it but it made no difference.

[Andy Willis]

I also had removed:

|
                   ((SHORT)WinSendMsg(plswData->hwndTaskMenu,MM_ITEMPOSITIONFROMID,MPFROM2SHORT(usHswActive,0),0)!=MIT_NONE?
                  PU_SELECTITEM:0)

from the WinMenuPopup call which made no noticeable change so I am not even sure what it is doing.

[Andy Willis]

Shows bleed through of underlying application.

[Andy Willis]

Attached screenshot of menu after moving mouse over menu and subsequent bleed through of underlying window that sometimes occurs also. My thought is that it must be related but not certain that it is and if it is it hasn't helped me isolate the cause as of yet.

[Andy Willis]

The OS/2 Warp Presentation Manager API book says that after WinCreateMenu there should be a call to WinSetWindowUshort should be called to change the window identifier (if the parent already has a an action menu). It then says to call WM_UPDATEFRAME.
I cannot tell when the WM_UPDATEFRAME should be called (after WinCreateMenu or after WinPopUpmenu).
I was not certain if this could be part of the issue so I tried this and tried the WM_UPDATEFRAME after both (above) but it did not make any difference.

[Andy Willis]

The OS/2 Warp Presentation Manager API book says that after WinCreateMenu there should be a call to WinSetWindowUshort should be called to change the window identifier (if the parent already has a an action menu). It then says to call WM_UPDATEFRAME.
I cannot tell when the WM_UPDATEFRAME should be called (after WinCreateMenu or after WinPopUpmenu).
I was not certain if this could be part of the issue so I tried this and tried the WM_UPDATEFRAME after both (above) but it did not make any difference.

[Gregg Young]

I think this is a zorder issue. The taskbar needs to stay visible until the menu operation is complete. It currently moves behind the other window as soon as the mouse pointer move away from it (down the menu). The relevant code is in lswhook.c (lswInputHook) code around line 155. I think the following call needs to be proceeded by a check to see if a menu is open and wait if it is (while (menu visible)

DosSleep(100);)

WinSetWindowPos(plswData->hwndTaskBar,

bOnTop ? HWND_BOTTOM : HWND_TOP, 0, 0, 0,
0,
SWP_ZORDER | (plswData->Settings.

bTaskBarAlwaysVisible ? 0
: (bOnTop ? SWP_HIDE :

SWP_SHOW)));

[Andy Willis]

The following alleviates the problem... I don't figure it is the correct fix. as I don't understand how the portion that I commented out is supposed to work) but the only side effect I have seen so far is that sometimes the Desktop button on the lswitcher taskbar appears highlighted when it is first opened and subsequently if you do a shift click and change to another application and then close that application then too the Desktop icon will appear highlighted.

		    WinSetWindowPos(plswData->hwndTaskBar,            
				    bOnTop ? HWND_BOTTOM : HWND_TOP, 0, 0, 0,       
				    0,                                              
//				    SWP_ZORDER | (plswData->Settings.             
//					bTaskBarAlwaysVisible ? 0                     
//					: (bOnTop ? SWP_HIDE :                        
//		        		     SWP_SHOW)));                               
                    SWP_SHOW);                          
		    bOnTop ^= TRUE;                                   

[Andy Willis]

The "side effect" is normal... the desktop was next in line to get focus and the icon is the Desktop icon afterall so it was just showing it. I only realized what I had been seeing when following the steps above did not produce the same results but then I clicked on the desktop and low and behold, duh.

[Gregg Young]

It works because it prevents the taskbar from being move from HWND_TOP to HWND_BOTTOM by SWP_ZORDER. The problem with the "fix" is it leaves the taskbar on top of what ever program it jumped in front of and it breaks auto hide. Unfortunately just putting in a DosSleep won't work because it blocks the input from the menu. We could move the show hide code to a separate thread or we could use a timer for hiding the code and only use the WM_MOUSEMOVE to show it.

[Gregg Young]

I did try to prevent the taskbar from disappearing by checking for the context menu being visible but I couldn't get it to work. I probably failed to figure out which hwnd it is but that means that it isn't one of the ones in the lswitcher struct.

[Gregg Young]

CS 42 is an attempt to fix this using a timer to delay hiding the taskbar. It works but is the delay of appropriate length?

[Andy Willis]

It'll take some getting used to... I am at times waiting for it to hide and at others having to reopen the bar. However, even when the bar closes the popup will stay open and can still be actioned so I think I could get used to it. I'd say it is probably fine for the next release but we should probably put in an enhancement request as a reminder to add an option for time till hide.
Hmm, one issue I just noticed as I was typing this:
the bar is not hiding. If the bar has focus it seems to hide (though possibly only if the mouse is over it without moving). If I set it so that the xwlan widget is beneath the bar then after the 5 seconds then instead of the bar hiding the widget will show up (at least sometimes).

[Andy Willis]

Also, I find that once it does hide it doesn't always want to resurface when I bring my mouse down to the area.

[Andy Willis]

It seems that clicking on another program while the timer is running (at least on Seamonkey so far I can say for sure) causes the hiding to stop functioning.

[Andy Willis]

OK, it actually appears that just putting the mouse over another application is enough... seen with Seamonkey and 4os2.

[Gregg Young]

I have committed an improved fix. It addresses the issues above. I needed to invalidate the rectangle to force a repaint if the taskbar had lost focus, The taskbar doesn't hide as long as the mouse button is over it. It hides in 500 msecs when you move the mouse away but the menus persist and are usable.

[Gregg Young]

CS [47]