Rigor O'Mortis

`scuse me. How did you get rid of unwanted downloads until now? Have you not heard of deleting entries from download queue? I mean, how difficult could it be to go to "Download Queue", locate the file you do not desire anymore and delete it! The "close connection" does exactly what it's supposed to do: it closes the connection you selected. That doesn't mean it also permanently stops the download. "Remove user from queue" will stop downloading from that user and make ApexDC++ "forget" that it has the files you wish to download. That, of course, until something is done to re-add him to the queue. This is user-based, so nothing is done about the actual file. There is no "cancel download" button or menu option in the download window, and it is my opinion that things should remain that way for the sake of download file integrity. That having covered the basics, are you actually saying that ApexDC++ attempts to re-download over and over and over again, even after the file has been removed from queue? Can you check whether or not the queue appears to be correctly written in the XML file upon exit? Oh, and, related to the alternation between "download starting" and "download finished" - this is segmented download... download is "finished" every time a segment is finished, and it is "starting" immediately as Apex gets the next segment. The rapid alternation is probably due to a very good bandwidth or very small segments. Naturally the download counter appears to be downloading continuously... ApexDC++ actually does that. Being on hubs with MANY users and lots of activity, downloading many things at the same time, activating IPGuard with many entries and having an overcrowded queue is also known to take your CPU past 20%.

Wow, that "someone is trying to use your client to ..." really did spark up some discussion. People have failed to notice that I said "on the same hubs in the same conditions, Apex 1.2.0 Beta complains while Apex 1.1.0 does not". I did make the effort of sorting through some debug messages, and it seems that indeed, $ConnectToMe messages were coming on HTTP, FTP or HTTPS ports (have no idea how the heck they set them up that way, or why), but appeared to be valid, meaning that that IP had sent other messages before and appeared to be an actual client, and not a spam victim. Now in the interest of keeping spirits cool, I must say that the chances of this message appearing are one in 500.000 users, but nevertheless, I do know quite some people that exceed that possibility by 3-5 times, connecting to so many hubs that 7 rows of tabs aren't enough to display them all. Anyway, this "issue" is minor. I'd be happy to see the CPU bugs sorted out nicely, the automatic IP fetching solved and proper ADCS standards (for now, excuse my ignorance, I have not been able to realize how exactly am I supposed to actually GET the certificate of somebody or of a hub and place it in the "trusted certificates" folder). That would make ApexDC++ 1.2.0 the top client again. Oh, by the way... Are you going to wait for the final StrongDC++ 2.22 before releasing the final 1.2.0 ?

Yup, en_dator confirmed it fine. Only the "Get IP" button fails, the automatic IP refresh on startup works fine. Adrian_007 - It's possible that it fails when trying to get IP from remote HTTP response, but other HTTP seems to work fine. Why this instance only? Crise - PeerGuardian was a plug-in. Couldn't IPGuard be made a plug-in too? That way, who wants to download and install it does so (the OPs generally), whoever doesn't, doesnt. That way, those who really don't need the IPGuard functionality (and I mean most of the users when I say this) are not going to be hindered by it being left accidentally on. Same functionality for those who need it, less usage for those who don't. And speaking of plug-ins... If I'm allowed a suggestion: please create a site section right next to "Download" that's named "Plug-ins"... That should include a VERY short install guide on the top (like "download and uncompress in the "Plugins" directory" - most users aren't stupid, and if they are, they won't be needing those plug-ins anytime soon), and next, a list of the official plug-ins (like the LUA one or the IPGuard if you decide to make it that way) and contributed ones if the space and time allows it. This way, people are going to find that illusive LUA plugin they've been craving for so much without having to guess that it is located somewhere within the forums. I'll try to find more info on the missing passwords thing. Please do take care about the "Someone is trying to use your client to spam ...", it's really annoying sometimes.

From the people that have used it, I've got the following feedback: - the Beta version forces CPU to 100% under certain conditions (I've been unable to replicate or find out the cause, though it has been witnessed) - the Beta version fails to memorize certain passwords if not doing a clean install (I've been unable to establish the pattern, but this one is also true, some favorite hubs are imported with a blank password) - the old "Someone is trying to use your client to spam ... please urge hub owner to fix this" is a real problem with the beta; I've witnessed it on almost all installations. Doesn't happen on only one hub software, so it's not a hub-related issue. Also, with Apex 1.1.0 and Apex 1.2.0 beta on the same hub, the beta complains while 1.1.0 doesn't. - it sometimes happens that upon startup, Apex beta's interface will jam completely then, after 30 seconds or so, get back to normal as if nothing had happened. During this time, everything else but the interface works. - cleaning up a highly-populated list (for instance, in a search window) is a horrible task to witness if, for any reason, the scrollbar is on the bottom, at the end of the list. It appears as if Apex would clean the list one item at a time, then refresh the interface to display the changes, then remove another item and so on... on less-performant systems, this thing alone can take between 10 and 20 seconds. This, by the way, is not new to the beta. While this is happening, it appears that everything else except the interface works normally. - if, for any reason, there's a menu opened while there is an avalanche of PMs, for every PM that opens a new window, the menu will go blank, its closing animation will follow, then its opening animation, it will display its contents and the whole cycle will be repeated. This is easy to notice if you are using a mass usercommand, but please do not try it on too many users at a time, as the interface will be completely locked during this time. All the other systems will work normally as far as I could notice. - the work on the looks of the progressbars is highly spoken of, by the way... - activating IPGuard with many blocks on a 10,000-user hub is murder on the CPU, but I guess this is not necessarily something fixable at the moment That would be all for now.

You're kind of lucky... my bandwidth is 640kb/s in all, and when it does reach that speed, I'm a happy guy. OK, few things I did notice about ApexDC++: Bug 1 [not serious]: The "Get IP" button attempts to fetch the IP of the computer. Normally this would be fine, however if one is behind a router, even if that router is configured to port-forward, that will automatically switch him to passive mode regardless of the setting. Since we are talking about the UPnP or manual port forwarding settings, I for one find it natural that the IP should be an internal one, and ApexDC++ should not attempt to automatically switch to passive mode. Automatically fetching the correct IP at startup seems to be working, though. Bug 2 [VERY SERIOUS]: This only became apparent when I'd forgotten to close my RSX++ before starting ApexDC++. Since I'm behind a router and I'm kind of lazy, I didn't port forward for Apex in particular: it was configured to use the same ports as RSX++. Naturally, Apex popped up saying it cannot open ports, so I opened its settings and switched it to passive mode, then hit "OK". BIG surprise: ApexDC++ still "couldn't open ports" (mind you it was switched to passive mode)... I closed ApexDC++ and opened it again, RSX++ still running, it STILL "Couldn't open ports"... In order to get rid of that error (and implicitly of ApexDC++'s attempt to open ports), I had to switch to "firewall with manual p.f." and manually clear out the TCP, UDP and TLS port boxes. I only find it natural that if it is passive, it should not attempt to open ports at all, regardless of whether or not the port setting exists.

No way... Are you actually telling us that I'm not the only one with this problem? Hallelujah, brothers and sisters! (just joking) Seriously now, ApexDC++ rocks as it is, no sense in pushing things. We'd all appreciate a Christmas present in the form of ApexDC++ 1.2, but if not, we'll wait for Easter then Stability, performance, features and awesomeness are more important.

This should be good... Let me just highlight the points of interest in this announcement: Smashing. This news is so good, that I don't even know where to start praising it. Should ApexDC++ LUA have the same declared types as others (say RSX++), thus making scripts compatible, that would be even better news. I for one have a lot of respect for Adrian_007 on what he did with that magnificent client. Seeing that ApexDC++ will also implement some of its most useful features is excellent news as well. When you say "merged", did you mean "merged merged" or "updated the code base to the latest StrongDC++ version" ? Because when I read that part, I couldn't help looking in the calendar just to make sure we weren't in April 1st again... I just knew the long silence in ApexDC++ development wasn't slacking off, but hard work so you guys can put out yet another breathtaking version, and this one should really be good... What can I say except for good news and hope the finised ApexDC++ will rock the world. By the way, would it be too much if I asked you to post a screenshot of the Settings window around the new CDM options? Just so we know a bit what to expect... One measly screenshot should do.

Iranmaster - you know what the horrible flaw in your logic is? True, a high-speed Internet connection is indeed affordable... however is it available? In my case, it isn't. I only have the option of my current ISP, and they (the people there) refuse to install me a faster line because of "their policy" (which kind of means that as long as you don't live in a block of flats, you're not going to have a T1/fiber from them). I could, of course, have a connection half the speed of a T1 brought in for 200$ per month, but, at that cost, I'd rather pay for a dedicated server somewhere and host my own online TV show. I'd be much better off. If you are worried that slow users download from you and there's no more room for fater users, there's a very simple sollution: more upload slots!

Call me stupid, but I never understood why usercommands cannot be made to work on ADC hubs as well. Of course, I do realize that there is a different protocol to send them with, but that can be adjusted for automatic detection, right ? ...which brings me to the bug I noticed. I was wondering whether or not someone has included some "hidden coding" and made usercommands work with ADC hubs. I therefore created a usercommand and forced it to run on an ADC hub (by typing the hub address in the "Hub IP/DNS" box, with adc:// protocol identifier and all). To my great surprise, the usercommand actually did appear in the hub user menu (as I instructed it to), but, as one can imagine, it was attempting to send the NMDC version of the command. Needless to say that the hub's last words before disconnecting were "Client sent weird data, protocol error..." So there you have it, in a wrap: usercommands do not appear on ADC hubs unless you specifically input the hub's address in the "Hub IP/DNS" box, which shouldn't happen, since it is trying to send the NMDC version of the usercommand to the hub.

Crise - doesn't that error show up when ports are overlapping with some other application? Like, say, you have IIS or Apache and you make the mistake of setting ApexDC++ to go on port 80...

Satan's right, actually. The windows firewall isn't considerably better than that in Windows XP, and UAC really is there more like an idiot-proof feature (and I personally wouldn't see why any person skilled with the use of Windows would actually need it), since it doesn't actually block anything from happening... a person that has no idea that clicking "ok" when asked "do you wish to install ... extension?" by IE is bad, they won't have any idea to click "cancel" when asked by the UAC anyway. In any case, the sollution I recommend for such a problem: - don't use low port numbers (I use 5566, for instance), and, even if you have a direct connection, do use "Firewall with manual port forwarding" and have fixed port numbers, they're much easier to manage and you can make sure no overlapping occurs - if possible, don't install ApexDC++ in the "Program Files" folder - wherever you install it, grant it administrative privileges - make sure it goes past the firewall(s) (and PS: DON'T use ESET Smart Security in automatic detection mode, it's a killer)

Image describes the bug: ApexDC 1.0.1 running on Vista SP1 64-bit, AMD Phenom quad-core CPU on AMD790X chipset.

It seemed to me that Apex knew from the beginning that it will overlap. It would be nice to change and actually show the real size that it is downloading, even if it is overlapping.

Segment size shown in column: 501.39 KB Already downloaded shown in progress bar: 1.37 MB Real segment size: ~2MB It's reporting 500KB on a 2MB segment. The progress bar was full when download reached 500KB, but the percentage shown on it was only 25%.

I don't mean to annoy anyone, but the Plugin support should really NOT have STLPort as a requirement. Personally, I consider STLPort as a useless chunk of code that uselessly bloats the ApexDC++ source code. It has a lot of drawbacks, a lot of incompatibilities and if there is one thing you shouldn't believe the makers of it, that has when they say "It should compile fine on any machine, with the standard configuration". Furthermore, it has no native 64-bit support, no native multi-core support (which you'd at least expect from something that claims to be the industry standard in multiplatform development), and it uses many deprecated symbols and syntax forms. It releases no binaries (claiming they prefer to "keep it simple for compiling", which, I have to say, is a complete and total failure on their part), and, if you take a look at the help pages, most are compiling problems, and most of them are either unsolved (some) or solved through coding mind gymnastics that I personally wouldn't go through. There, I said it. Now I feel a lot better. I know what I asked for isn't exactly possible, but one can dream, right ?

I have a spooky suspicion that this crash is related to the one I posted ( http://forums.apexdc.net/index.php?showtopic=2681 ), for no other reason but them being triggered by the same thing, hitting an error in the same code, on the same line. I'll have to say it is possible that the crash I reported may have had (for some reason or another) its details cut off, and be in fact a manifestation of this crash.

Hmm... took a look through the source code. The piece that triggered this is: if(ou->getUser()->isOnline()) { StringMap tmp = ucParams; ou->getIdentity().getParams(tmp, "user", true); client->escapeParams(tmp); client->sendUserCmd(Util::formatParams(uc.getCommand(), tmp, false)); } The user didn't go offline (actually I successfully used the same usercommand on him after restarting ApexDC++).

Code: c0000005 (Access violation) Version: 1.0.1 (2008-03-09) Major: 6 Minor: 0 Build: 6001 SP: 1 Type: 1 Time: 2008-04-23 16:55:13 TTH: H6JE7JFGAHDTABZAJLSO3RRWNEI7VBJ6LAYWMUQ d:\development\apexdc\trunk\windows\chatctrl.cpp(931): ? That's all.

The user command was something like this: !bannick_1d %[userNI] RO: <romanian message> <web address> <romanian message>. EN: <english message> <web address> <english message>. %[myNI] thanks you. Chat command, present on user menu, sent once per nick, towards any hub. I'm sending the actual user command through private message. Some other info I can give on this is: everything worked fine afterwards in ApexDC (downloads/uploads and mainchat didn't seem to be bothered by this exception), but I couldn't make it go away either. Whenever I hit "Continue", it would show the same over and over again. I used the command on one user, his tag read ++ V:0.704 (as I can remember), the hub is a Verlihub 0.9.8d_RC1. That particular usercommand I use about 10-15 times a day at least (since there are a lot of morons out there), and I've used it since without any incident. That's about all the info I have. If you need anything else more specific, please say.

Code: c0000005 (Access violation) Version: 1.0.1 (2008-03-09) Major: 5 Minor: 1 Build: 2600 SP: 2 Type: 1 Time: 2008-03-27 23:43:55 TTH: H6JE7JFGAHDTABZAJLSO3RRWNEI7VBJ6LAYWMUQ d:\development\apexdc\trunk\windows\chatctrl.cpp(931): ChatCtrl::runUserCommand d:\development\apexdc\trunk\windows\uchandler.h(37): UCHandler<ChatCtrl>::ProcessWindowMessage d:\development\apexdc\trunk\windows\chatctrl.h(80): ChatCtrl::ProcessWindowMessage d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3976): ATL::CContainedWindowT<ATL::CWindow=0x016CD540,ATL::CWinTraits<1442840576=0x00000111,0> >::WindowProc USER32!0x77D48709: GetDC USER32!0x77D487EB: GetDC USER32!0x77D4C00E: DestroyCaret USER32!0x77D4C034: CallWindowProcW d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3981): ATL::CContainedWindowT<ATL::CWindow=0x016CD42C,ATL::CWinTraits<1442840576=0x00000111,0> >::WindowProc USER32!0x77D48709: GetDC USER32!0x77D487EB: GetDC USER32!0x77D489A5: GetWindowLongW USER32!0x77D489E8: DispatchMessageW d:\development\includes\wtl\atlapp.h(992): WTL::CMessageLoop::Run d:\development\apexdc\trunk\windows\main.cpp(432): Run 0x000500D0: ? ApexDC!0x00444CC2: MainFrame::FileListQueue::`scalar deleting destructor' ApexDC!0x004AEE0E: [thunk]:ATL::CComContainedObject<ATL::CAxHostWindow>::Release`adjustor{32}' 0x8351F8E4: ? It's been reported to me by a friend, so this is all I've got. He is an operator on many hubs (hence the high probability of an error with usercommands to surface).

