Rigor O'Mortis

Fixed the picture, my apologies, I had changed the folder name in which it was located. PS: when a connection is encrypted, shouldn't it be displayed somehow in the download window? like a key next to the user name or something. If this already happens, I wish to announce that I haven't noticed it anywhere...

Zlobomir is right. However, there's a problem... if you put a different search time for different hubs, when you search something on both hubs how much will you have to wait until search works ? Is it possible to time both hubs at a time and postpone search on others until the last hub's search interval timeouts ?

I'd go with the fully automatic update. Display a balloon once downloaded (downloading is done automatically) and let it there for 12 hours. After 12 hours from the finished download, if the user doesn't click "yes" (or "not now", "no should not be an option), update automatically using the method described above. I'd also do something else: the updated ApexDC++ binaries, in a super-tightly-packed install package, should be placed in the user's share, without him having the ability to control it. Any update will therefore attempt to segmented-download from users, and resort to the site only if it has no users to download from at that moment.

Some positioning issues in the download queue window. Image here: http://www.ixiancorp.com/Users/Adim/ApexRe...positioning.jpg Reported by the same pervert friend of mine who found the %-formatting bug.

Same problem here. I presume you've kept your settings file from older versions. I saved my usercommands in notepad, saved my theme, then deleted the settings file, started Apex to create a fresh one and pyut my user commands back. They show in correct order now (with the exception of separators, which do not seem to show anywhere). It was painful enough to re-hash 300GBs, but at least no more compatibility issues...

Bug #1: ADC hub, not ADC1.0-compatible... Bug #2: (crash report) Code: c00000fd (Stack overflow) Version: 1.0.0B4 (2007-08-07) Major: 5 Minor: 1 Build: 2600 SP: 2 Type: 1 Time: 2008-01-10 14:07:52 TTH: 7CNQCQXDGEV7S2IDTUSYEW73M722LLS7BVOOXDI fsma32!0x170036B7: _FSMAStopMessagePump@4 FSHTTP!0x01721631: DeletePluginObject It's Beta 4, remains in beta 5 after update, happens every time Apex is started, "Continue appplication" makes it go away and not appear until next Apex session Bug #2 and a half: (this is funny, actually, not a real bug, but I thought it might make a good laugh) Off-site image (it was too large, I use 1600x1200 screen resolution)

No, it WASN'T compatible, that's just the point. I understand the mainchat problem in hubs that aren't 100%-compatible, but that was just a bit weird. Downloading from a user without being able to see its name. It only identified the hub from which it comes. Regardng bug #2 - The sollution was good. It was indeed FSecure Antivirus (although it was fully updated). Disabled it and worked.

Pretty straightforward and easy to understand feature request, I think...

Ony of my more pervert friends has discovered a funny bug in ApexDC beta 4. I have no idea whether or nit it's present in the new DC++ as well, but, still, it was funny enough to be worth posting here. Try entering away mode, but with this: /away Hibernating 69% (my friend is somewhat obsessed with 69, but that's a different matter) You will notice a very strange away message... and the most code-experienced of you will quickly realize that the "%" is causing this.

A feature such as this one might take out a lot of frustration from users, though. Let's say I wish to give someone a file without putting it in share, but I also don't wish that person to have my YM/MSN/whatever account name/number. Undoubtedly, this feature would make ApexDC++ a complete file sharing application.

Furthermore, I think a much wiser option would be to create a "Network interface for all connections" override in Favorite Hubs. That way, all connections for a certain hub will be going through that network address only. The same setting in Connection Settings could be transformed from a drop-down into a selectable list, and be used to limit which network connections can ApexDC use. This would please users that run ApexDC on network centerpoints or servers. I should bring into attention another problem: people with multiple Internet connections (there's a whole ad-hoc network of people in this situation where I live, and I could surely get them to test a feature like this for me). Perhaps the "External/WAN IP" setting can be made hub-specific as well ?

Reported this back with previous betas. It seems to be related to the number of uploads, downloads and hub users. When I stay on hubs with many users and there are many uploads, CPU usage can go up to 100%. For downloads, yes, the same thing can happen, but only if I download 30-40 files at the same time or more, which shouldn't happen ver often. PS: Adrian, get rid of Firefox and ZoneAlarm...

And through normal promotion of ApexDC, through site and DC client lists, that promotion of leecher clients is not going to happen? I'm afraid you're off here. There could be ways in which the clients would identify to each other through client-to-client protocol, or at least identify their enabled capabilities, so methods such as archive-then-send, prioritized upload/download or solid-archive-then-send would work. So, essentially, what you're saying is that nobody will be able to identify a user based on client capabilities only, so why bother improving possible user experience, is that it? I, for one, am a fan of this idea of prioritized upload. I would implement it in the following way: - prioritized upload can be made on extra slots only, thus not affecting those that aren't "prioritized" - prioritized upload can be enabled only on a favorite user; if it's a favorite user, then you must have placed it there for a reason - only one priority upload can happen at a time - a specific upload can be declared as priority upload manually if it's not on a favorite user (say, by right-clicking on it, through the menu), if there is no other priority upload at that time, that upload being automatically considered on an extra slot - through client-to-client protocol, a prioritized upload from the sender will become a forced priority download on the receiver, thus strangling all the other downloads and forcing people to use priority uploads/downloads only when absolutely necessary This way, there will be no abuse problem, yet it will solve the problem of allowing a friend/colleague getting a file urgently without having to kill other uploads or closing ApexDC++ altogether to use a different file sharing method in order to gain speed.

1. User dupe checker I'm in certain huge international hubs ("international" = "mostly Sweedish"). Like me, others are on the same hubs. If I try to download from one, it is only a matter of time since the same user, but from all different hubs, is added to queue. This would normally be a good thing, but I can only download from one clone at a time, all the others being in "connection timeout". How difficult would it be to implement a system that identifies users from different hubs as one and the same? Say, something like "if user1 and user 2 have the same IP and same exact sharesize and same tag (if available to check) and the same communication ports open, consider them both as user1". 2. The clear chat button I really miss it. It was quite a useful feature. 3. The suppress mainchat function It would be very useful if implemented in a hub-specific way. It would help many people stick to ApexDC only, and not have a different client for the hubs they do need to speak in. Actually, this would be of a lot more help. It would be of a lot more help if it was implemented in the protocol... helps save a lot of bandwidth.

Please see the image below to understand what the bug is: As you can see, when the toolbar is too small for all buttons to fit, the buttons that do not fit have no text on them, if accessed from the drop-down menu. A quick edit: The Media Toolbar has the same problem, only a bit bigger: it has no icons either.

Well, I gave the methods to find out the paths. Personally, I think they should be impossible to share, but a big WARNING dialog will work, too. By the way, if Lee or Crise is reading this (no use starting another topic just for this), when you wish to add a file preview application in Settings -> File Preview, the add / change dialog title is simply "Dialog". Very suggestive :)

