Crise

Unfortunately no, all I can say is hopefully soon... but that's about it.

Hash data remains, only the share entry is removed... In other words all you need to do is re-add the removable storage to share, rehashing is not usually necessary (and thus you should see your share back instantly after re-adding the removable storage back to share).

Not quite correct... what it does (afaik) is trim away nonexistent or duplicate entries... In any case... you'll see a message in statusbar/system log when it's done rebuilding, after that try restating apex.

For now, try disabling DHT if you have that enabled... should be sorted in next version.

Which help file... in any case it was changed and that was intentional.

You are aware of the difference between 32bit and 64bit binaries (ie. that you can not run 64bit apps on 32bit OS).

Do you use the Lua plugin?

Sorry my mistake... I should have checked my facts, I completely forgot about the VirtualStore in AppData. When Apex does this it is requesting the TTH tree for the file/chunk (the blinking that you describe is probably caused by not being able to write that data into a file), the problem in question is pretty common when Apex is in local mode and can't write to the "Settings" directory.

Easy with the font size... also is there any point in telling us what you are going to do . I already stated in this topic that in next version the behavior would be back to "normal" so your post holds no value in my eyes. Also it is wrong to call it defective since the change was intentional but oh well...

There is no security needed, since I initially said that if you deleted the dcppboot.xml file you'd then have to manually copy your settings from AppData (hidden system directory on your windows drive) and move them to the correct location under ApexDC's own directory. The reason why your favourites were "wiped" is because you did not move those files back so it created new ones but it is pretty likely that the settings files are still intact in AppData.

About ProgramData... that is for visualization (ie. what windows uses for legacy apps that don't have the UAC awareness indicated by manifest). While I suppose it would be possible to force an UAC aware app like ApexDC to use that directory but really I don't think any apps should write files in there directly. What windows does is use that folder to write the files when an old application (that isn't UAC aware so to speak) tries to write to say Program Files directory. After looking at that list of files all I can say is that the files themselves have been moved correctly (well they might also have been recreated, but then you could probably tell since some of your settings would likely have been lost, like sy the hash data.)

You can also delete the dcppboot.xml. In which case you have to copy your old settings back from AppData manually though...

That shouldn't be possible... actually assuming all files get saved where they are supposed to be saved there shouldn't be any permission issues. Can you check your AppData and tell what files are in each of the "ApexDC++" directories.. just to see if everything gets created/moved correctly. Edit: I assume your finished downloads directory also exists and is "writeable"

This shouldn't have happened I'll look into it... Anyways if you got a crash mind sharing the exceptioninfo.txt file that should be in your ApexDC directory...

Hmm, what are your downloads and temporary directories set to, in settings?

Make sure you don't mix and match ie. 32bit exe means you need 32bit plugins as well... that error is most likely caused by that exactly. Also use the binaries from:

Hmm, I didn't know of the drag and drop.. I knew that it could be made always visible though the settings though. I also realized that I should have just changed the Minimize to Tray default value to be off rather than code the behavior for win7 static though. The only drawback with that though is that people that just upgrade to Win7 will still have the enabled so they might have hard time finding the tray icon at first, since windows likes to hide them. Oh well now all I need to figure out is why I didn't just change the default to begin with...

Now, now... it's bad to generalize so much . Because I am on Windows 7 and do not happen to minimize my Apex to tray, not even before this change was made... why? Because the tray icon gets hidden by windows by default, and it is bothersome having to click the "Show hidden icons" (especially since that opens upwards rather than sideways now) to get to it. Just for the record when I was still on Vista/XP I used to minimize to tray as well. I am well aware that the taskbar can be changed to one that looks and functions lot more like the taskbar on earlier versions of windows but I also happen to primarily be on a smaller screen (a laptop), so in my case this new behavior of the taskbar (and Apex) is much more compact and faster to use. Also we have to consider how Windows 7 comes out of the box, because many less advanced users do not even know how to adjust the taskbar look. It is also a matter of things working the same way. I have Apex pinned to taskbar and when it was still minimizing to tray I used to click the pinned shortcut and get the "An instance of..." dialog at times because I had already gotten used to the shortcut becoming the taskbar button with other apps I use. While right now many apps do not yet make use of the new features of the taskbar in windows 7, over time that will increase and the phenomena I described above will become more common.. right now apps that use the new taskbar features will stick out but eventually it will be the other way around.

I have yet to figure out how to "fix" the exception infos on post XP systems for end users (since even though they get generated they are lot less informative than those coming from XP based systems) despite looking into it several times. (it could be that I am missing something really obvious though).

Doesn't necessarily have to be a chm... pdf f.ex. would work as well (although chm does have some nice search features and such)

None that I know of... well of course windows on windows execution will do some other things differently as well (so it's not the same as an on/off in settings would be). But as far as I am aware in ApexDC's case that will have no noticeable impact on anything.

This change won't be reverted... that's why the bit about compatibility mode was documented in changelog (and it actually needed some research to get the compatibility mode to do it like that). In other words... if I was planning to revert the change I wouldn't have gone through the trouble of making sure compatibility mode can be used that way with 1.3.1. Here is another post about this: It's for people like you that the compatibility mode was made to be able to revert the behavior. The rest I could say here would just repeat what I have already said in this topic and in the topic I linked to. Edit: about compatibility mode... right click on ApexDC.exe click properties and choose the compatibility tab... rest should be obvious.

Could it be that your ISP is throttling your connection for p2p traffic?

You are not exactly correct about that... but regardless to all the rest of you posting those exception infos I am aware of this (another stupid mistake by me) and I have said elsewhere that it will be fixed in next version. So it's no use posting the same exact exception info over and over again. Not like it will be fixed any fater if you keep uploading the file over and over again. (When posting exception infos you should check if an identical one has been posted already).

It's not that we don't understand... the behaviour of that checkbox will be changed slightly with next version to address these issues (ie. the old behavior of "Update IP on startup" will be merged to the "Update IP on DHT firewall check").