Crise

This time around that message is actually 100% valid (as betas got this message only due to the fact that they were betas)... there is indeed a bug, and thus we do not recommend anyone to keep using anything below 1.1.0. If it's of any consolation under normal circumstances I would have left both 1.0.1 and 0.4.0 as they were. Naturally you are free to do as you choose, however, we kindly remind you that support for anything below 1.1.0 has now been completely dropped and so from now on no member of Management or Support is obliged to provide you assistance of any kind when it comes to these versions.

This one is hopefully sorted in trunk now, can't say for sure though... as I run vista and for me 1.1 ones looked just perfect.

Yeah but I need to make the plugin first :(

Fixed in trunk....

Yep I know, didn't have time to fix this one...

Screenshots, so that I can compare as mine are just fine...

working on it as I write this, need to consult adrian about something though...

Not correct... read SDC changelogs to know why... as we often merge with StrongDC

Yeah, I supose it can, if I'll put that plugin available on the site for general public is another matter though...

Same here, as afaik ApexDC at present is almost complete OP client (ps: there will be no need to make it complete either as RSX & Apex will change to a different CDM in near future)

I would do it as a plugin myself as well, the problem is that doing it as a plugin would force me to remove many checks that exist to prevent abuse.

Always finish current downloads before upgrading... is all I have to say, and please refrain from using such foul language.

Nope, you need to place a shortcut to ApexDC++ in startup folder, not the exe :)

That is not exactly true, though FlyLink++ does have features that make it a bad client in some ways, it is still far better than GreyLink... and despite all of their bad features they do have some that are actually very nice and perfectly acceptable additions. However, for GreyLink nothing will excuse the fact that it breaks GPL.

This is fixed, this is the exception info for the remote crash fixed in 1.1.0 if I am not mistaken.

I did my best to prevent abuse of this feature, however preventing it completely is not possible... At present users are not allowed to block a single ip, plus they can't block all ip's either... and in addition when ip range is blocked it should not affect connections that have already been made. Then of course there is the fact that when ip range is blocked all new connections to it are blocked this includes naturally all incoming and outgoing traffic (so hub connections to and downloads from that range are not allowed either). I personally do not know if this is enough safety measures, but fir some reason unknown to me I really don't want to remove this feature... perhaps because doing so would encourage many users to switch clients into a far worse ones when it comes to features that are harmful to the network.

It's not possible, and I am uncertain if it even will be, though in the long run I am aiming towards that possibility...

Fixed version is coming as soon as possible.

The only genuine way around UAC is through COM moniker as far as I know... simply because you can not elevate an already running process. However, even going through the trouble of learning COM would not help as f.ex. magnet keys are created at program startup... so the elevation popup would still come up almost instantly after application start PS: SDC uses asInvoker (last I checked it did anyways), and we use highestAvailable... there is a slight difference to find that out use google Edit: since you won't google anyways here it is...

I don't know for sure either, but not long ago I checked the transferview and queue & downloadmanager code of apex against SDC and at least I can't see any changes from apex that would affect segment size reporting in any way.

You are wrong there Zlob, WTL update to unedited version did that... not stlport.

That's probably because afaik ADC does not have direct equivalent for $GetNickList, correct me if wrong...

going to need more info, what user command triggered this etc.

Well I haven't looked into it much, but as the gadget api is markup language and jscript only it would need a way to access the plugin to get the information required and after quick look up I see no gadget access to stuff such as SendMessage or FindWindow etc. that would allow direct communication with application components...

yes, until client is restarted finished downloads are shared for partial file sharing.