Icons Revert Back to First Desktop

[OtakuSupport]

Hi Patrick,

The way per-desktop icons work is that you have one set of icons, and you choose which ones are shown and hidden on each desktop. Cutting and pasting won't move icons between desktops, because it just removes an icon from the set and then adds it back in (which is why you saw the behavior with the icon you cut and pasted).

Currently the only way to specify which desktops an icon appears on is via the Manage Desktop Icons dialog. We're working on improving the desktop icon management in the next version of DeskSpace, which will be a free upgrade we will release in the next few months.

[winger]

I've been having similar problems for ages. Currently on v1.5.7.2 with Windows 7 x64.

I've noticed it happens mainly after system crashes like a blue screen, or a force shutdown. Deskspace forgets customised icons and sometimes wallpapers.

The most recent crash (a couple of days ago) was during a video conversion program causing a bad system freeze. So bad that I needed to force shutdown. I was also in the middle of a desktop switch when it froze. When I powered on again all my desktops had the same wallpaper, all icons shown on 1st desktop, all other desktops had no icons and I noticed that Deskspace's manager had the "Show different icons on each desktop" option un-ticked.

At least I know I can back up the settings from now on

[OtakuSupport]

winger: It sounds like the configuration is being reset back to the default, which only occurs when DeskSpace can't read the current configuration.

If DeskSpace is saving its configuration files and the system crashes or DeskSpace is forcefully quit, there's a very good chance that those configuration files will be corrupted, making them unreadable when DeskSpace starts back up.

DeskSpace should handle a normal shutdown gracefully (i.e. telling Windows to shutdown and then waiting for it to finish), and it should also handle all other normal system events without losing its configuration. If you're see DeskSpace losing its configuration after a normal system event (i.e. not a crash or force quit) then let us know and we'll fix the problem.

Unfortunately there's nothing we can do to prevent configuration loss when the system crashes while DeskSpace is saving. Perhaps we can look at implementing a "backup" system, where DeskSpace will create backups of your current configuration each time you boot and then restore these backups if it determines the configuration has become corrupted.

[winger]

The backup feature would be great, but it won't work in the way you've suggested. If it backs up each time you boot, the configuration may have already reverted to default...in which case it will overwrite a good backup.

What would be really nice is backup and restore buttons. So the user can choose to backup once they have everything perfect and restore it if it's lost. A simple "Copy A to B" DOS script would complete the action needed. To be honest, this is such an easy script to write that I'll be disappointed if it's not in the next release

[OtakuSupport]

The backup feature would be great, but it won't work in the way you've suggested. If it backs up each time you boot, the configuration may have already reverted to default...in which case it will overwrite a good backup.

DeskSpace only resets to default when it detects that the configuration has been corrupted. This only happens when DeskSpace first tries to read the configuration file. In the case of a corrupt configuration we'd be replacing the current "reset to default" procedure with two steps:

1. Do we have a valid backup? If so, restore it.
2. If we don't have a valid backup, reset to default.

Note our suggestion doesn't involve backing up configurations that DeskSpace can't read. Only valid configurations (that also weren't the default config) would be backed up, so DeskSpace wouldn't be overwriting good backups with bad.

What would be really nice is backup and restore buttons.

Unfortunately it won't make it into the next version, but configuration import/export is something we'll be adding in the future.

[billp3rd]

I've also begun seeing this with 1.5.7.2. Windows 7 Ultimate, x64. With icons spread over 6 desktops, resetting them is getting tiring. I had previously only seen this, maybe once, but I recently installed Google Desktop and that seems to have exacerbated the problem. Knowing how to back them up helps but it'd be nice to get a fix (not just for me but everyone else who is seeing/has seen this). It's not a problem that I can re-create at will unfortunately.

[OtakuSupport]

billp3rd: This thread deals with a couple of different issues:

a) If Windows crashes while DeskSpace is saving the icon configuration then that configuration is lost.
b) Cutting and pasting an icon between desktops won't work as some users expect, because DeskSpace only shows/hides icons and cutting/pasting actually removes/adds the file the icon represents.
c) Icons are being reset at some other point, but we don't have enough information to reproduce the problem.

It looks like (c) is the problem you're experiencing. We would love to fix it for you, and would really appreciate any information you could provide us.

The first thing to do would be to upgrade to DeskSpace 1.5.8. Next, if you could pin down exactly when the problem happens (and exactly what happens before the icons are reset) we'll have a much better chance of finding and fixing it.

[billp3rd]

Thanks for the quick response. I'm also sure that my case is 'C' as you describe. I've installed 1.5.8 and observed some really bizarre behavior, some of which I can reproduce at will. Where to start...

