dcplusplus-devel — Developer's list

[dcplusplus-devel] [Fwd: DC++ on FileHippo.com]

[Jacek S. <arn...@gm...>]

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/

Re: [dcplusplus-devel] patch: new black arrows for list views

[Jacek S. <arn...@gm...>]

> 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

Re: [dcplusplus-devel] Fw: patch: let windows draw ListView arrows

[Jacek S. <arn...@gm...>]

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

[dcplusplus-devel] Fw: patch: let windows draw ListView arrows

[poy <po...@12...>]

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
>>
>>
> 

[dcplusplus-devel] Fw: patch: new black arrows for list views

[poy <po...@12...>]

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 

Re: [dcplusplus-devel] patch: let windows draw ListView arrows

[poy <po...@12...>]

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
>
> 

Re: [dcplusplus-devel] patch: let windows draw ListView arrows

[Jacek S. <arn...@gm...>]

> 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

Re: [dcplusplus-devel] patch: new black arrows for list views

[Jacek S. <arn...@gm...>]

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
> 
> 

Re: [dcplusplus-devel] patch: let windows draw ListView arrows

[poy <po...@12...>]

> 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 

[dcplusplus-devel] patch: new black arrows for list views

[poy <po...@12...>]

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 

Re: [dcplusplus-devel] patch: listviews down arrow fix

[poy <po...@12...>]

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 

[dcplusplus-devel] patch: listviews down arrow fix

[poy <po...@12...>]

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 

Re: [dcplusplus-devel] Source level bug (probably) report

[Jacek S. <arn...@gm...>]

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
> 
> 
> 

Re: [dcplusplus-devel] patch: let windows draw ListView arrows

[Jacek S. <arn...@gm...>]

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

[dcplusplus-devel] patch: let windows draw ListView arrows

[poy <po...@12...>]

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 

Re: [dcplusplus-devel] Source level bug (probably) report

[Jacek S. <arn...@gm...>]

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

Re: [dcplusplus-devel] Source level bug (probably) report

[Fredrik U. <ul...@gm...>]

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

Re: [dcplusplus-devel] Source level bug (probably) report

[James R. <si...@wa...>]

--------------------------------------------------
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 

[dcplusplus-devel] Source level bug (probably) report

[itinerants <iti...@ho...>]

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"

[dcplusplus-devel] double-clicking in textboxes

[poy <po...@12...>]

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 

Re: [dcplusplus-devel] Patch to remove restriction with sharing files named with a dollar sign

[Jacek S. <arn...@gm...>]

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.

Re: [dcplusplus-devel] patch: magnet dialog + favhubs

[Jacek S. <arn...@gm...>]

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

[dcplusplus-devel] Patch to remove restriction with sharing files named with a dollar sign

[Fredrik U. <ul...@gm...>]

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

[dcplusplus-devel] patch: magnet dialog + favhubs

[poy <po...@12...>]

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 

[dcplusplus-devel] patch: auto-opening windows reordering

[poy <po...@12...>]

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