Custom Query (74 matches)

This used to work correctly with 2.7.0.

Consider:

• xPager configured for 3x2 virtual desktops. Start in lower left desktop.
• Dave Saville's ClipView minimized, and configured as sticky in xPager
• Restore ClipView from taskbar. ClipView opens in lower left of current desktop.
• Minimize ClipView.
• Restore ClipView. ClipView again opens in lower left of current desktop.
• Switch desktops.
• Restore ClipView. ClipView is restored off the bottom of the lower left window, requiring Alt-F7 to position it in any virtual desktop.

Expected behavior:

Windows restored from lSwitcher's taskbar, if set to sticky in xPager, should restore to the same relative position on the current desktop (as I say, this used to work).

I have not tested with the widget, as I don't use it. Restoring from popup window is also inconsistent, but app window shows up in yet a different spot (to the left or right of the current virtual desktop).

Taskbar settings:

Switch to PM from FS Show hints No sticky popup window No popup window exclusions Taskbar enabled Auto-hide Flat buttons 3D look Default icons only Bottom of screen No taskbar exclusions

Note files attached.

TRP files are created at system shutdown (using XWP Xshutdown) and when manually closing lSwitcher from the context menu.

Also, xshutdwn.log excerpt attached (goes with 0070_02.TRP).

This may or may not be an lSwitcher issue, but as I have observed the problem consistently when lSwitcher has been running, and then repeating my steps after closing lSwitcher following yet another reboot, and having those objects create normally, this should probably be documented.

I am using the "fixed" 2.81 exe. Kernel is 14.106_W4, on eCS 2.1, ThinkPad T43, SNAP, ATI X300, 2.26GHz Pentium M Dothan. Desktop is on the boot volume (C:), which is JFS.

1. I downloaded the OpenOffice 4.1.1 RC3 non-debug version and unzipped to j:\PROGRAMS\OpenOffice 4.
2. I created a new folder for OO4, and copied the folder icon from OO3.2.
3. I first tried copying all of the objects from the OO3.2 folder to the new OO4 folder, and then edited the paths one by one to reflect the new locations (I did not uninstall OO3.2, so all of those objects remain valid).
4. The exe's have the ugly icons in them, so I then selected all of the new objects, went to Properties from the context menu, which opened them all, and then painstakingly dragged the OO3.2 icons for each to the new objects for OO4. I then had to edit the names of a couple of them.
5. I closed the desktop folders and rebooted, saving the ini files using XWP 1.0.9's INI routines as set from the Desktop xShutdown page.
6. Upon restarting and opening the folder, all of my new icons were gone.

I repeated the above several times, in several different ways (open the drives object, browse to the program directory, open it, select all of the exe's, right-click, select Create Program Object, etc.), and still I had inconsistent results. Sometimes, only a few of the objects would be missing, and not all of them. Usually the URL object for the readme was okay.

DMT (which I have installed under eCS 2.1, on this machine) even created a folder of lost objects, and three of the objects were recovered, sans their new icons and corrected titles (i.e., with ugly program icons and exe names).

In between, I even deleted and recreated the folder, and created it on the desktop instead of under Programs, all with similar results.

Finally, I booted the machine, closed lSwitcher upon desktop init, and created the folder contents again (all items were missing except Text Document, Open document..., Math, and the README URL). I shut down and rebooted, and the older contents came up intact. UniMaint shows no errors, and neither does checkini (which both came up with errors during my previous attempts).