• Content count

  • Joined

  • Last visited

About Fangs404

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Iowa City, IA
  1. Released: ApexDC++ 1.3.1

    This is awesome! And good job going with 7-Zip. I've been using it for years now, and it's good to see more people using it.
  2. wrong install location for 64-bit installer

    Good deal. You guys are awesome. ;)
  3. settings still not saved to the correct location

    Good deal. Thanks!
  4. I'm running 64-bit Windows 7, so I figured I'd give the 64-bit version a shot. It seems to work just fine, but the default install location is C:\Program Files (x86)\ApexDC++. It should install to C:\Program Files\ApexDC++ (the 64-bit program files directory).
  5. This is basically a reminder of since those changes weren't incorporated into this release. Having to run the application as administrator or install somewhere besides program files is not a solution.
  6. Interesting, I figured out a way to solve my problem. I went to the downloads section of the settings and rechose my default download directory (which lives on my NAS). Then, magically, my mapped network drive showed up under sharing. Weird, but it's working now at least.
  7. I actually just started having this problem today. I have mine mapped to Z: also, and I'm running Win7 64-bit. I was sharing just fine for the last week, but I launched ApexDC++ today (as admin), and all of a sudden, it didn't see the mapped drive. However, when I don't run it as admin, I can see the drive alright.
  8. This is great news. Thanks!
  9. I've been active in the DC community for quite some time now (I co-develop NextHub), and I just stumbled onto ApexDC++ not too long ago after using StrongDC++ for a while. I quite like it, but I have one gripe. Currently, the settings are stored in the Settings directory inside the install directory. I noticed not too long after I began using it that I was experiencing some strange errors. When I closed the hub, it would always ask me if I really wanted to close it even though I repeatedly told it to remember my decision. Then I noticed that I was getting the popular "Error saving hash data" error. I instantly recognized the problem, ran it as administrator, and voila, the problem is fixed. The problem is that the settings are being stored in the install directory. The installer naturally installs to %PROGRAMFILES(X86)% (I'm running Windows 7 64-bit Pro). This is fine because that's where it should install. However, administrator access is needed to write to that directory. This isn't a problem during installation, but it is when the settings need to be written/updated. As a computer scientist, I recognized this right away. However, other users on the hubs that I recommend didn't understand why their settings weren't being stored properly. There are 3 solutions to this problem: - Run the program as administrator at all times (as recommended at http://forums.apexdc...cess-is-denied/). - Install the program elsewhere (perhaps to C:\ApexDC++). - Save the settings in the correct location (%appdata%\ApexDC++). I was shocked to see that a project manager is actually recommending running the program as administrator at all times. This is terrible advice and should absolutely not be carried out because it sets a bad precedent for other developers/users (it's a terrible security hole). The 2nd solution might be more viable if it were the default install location for the installer, but it's not. Most users will install a program to the default location given in the installer, and it's expected that the program should fully function from this location. Installing to the root directory is bad practice anyway, so this really isn't a great solution either. The third solution is the most appropriate. The program is indeed installed to program files, and the settings are stored in a local user directory where the user is guaranteed to have write access. The reason I have placed this thread in bugs is because it really is a bug and needs to be fixed. I hope the developers understand this problem and why changing the settings to %appdata% is the only real solution here. Thanks for the solid software, and I look forward to this being fixed in the future.