Let's say I wish to share a folder, say C:\Folder1. I accidentally click on C:\Folder2, which has about 32768 subfolders, each with 65536 files in it. Obviously, I do not whish to share Folder2, but Folder1, so naturally, when I am presented with the dialog requiring me to input the virtual folder name, I click on "cancel". However, ApexDC++, even so, creates a list of files to be TTH-ed (and you can imagine, in a situation like that, how much that would take), and keeps the check on Folder2, although I clicked on "Cancel". It would be quite logical that, if the user clicks "Cancel", Apex would simply... cancel :blushing: . I know this is a general bug, I know this is a minor bug, but just thought I'd let you know it exists.

Oh crap, I've been away for too long. I still have a question, though: what does "cancel the virtual name" actually mean? Will the folder be shared without a name (I'm joking here)? Wouldn't it make a lot more sense to make the "Cancel" button actually cancel? Or, wouldn't it make a lot more sense to add another button saying "Cancel and cancel share of this folder", or something on the lines of that, specifically for that case in which you accidentally click on a 32768-folder-full folder, each subfolder with 65536 files ?

Speaking of which... (since I see optionwizz sharing the Windows folder...) 4. Share limitations for some folders A lot of hubs kick or even ban users who share junk. Amongst junk would be, of course, the Windows and Program Files folders as well (for instance, I cannot imagine why anyone would download the "Windows" folder). For those that "boost" their share this way and are lucky enough to have a dynamic address, ApexDC++ is, ironically, the best option, since all they have to do is reconnect, Apex automatically updating the IP address, and the kick/ban being unapplied. Would it be difficult to pull four values and prevent those folders from being shared? I'm talking about the "Windows" folder, the "Program Files" folder, the "System Volume Information" folder and the "Documents and Settings" folder (leaving a special option "My Documents" at root-level, along with "My Computer" and "My Network Places") ? Those values can be obtained like this: - Windows folder: registry value located at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", named "SystemRoot" - Program Files folder: registry value located at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion", named "ProgramFilesDir" - System Volume Information folder: <drive letter>\System volume information. Any NTFS drive has it. - Documents and Settings folder: registry value located at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList", named "ProfilesDirectory" Hope this helps and hope to see this thing implemented, it would be one more step forward into crashing cheaters.

Not sure whether or not this is a bug, but... When I try to assign an action for an ADL search, it shows it as assigned in the ADL search properties, but it shows "No Action" in the ADL search list. Also, unless the command I'm inputting actually doesn't work, it would seem that ApexDC isn't doing anything with it (activated the action from hub properties, so that's not the problem). However, I'm certain that the RAW command works, since it is a very simple and short mainchat message (and it works if I use it differently than in ADL search).

That's the spirit! :blushing: I'll let the pic up until the next version and then delete it from the server, after the bug is sorted out.

Aha, so it goes back to the ol' DC++... I'll wait for the next DC++ then...

I notice that there's validation in the "Settings" dialog. It also seems to work properly: But as you can see from the image, the TLS port box is the only one in which it does, at least in the "Connection settings" area. I've stumbled on this little bugger when I was screenshooting the "Settings" page for a small help file that I'm working on for someone. This bug is minor, so please do not waste time with it if there's something more important to do. Quick edit: Also, the "password" field of the SOCKS proxy area is unmasked.

OK, it does work, I'm a little ashamed... Shouldn't the RAW command selection drop-down be disabled if the ADL search is not for a forbidden file? That would make a lot more sense.

That would indeed be a very good idea. I do remember old clients by the time DC++ 0.306 was out having the same problem. Of course, it's not that bad when it destroys your favorites, but it is horrible when it destroys a 5000-file download queue. Say there is a Settings\Backup folder, where, upon startup, Apex checks for integrity of all settings files and then backs them up. Let's say it backs up the last 10 entries, like Favorites.xml.bak0, Favorites.xml.bak1,... and automatically names files accordingly.