You can subscribe to this list here.
2002 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(28) |
Nov
(89) |
Dec
(37) |
2008 |
Jan
(78) |
Feb
(37) |
Mar
(21) |
Apr
(3) |
May
(10) |
Jun
(3) |
Jul
(13) |
Aug
(7) |
Sep
(9) |
Oct
(3) |
Nov
(4) |
Dec
|
2009 |
Jan
(2) |
Feb
(7) |
Mar
(16) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(5) |
Nov
(4) |
Dec
(1) |
2010 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Jacek S. <arn...@gm...> - 2007-11-09 19:23:04
|
Any takers? regards /J -------- Original Message -------- Subject: DC++ on FileHippo.com Date: Fri, 09 Nov 2007 10:09:34 +0000 From: FileHippo Admin <ju...@fi...> To: arn...@us... Hi, we'd really like to add detection of DC++ to our Update Checker, but the app is missing a file version property that we use to detect the version. It was present in earlier builds of DC++, but is not in the latest versions. Is this something you could add in future builds? Regards The FileHippo team http://www.filehippo.com/ |
From: Jacek S. <arn...@gm...> - 2007-11-09 19:19:36
|
> actually, brushes and pens are selected and used correctly, but the > result is awful. i'd say it is because the bitmap itself doesn't have > enough memory, maybe. Well, that'd be strange, but I'll accept any reasons =) something must be different since it worked before and now it doesn't... > > how about having both arrows as resource files, and loading them with > ::LoadImage()? Naw, they're supposed to follow system colors for shadows and highlights.. /J |
From: Jacek S. <arn...@gm...> - 2007-11-09 19:17:04
|
ok. =) thanks /J poy wrote: > forgot the patch once again. ^^ > >> here, new patch. >> - the function now uses SmartWin::LibraryLoader. >> - moved the MessageBox to MainWindow, and its string can be translated. >> - played with some includes... >> >> poy |
From: poy <po...@12...> - 2007-11-09 18:09:25
|
forgot the patch once again. ^^ > here, new patch. > - the function now uses SmartWin::LibraryLoader. > - moved the MessageBox to MainWindow, and its string can be translated. > - played with some includes... > > poy > >>> i did it in win32/ and used a bool in WinUtil because DC++ already >>> checks >>> the Common Controls version on startup, and if the version is too old it >>> displays a MessageBox. >>> >>> or should i move the whole checkCommonContrlols() function (along with >>> its >>> MessageBox) in smartwin/ ? if it's static the MessageBox would appear >>> only >>> once so yeah that should also work. >> Well, maybe just create a function that loads the version number in >> smartwin and then have dc++ use >> that function to do the check... if the dc++ smartwin is ever released >> separately, it's not sure >> that all apps will need the new controls... >> >> /J >> >> > |
From: poy <po...@12...> - 2007-11-09 18:08:19
|
this was supposed to be sent here... >> Hm, pretty strange then...the old wtl code did it with brushes and pens >> so I wonder what's >> different...maybe some handle not being assigned correctly? >> >> /J > > actually, brushes and pens are selected and used correctly, but the result > is awful. i'd say it is because the bitmap itself doesn't have enough > memory, maybe. > > how about having both arrows as resource files, and loading them with > ::LoadImage() ? > > poy |
From: poy <po...@12...> - 2007-11-09 18:07:11
|
here, new patch. - the function now uses SmartWin::LibraryLoader. - moved the MessageBox to MainWindow, and its string can be translated. - played with some includes... poy >> i did it in win32/ and used a bool in WinUtil because DC++ already checks >> the Common Controls version on startup, and if the version is too old it >> displays a MessageBox. >> >> or should i move the whole checkCommonContrlols() function (along with >> its >> MessageBox) in smartwin/ ? if it's static the MessageBox would appear >> only >> once so yeah that should also work. > Well, maybe just create a function that loads the version number in > smartwin and then have dc++ use > that function to do the check... if the dc++ smartwin is ever released > separately, it's not sure > that all apps will need the new controls... > > /J > > |
From: Jacek S. <arn...@gm...> - 2007-11-08 19:09:54
|
> i did it in win32/ and used a bool in WinUtil because DC++ already checks > the Common Controls version on startup, and if the version is too old it > displays a MessageBox. > > or should i move the whole checkCommonContrlols() function (along with its > MessageBox) in smartwin/ ? if it's static the MessageBox would appear only > once so yeah that should also work. Well, maybe just create a function that loads the version number in smartwin and then have dc++ use that function to do the check... if the dc++ smartwin is ever released separately, it's not sure that all apps will need the new controls... /J |
From: Jacek S. <arn...@gm...> - 2007-11-08 19:04:24
|
Hm, pretty strange then...the old wtl code did it with brushes and pens so I wonder what's different...maybe some handle not being assigned correctly? /J poy wrote: > i've been trying to re-do the list view createArrows() code in a simpler > way; ie, simply draw a gray triangle and fill it. but i could never > manage to get any brush applied, so the only way i've found is to use > ::InvertRgn(), and the result is a black triangle. > yes it's quite ugly, best would have been to use ::PaintRgn() or > ::FillRgn() with the appropriate brushes. > > as i'm not sure which arrows are best (ugly previous ones, "too black" > new ones...), attached are screen shots. > > poy > > |
From: poy <po...@12...> - 2007-11-08 18:45:43
|
> Ok, this should go to the smartwin widget instead...along with a version > check function to > aspectcontrol for example (or some better place maybe, ideally it would be > static and defined in a > .cpp file)... > > /J i did it in win32/ and used a bool in WinUtil because DC++ already checks the Common Controls version on startup, and if the version is too old it displays a MessageBox. or should i move the whole checkCommonContrlols() function (along with its MessageBox) in smartwin/ ? if it's static the MessageBox would appear only once so yeah that should also work. poy |
From: poy <po...@12...> - 2007-11-08 18:30:14
|
i've been trying to re-do the list view createArrows() code in a simpler way; ie, simply draw a gray triangle and fill it. but i could never manage to get any brush applied, so the only way i've found is to use ::InvertRgn(), and the result is a black triangle. yes it's quite ugly, best would have been to use ::PaintRgn() or ::FillRgn() with the appropriate brushes. as i'm not sure which arrows are best (ugly previous ones, "too black" new ones...), attached are screen shots. poy |
From: poy <po...@12...> - 2007-11-07 14:10:35
|
forgot the patch. ^^ > this is a simple fix to get the down arrow in listviews drawn "correctly" > (meaning, one can understand that the drawn thing is an arrow...). > i've been trying to draw a simple gray triangle instead, but could never > get > the colors applied properly; best i've got is a black triangle. will try > again... ;) > > poy |
From: poy <po...@12...> - 2007-11-07 13:39:20
|
this is a simple fix to get the down arrow in listviews drawn "correctly" (meaning, one can understand that the drawn thing is an arrow...). i've been trying to draw a simple gray triangle instead, but could never get the colors applied properly; best i've got is a black triangle. will try again... ;) poy |
From: Jacek S. <arn...@gm...> - 2007-11-06 19:24:26
|
Try the attached example...it exits gracefully in with g++ at least... /J (oh, and I assume your reply should have gone to the list really) itinerants wrote: > On 4/11/07 5:55 pm, "Jacek Sieka" <arn...@gm...> wrote: > >>> 2. DirectoryListing::loadFile need to be specified as throwing >>> FileException, SimpleXMLException - corrupt file lists, as well as the >>> routine itself, throw more than just "Exception". I'm not a c++ expert, but >>> my understanding of the "throw" thing in the function prototype is that if >>> you throw something other than what's listed, you get a runtime exception >>> and the prog exits if it isn't handled - can't see that it is being handled. >>> This certainly killed my version until I added the new specifiers. >> *Exception inherit from Exception so it should be safe...although I'm sure >> there are lots of places >> in the code with bad specifiers (msvc didn't enforce this so I never cared >> really much about >> it)...currently I use a gcc switch to disable the runtime exception =) > > I've searched high and low, and can't find out what the inheritance story is > here - sounds reasonable. > All I CAN say is that it killed my CodeWarrior program until I explicitly > listed the other exceptions. > Given that you aren't really using them, perhaps making the "throw" specs at > least a #define in some future version might be an idea - then *I* can turn > them off too! > > Regards > > Roger > > > |
From: Jacek S. <arn...@gm...> - 2007-11-06 19:08:48
|
Ok, this should go to the smartwin widget instead...along with a version check function to aspectcontrol for example (or some better place maybe, ideally it would be static and defined in a .cpp file)... /J poy wrote: > Common Controls 6 provides a nice way to draw ListView arrows > automatically, so this patch uses it. now arrows aren't as ugly, and the > down arrow is drawn correctly. > i had a little trouble with 2 defines, which were in the psdk but not in > my MinGW. > > by the way, i saw this being used in a mod of DC++ a long time ago > (can't remember which), but it's not like it really matters... > > poy > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > dcplusplus-devel mailing list > dcp...@li... > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel |
From: poy <po...@12...> - 2007-11-06 18:17:16
|
Common Controls 6 provides a nice way to draw ListView arrows automatically, so this patch uses it. now arrows aren't as ugly, and the down arrow is drawn correctly. i had a little trouble with 2 defines, which were in the psdk but not in my MinGW. by the way, i saw this being used in a mod of DC++ a long time ago (can't remember which), but it's not like it really matters... poy |
From: Jacek S. <arn...@gm...> - 2007-11-04 17:55:45
|
itinerants wrote: > 1. I see there is some "if macintosh" type code, so I needed to turn off > SO_NOSIGPIPE... > BufferedSocket::accept > BufferedSocket::connect > Both needed > sock->setSocketOpt(SO_NOSIGPIPE, 1); > With the other socket options. > I suspect this is a mac only fix, but I know nothing about pcs, so I can't > be sure. linux has a similar issue/trick...win32 doesn't... > 2. DirectoryListing::loadFile need to be specified as throwing > FileException, SimpleXMLException - corrupt file lists, as well as the > routine itself, throw more than just "Exception". I'm not a c++ expert, but > my understanding of the "throw" thing in the function prototype is that if > you throw something other than what's listed, you get a runtime exception > and the prog exits if it isn't handled - can't see that it is being handled. > This certainly killed my version until I added the new specifiers. *Exception inherit from Exception so it should be safe...although I'm sure there are lots of places in the code with bad specifiers (msvc didn't enforce this so I never cared really much about it)...currently I use a gcc switch to disable the runtime exception =) > 6. Unless I've missed something, which is quite possible, users in the wait > list who aren't online are shown only with their CIDs? yeah, at some point some sort of caching of nicks (and other info) should be added... an open mac port would be welcome, to this end I've been striving to make the non-gui part more library like to maybe break it off in some distant future... /J |
From: Fredrik U. <ul...@gm...> - 2007-11-04 14:10:15
|
On Nov 3, 2007 9:22 PM, itinerants <iti...@ho...> wrote: > 4. The AutoSearch thing... > It saves a list of the 30 last "searched for" strings. > This means that, if you have, say, 29 items in your list, once they've all > been searched for, no more autosearching is performed, yet if you have 31, > it'll keep cycling around. > I fixed this by clearing the list if nothing to search for is found, then, > next time around, we're back searching again. > > 5. The autosearch interval needs to be user-specifiable. It's either 120000, > or 300000, but some hubs have 10 minute minimum search intervals! On those > hubs, autosearch never finds anything after the first one, since the hub > bounces every subsequent search as being within the minimm search interval. > If there's less than 30 items, DC++ should start over again with the queue. (It didn't at some point, and a patch was provided to fix it. This was quite a long time ago.) However, there's still bugs in that code; The code only checks for the total size of the queue, and not the size of the files that are eligable for autosearch. That is, if there's a file that's set to paused or is running etc, and there's less than 30 items, the autosearch mechanism will (then) break. I'm not sure if a user defined search interval would be useful. First off, most people would probably keep the interval at its minimum. The setting seem to be only useful in those instances where the hub has a completely silly minimum interval, and it feels bad to endorse that kind of behaviour where massive user count is the goal (and the hub's reasoning of setting a silly minimum interval to preserve bandwidth). -- Fredrik Ullner |
From: James R. <si...@wa...> - 2007-11-03 21:05:27
|
-------------------------------------------------- From: "itinerants" <iti...@ho...> Sent: Saturday, November 03, 2007 8:22 PM To: <dcp...@li...> Subject: [dcplusplus-devel] Source level bug (probably) report > 3. in .702... > In "StringDefs.cpp", > > A) in ResourceManager::strings > between > "Tag", and " Target filename too long", > There should be "Target removed" > > B) in ResourceManager::names > between > "Tag", and "TargetFilenameTooLong", > There should be "TargetRemoved" For what it's worth, this was caused by a typo in StringDefs.h (which StringDefs.cpp is generated from), and has since been fixed in SVN (r873, 29 October 2007). -- James Ross |
From: itinerants <iti...@ho...> - 2007-11-03 20:22:36
|
A coupla weeks ago I decided to port dc++ onto OSX, that is, to put a native interface onto the "client" section of the code. It went well - had it up and running in about 8 hours, another 4 to put some semblance of "nice" interface on it, and I've been using it, crashless (well, a few due to my own errors) since then. I did, however, find the following, which I think are NOT my bugs, but I stand to be corrected... 1. I see there is some "if macintosh" type code, so I needed to turn off SO_NOSIGPIPE... BufferedSocket::accept BufferedSocket::connect Both needed sock->setSocketOpt(SO_NOSIGPIPE, 1); With the other socket options. I suspect this is a mac only fix, but I know nothing about pcs, so I can't be sure. 2. DirectoryListing::loadFile need to be specified as throwing FileException, SimpleXMLException - corrupt file lists, as well as the routine itself, throw more than just "Exception". I'm not a c++ expert, but my understanding of the "throw" thing in the function prototype is that if you throw something other than what's listed, you get a runtime exception and the prog exits if it isn't handled - can't see that it is being handled. This certainly killed my version until I added the new specifiers. 3. in .702... In "StringDefs.cpp", A) in ResourceManager::strings between "Tag", and " Target filename too long", There should be "Target removed" B) in ResourceManager::names between "Tag", and "TargetFilenameTooLong", There should be "TargetRemoved" 4. The AutoSearch thing... It saves a list of the 30 last "searched for" strings. This means that, if you have, say, 29 items in your list, once they've all been searched for, no more autosearching is performed, yet if you have 31, it'll keep cycling around. I fixed this by clearing the list if nothing to search for is found, then, next time around, we're back searching again. 5. The autosearch interval needs to be user-specifiable. It's either 120000, or 300000, but some hubs have 10 minute minimum search intervals! On those hubs, autosearch never finds anything after the first one, since the hub bounces every subsequent search as being within the minimm search interval. 6. Unless I've missed something, which is quite possible, users in the wait list who aren't online are shown only with their CIDs? I've created a "Downloaders" database/window that shows how much has been down/up loaded from each user you've down/up loaded from/to. I had this on an earlier Valknut port and now wouldn't/couldn't live without it. It tells you who might be a good target for future downloads (it also shows max/average speed for each). To do this it hooks into the DownloadManagerListener, UploadManagerListener, BufferedSocketListener, ClientManagerListener, and QueueManagerListener (to collect nicks for people before you've downloaded from them). The other advantage is that my wait list uses THIS database to provide real nicks. Guess that's more a suggestion than a bug, sorry. There are a bunch of other things of lesser import, but I'll stop for now. Hope some of this is useful, if not, just send a nuke my way! Regards and keep up the good work. "SomeQuestions" |
From: poy <po...@12...> - 2007-11-01 00:37:09
|
at the moment every frame window in DC++ is using ::WidgetFactory (in win32) as a base class instead of SmartWin::WidgetFactory; so writing a link in eg the message input textbox in hubframe/PM and double-clicking it opens the web-browser... same goes with several other dialogs. should the double-click parsing be moved in hubframe/PM chat controls instead of being in the custom WidgetTextBox itself? poy |
From: Jacek S. <arn...@gm...> - 2007-10-31 23:01:44
|
Reasonable. thanks /J Fredrik Ullner wrote: > The included patch will remove the restriction set in > ShareManager.cpp, where file names containing a dollar sign ('$') will > not be shared. This restriction is obsolete since DC++ only requests > (and accept requests) with a file's TTH, and not the name. |
From: Jacek S. <arn...@gm...> - 2007-10-31 23:00:49
|
Patched poy wrote: > magnet dialog ported, as long as its commented code (which is still > commented out for now). > changed some radio buttons IDs to make sure they were ordered correctly... I thought this depended on the declaration order in the rc, not the id order... > > also, small fixes in fav hubs, including changing ::WidgetFactory to > SmartWin::WidgetFactory so that a double-click on a link in one of the > textboxes doesn't get parsed. Ok. thanks /j |
From: Fredrik U. <ul...@gm...> - 2007-10-31 13:00:46
|
The included patch will remove the restriction set in ShareManager.cpp, where file names containing a dollar sign ('$') will not be shared. This restriction is obsolete since DC++ only requests (and accept requests) with a file's TTH, and not the name. -- Fredrik Ullner |
From: poy <po...@12...> - 2007-10-31 08:36:22
|
magnet dialog ported, as long as its commented code (which is still commented out for now). changed some radio buttons IDs to make sure they were ordered correctly... also, small fixes in fav hubs, including changing ::WidgetFactory to SmartWin::WidgetFactory so that a double-click on a link in one of the textboxes doesn't get parsed. file added: win32/MagnetDlg.cpp poy |
From: poy <po...@12...> - 2007-10-30 21:59:03
|
re-sending this: > this is a small patch to re-order windows auto-opening (we discussed of it > on the private hub...). system log is always first, because it's > important. > as for fav hubs and public hubs, if you auto-open them you want to use > them > on their opening, so i've moved them to last so that they are the most in > the foreground. poy |