Bug fixed :thumbsup:

Anyone into the error found here? http://www.ixiancorp.com/Users/Adim/Report...s_ssl_error.jpg Behavior: at first, it downloads fine. Then, it gives this error (and nothing more). After that, it's "Connection Timeout" for a while. Not sure whether it's a bug in Apex or in the other client (and considering that the user from which this arrived is FleetCommand, I can only suppose it was BCDC++), so I'll post it here. Admins please move where appropriate, if necessary.

Had the time to test StrongDC++ 2.12 today. I can't wait for a new ApexDC++ version based on it... Please, make us all happy and release it ASAP :D

To me, it looks like a virus ! http://forums.cnet.com/5208-6142_102-0.htm...ssageID=2460370 http://forums.techarena.in/showthread.php?t=729299 http://www.zolved.com/synapse/view_content...essage_c0000013 http://www.consumingexperience.com/2007/11...processing.html

My Apex does a filelist refresh every startup, so I'd rather expect this kind of behavior if it was my computer you were talking about. Wouldn't creating a PreviousHasdData.xml and PreviousHashIndex.dat be more helpful? Keep the latest TTH for any removed file/drive/etc. in them. And get the entries in it that are older than a week deleted. When a previously-removed file is found, it is checked against the data in these files (put a limit to file size, say, 10MB, otherwise it will be very inefficient) and the TTH already exists, can be shared instantly.