Removing a button sometimes fails to reclaim the space it occupied on the taskbar

[Gregg Young]

Perhaps this can be achieved with a timer (every 5 seconds perhaps) that runs:

WinSendMsg(plswData->hwndTaskBarClient,
           LSWM_INITBUTTONS, 0, 0);

Need to do the same checks as TSKHIDEDELAYTIMERID. Probably best not to do it with the mouse over the bar and with z-order not top or with the bar hidden.

[Gregg Young]

Need to check for the subwindow menu for the widget as checks above except mouse over won't work.

[Gregg Young]

Perhaps we can run through the buttons doing the same check as would be done for bubble help and only refresh if it fails on one of them.

[Lewis Rosenthal]

Milestone renamed

[Lewis Rosenthal]

This seems working to me (2.82r), except for known instances (completed sessions). Am I missing a scenario to trigger this?

[Gregg Young]

The scenario is in Arca Noae ticket 1477 ​https://mantis.arcanoae.com/view.php?id=1477
It is the completed command shell issue. I have not found a reliable way to identify the window so I can remove it. It should be documented in the known issues section. Closing and reopening the taskbar or XCenter removes it.

[Lewis Rosenthal]

This is documented in the Known Issues section:

Under certain circumstances, a "phantom" button may be left on the Taskbar. When this happens, a "phantom" entry is also left in the OS/2 Window List. The cause appears to be one application started from another application using a command shell which ends with an open command shell titled Completed: program name (e.g., starting Mplayer from Firefox to play a video). The workaround is to close and restart lSwitcher.

So, let's keep this open in the interim, and just kick it to a future milestone. Is this only for the widget? I think this should be core.

[Gregg Young]

I would keep it open. I should probably ask Steven about it. I also need to see exactly what info remains in the switch list when this happens.

[Gregg Young]

The button icon is has 2 different storage locations. Since the icon is clearly missing perhaps checking both of these will give a basis for removing a phantom button without removing any good buttons.

[Gregg Young]

This is a PM defect. The PM windows list (which is where lSwitcher gets "change" information from) loses track of some VIO windows that start PM processes. These windows will finish with "Completed someprogram". While they remain in the windows list they are no longer in the switch list.

Since the windows list never signals lSwitcher that the window is gone the remove code is never called leaving the button. When the buttons are updated the lack of information in the switch list removes the menus, icon etc. I need to determine what is left of the button so I can call the remove code(using the switch list isn't possible). This is probably best done with an enumeration of the button windows. The problems are how to identify the phantom and where to put the enumeration (?timer check every 1 sec?). Repeatedly checking this would be expensive but I don't see what signal I can look for. I could also do this every time the update code runs (also expensive).

The workaround is to add known problem windows (mplayer.exe & cppcheck-gui.exe) to the exclude lists.

[Gregg Young]

It might be possible to remove the entry from the windows list. That would require keeping a list of window titles, checking to determine which was orphaned and then sending a message to the window list to remove it. This assumes the window list would accept and process a message from the hook. I am inclined to just document this issue and do nothing else about it.