After installing 1.5.8, everything seemed fine. I then rebooted and all icons were gone, on all desktops. Nowhere to be found. (Before starting all of this, I made a copy of the DesktopIconConfiguration.cfg file.) I opened the .cfg file and found everything set to Hidden. I stopped Deskspace, restored the .cfg file and restarted. All icons back where they belonged. Reboot again (I spent a couple of hours on this, logging off and on, rebooting, etc.)

Reboot again, all icons on desktop 1, stacked in the top-left corner. Stop, restore, restart, icons back.

Switch to desktop 2, reboot. Oh, a neat new feature. Deskspace remembers which desktop was active when I reboot and goes back to it. (I have a different desktop background on each desktop.) No, wait a minute. Those aren't the right icons. But that's background #2 on desktop 1. Hmmm. Go to manage desktop backgrounds and discover that background #2 has also been placed on desktop #1. This is repeatable. Switch to #5, reboot, log on. Desktop #1 now has background #5.

So, later I'm in IE and want to save a picture on the (current) desktop. Right-click and do the "Save As" thing. Fine. No, wait. Where's the icon. Maybe I didn't put it where I thought I did so I open a CMD window in "C:\Users\bparrott\Desktop" and do "DIR *.jpg". There's the file. Check all 6 desktops. No file. Check "Manage/Desktop Icons..." There it is in the hidden list. Back to the command window. Try "TOUCH test.txt" to create an empty file. "DIR". There it is but it doesn't appear on any desktop. Check "Manage/Desktop Icons..." There it is in the hidden list. Try it with notepad. From the command line, "NOTEPAD test2.txt". Answer "Yes" to create the file. Type some text, save, exit. No file. "DIR". Yep, there it is. In every case, new files are automatically hidden on all desktops.

I haven't seen again the icons all showing up on desktop #1 or disappearing entirely. As a precaution, I've created a scheduled task to run hourly and make a copy of the .cfg file. With 82 icons distributed among the desktops, it's just too painful to manually restore them when they go awry.

I'm happy to provide any additional information to help.

[OtakuSupport]

billp3rd: Why these issues didn't show up during the month-long 1.5.8 beta we'll never know

The good news, however, is that DeskSpace 1.5.8.1 (which is available now), should help a lot with these bugs. In the past week we've rebooted 1.5.8.1 thousands of times on our test machines, and both the desktop wallpaper and the desktop icons are always saved and restored correctly*. Our beta testers have also reported that they've been able to reboot without losing settings. How this fix will fair "in the wild" remains to be seen, but we're cautiously optimistic that the problem has been resolved.

In 1.5.8 the icons of new saved files are automatically shown by default, but to do this DeskSpace needs to rely on specific Windows functionality. However, on some computers this functionality either works intermittently, or (as in your case) just doesn't work at all. We've included a workaround for this issue in 1.5.8.1.

--

* With the exception of one very specific desktop icon bug under Windows XP: If auto arrange is disabled on the first desktop and enabled on the second (or other) desktop, then if you ever switch to the second (or other) desktop the desktop icons on the first desktop will always be auto arranged when you restart, regardless of whether or not DeskSpace is running or whether DeskSpace runs when the system boots up again. Note that auto arrange won't be set, it's just that Windows will move the icons to auto arranged positions. At the moment we don't have any way to prevent Windows doing this, but we're looking into it.

[billp3rd]

The icon problem appears to be solved. You tripped me up a bit by changing the way you write the configuration files.

Anyway, the wallpaper problem is still there. I made sure everything was closed, switched to desktop 5, and rebooted. I found the wallpaper from desktop 5 was also on desktop 1.

Thanks for the quick turn-arounds! While most companies will put the customer off "until the next release," whenever that is, you guys get it out in days (and sometimes hours). I don't know if you hear this often, but it is very much appreciated! I'm sure the entire user community agrees.

[OtakuSupport]

billp3rd: Thanks for the kind words, but it's our job to make sure our software works as advertised

Sorry about the change to the configuration files, but it was done so that we'll be able to implement a certain feature in the next major release

Regarding the wallpaper, would you mind if we asked the following questions?

1. What kind of wallpaper are you using (BMP, JPG, PNG, etc...)?
2. Which directory is the wallpaper stored in (you can find this out by going to the Manage Desktop Backgrounds dialog)?
3. What happens if you set the wallpaper for Desktop 1, set the wallpaper for Desktop 5, switch to Desktop 5, and then exit DeskSpace (instead of rebooting)?
4. Does this problem happen for only one type of wallpaper (e.g. PNG), or does it happen for all types of wallpaper?
5. Does this problem only occur when rebooting from Desktop 5, or does it happen when rebooting from any desktop?
6. When you initiate a reboot, do you see the desktop being reset to Desktop 1 just before the reboot actually takes place?
7. Is the wallpaper reset every time you reboot, or only sometimes?
8. Is the problem the same whether you restart, shutdown, or log off?

[billp3rd]

Having authored my share of software over the years, I've found that users are quick to complain but if everything's going well, you never hear from them. I just wanted to make sure that you knew that your efforts and fantastic support are appreciated.

Back to the matter at hand:

1. jpg
2. C:\Users\Public\Pictures\Country Theme Photos\
3. The wp on desktop 1 is correctly preserved.
4. I haven't tried any other than the jpgs.
5. From any desktop
6. No (and I watched carefully )
7. Every time.
8. Logging off will do it.

FYI: I've save the output from msinfo to http://renton.jayhawk.net/DeskSpace/

[OtakuSupport]

billp3rd: Thanks again

When you shutdown/restart/logoff your computer, apps only get a short period of time to "cleanup" and exit. During this time, DeskSpace has to reset the icons and wallpaper to the Desktop 1 icons and wallpaper. The same code is executed to perform this cleanup whether you quit DeskSpace manually or force it to quit via shutdown/restart/logoff.

This code is works on your machine when you manually exit DeskSpace, and is at least resetting the desktop icons when you quit via shutdown/logoff. We've also seen it fully working on our test machines (XP, Vista 32-bit/64-bit, and Windows 7 32-bit/64-bit).

Therefore we think is happening on your computer is that our wallpaper change request is executing correctly, but that Windows is simply ignoring it. This is probably a timing issue: by the time the system tells DeskSpace it should quit there might not be enough time to change the wallpaper.

There's a number of approaches we can try:

1. See if there's any way we can make the wallpaper reset process faster.
2. See if we can hold up the shutdown process until we've had time to change the wallpaper (undesirable).
3. Add an option to have DeskSpace restore the wallpaper of Desktop 1 when it starts up (this could potentially overwrite any wallpaper changes you've made between the time you shutdown the computer and the time you next run DeskSpace).
4. Eliminate the need to reset the desktop wallpaper and icons by having DeskSpace remember which desktop it was last on, and automatically switch to that desktop the next time it starts up. This would only work if DeskSpace was set to run at start up (which we believe is the way most people use it), however, as otherwise you'd be stuck with the settings of the desktop you shutdown from.

If you can think of any other ways we could handle this problem, please let us know.

Our particular preference is #4, as it means we don't have to run the timing gauntlet during the shutdown process (#1), don't have to start interfering with Windows shutdown mechanics (#2), and don't have to perform potentially "destructive" changes to a users settings (#3).

If we went with #4 then we'd probably want to make it non-optional. Please let us know what you think, we'd really like to hear about how you'd like this feature to work, or any potential concerns you may have about it.

[billp3rd]

Sorry for the tardy reply. So...

#1 This seems impractical because you have no way of knowing how fast is fast enough on every platform. After all, on my rather run-of-the-mill laptop, it apparently isn't.

#2 This one may be easier than you think. I started programming for WIndows when it was Windows 1.0 and everything was done in the message loop. (Really!) You could run a separate thread that did nothing but look for the WM_QUERYENDSESSION message in the message loop. When it sees it, you could just not respond until everything was adequately and safely put to bed. I believe that the delay would be unnoticeable, even if you were look specifically for it. As for interfering with the Windows shutdown process, that's exactly what WM_QUERYENDSESSION is meant for. ""Hey!! Hang on a sec. I'm not quite done here!!!"

#3 Probably not as onerous as you think. As you say later, I'd doubt that very many DeskSpace users shut it down manually very often. They run it at startup and let the Windows deal with it when they log off. You'd be rarely be making "destructive" changes to a user's settings. As far as it goes, you could actually condition your actions on the reason the user is exiting DeskSpace. Is it a shutdown or is the user just closing up for some reason.

#4 I really like this idea as an option. "Remember where I was when I logged off and return me there when I restart."

So there you have it. My thoughts on your thoughts.

[OtakuSupport]

No problem, we're glad to hear from you

#1. It's not our preference either, and there's not much we can do to make it faster anyway (we're just calling the relevant API functions).

#2.

As for interfering with the Windows shutdown process, that's exactly what WM_QUERYENDSESSION is meant for. ""Hey!! Hang on a sec. I'm not quite done here!!!"

This is what DeskSpace does already - it resets the desktop wallpaper and icons on a WM_QUERYENDSESSION, and only after that's complete does it let Windows know that it can go ahead with the shutdown. The whole reason this bug is showing up on your computer is that by the time we get a WM_QUERYENDSESSION message, Windows 7 has already decided it's going to shut down anyway, and so decides to ignore our wallpaper change request. Ah, the wonderful world of Windows programming

#3. It won't affect most users, but it will affect some, and the minority are always the most vocal. We could look into how we could guess what's the best course of action to take, but honestly we think that we're better off pursuing option #4.

Thanks again for your feedback.