dcplusplus-devel — Developer's list

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

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

little fix, not tested of course.

as for ':', have a look at line 198 of Util.cpp. ;)

poy

----- Original Message ----- 
From: "itinerants" <iti...@ho...>
To: <dcp...@li...>
Sent: Wednesday, November 14, 2007 11:24 AM
Subject: [dcplusplus-devel] ValidateFileName problem on Macintosh...


> In file... Util.cpp
> Routine... Util::validateFileName
>
> This attempts to convert an arbitrary "filename" into something that'll 
> work
> as a file name on the system it's running on. For example, the url of a 
> hub
> file list (" http://dchublist.com/hublist.xml.bz2") into a usable 
> filename.
>
> I can speak only for Macintosh, but '/' (and btw ':') need to be on the 
> list
> of "badChars" outside the "#ifdef _WIN32" switch, otherwise the filename
> produced won't work.
>
> R
>
>
>
> -------------------------------------------------------------------------
> 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] off mail list

[<edv...@zo...>]

please get me off your mailing-lists

Re: [dcplusplus-devel] ValidateFileName problem on Macintosh...

[<edv...@zo...>]

Please get me off the mailinglist




Citeren itinerants <iti...@ho...>:

> In file... Util.cpp
> Routine... Util::validateFileName
>
> This attempts to convert an arbitrary "filename" into something that'll work
> as a file name on the system it's running on. For example, the url of a hub
> file list (" http://dchublist.com/hublist.xml.bz2") into a usable filename.
>
> I can speak only for Macintosh, but '/' (and btw ':') need to be on the list
> of "badChars" outside the "#ifdef _WIN32" switch, otherwise the filename
> produced won't work.
>
> R
>
>
>
> -------------------------------------------------------------------------
> 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] ValidateFileName problem on Macintosh...

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

In file... Util.cpp
Routine... Util::validateFileName

This attempts to convert an arbitrary "filename" into something that'll work
as a file name on the system it's running on. For example, the url of a hub
file list (" http://dchublist.com/hublist.xml.bz2") into a usable filename.

I can speak only for Macintosh, but '/' (and btw ':') need to be on the list
of "badChars" outside the "#ifdef _WIN32" switch, otherwise the filename
produced won't work.

R

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

[<edv...@zo...>]

PLEASE skipp me of your mailinglist



Citeren James Ross <si...@wa...>:

> --------------------------------------------------
> From: "poy" <po...@12...>
> Sent: Friday, November 09, 2007 6:11 PM
> To: "dcplusplus-devel" <dcp...@li...>
> Subject: [dcplusplus-devel] Fw:  patch: let windows draw ListView arrows
>
>> 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...
>
> Unfortunately, this introduces a dependency on the ordering of C++ static
> initialisers in separate translation units - which is undefined by the C++
> spec, as far as I can see.
>
> The static initialisers are all done before the 'main' starts executing, and
> this particular call chain is the problem:
>
> win32\WinUtil.cpp: const SmartWin::WidgetListView::Seed
> WinUtil::Seeds::listView;
> -> causes the static construction of ->
> smartwin\source\widgets\WidgetListView.cpp: WidgetListView::Seed::Seed
> -> calls common controls check, which ultimately uses the static lock at ->
> smartwin\source\LibraryLoader.cpp: Utilities::CriticalSection
> LibraryLoader::itsCs;
>
> Now, the problem is that the initialisation of LibraryLoader::itsCs is also
> a static initialiser. If the itsCs lock is not initialised before the Seed
> constructor, the application crashes on startup.
>
> Which is exactly what happens for me. :-(
>
> The simplest, but less than ideal, fix I've found is to move the common
> control check in the Seed constructor into WidgetListView::create. Better
> ideas welcome - especially ones which don't do the check on every list view
> creation!
>
> Note that the most likely reason this has affected me and not others is that
> I'm probably the only one building with MSVC. I am only to assume GCC is
> being lucky here, as I can't find any indication that it's actually a bug in
> either compiler, it's just undefined behaviour, which is a right pain.
>
> --
> James Ross
>
> P.S. I hope I got all that right, I've spent most of the day periodically
> searching the little information on the web about C++ static initialisers,
> their orderings and compiler-specific behaviours and it's all starting to
> blur a bit.
>
>
> -------------------------------------------------------------------------
> 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
>

Re: [dcplusplus-devel] patch: boost build script

[<edv...@zo...>]

PLEASE skipp me of your mailinglist











Citeren Jacek Sieka <arn...@gm...>:

> The first part is obviously wrong and a copypaste leftover, but I 
> think the second part should stay,
> boost should not need the standard dc++ include paths to compile...
>
> /J
>
> poy wrote:
>> this is a patch i always apply before compiling DC++; otherwise, i get
>> file access errors ("couldn't open boost/*") when SCons gets to compile
>> boost.
>> apparently i'm the only one who needs this, but here it is for the
>> record. i don't mind if it's not applied as my bat scripts handle it
>> automagically. :)
>>
>> 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
>

Re: [dcplusplus-devel] patch: boost build script

[<edv...@zo...>]

Citeren Jacek Sieka <arn...@gm...>:

> The first part is obviously wrong and a copypaste leftover, but I 
> think the second part should stay,
> boost should not need the standard dc++ include paths to compile...
>
> /J
>
> poy wrote:
>> this is a patch i always apply before compiling DC++; otherwise, i get
>> file access errors ("couldn't open boost/*") when SCons gets to compile
>> boost.
>> apparently i'm the only one who needs this, but here it is for the
>> record. i don't mind if it's not applied as my bat scripts handle it
>> automagically. :)
>>
>> 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
>

Re: [dcplusplus-devel] patch: boost build script

[<edv...@zo...>]

Citeren Jacek Sieka <arn...@gm...>:

> The first part is obviously wrong and a copypaste leftover, but I 
> think the second part should stay,
> boost should not need the standard dc++ include paths to compile...
>
> /J
>
> poy wrote:
>> this is a patch i always apply before compiling DC++; otherwise, i get
>> file access errors ("couldn't open boost/*") when SCons gets to compile
>> boost.
>> apparently i'm the only one who needs this, but here it is for the
>> record. i don't mind if it's not applied as my bat scripts handle it
>> automagically. :)
>>
>> 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
>

Re: [dcplusplus-devel] patch: boost build script

[<edv...@zo...>]

Citeren Jacek Sieka <arn...@gm...>:

> The first part is obviously wrong and a copypaste leftover, but I 
> think the second part should stay,
> boost should not need the standard dc++ include paths to compile...
>
> /J
>
> poy wrote:
>> this is a patch i always apply before compiling DC++; otherwise, i get
>> file access errors ("couldn't open boost/*") when SCons gets to compile
>> boost.
>> apparently i'm the only one who needs this, but here it is for the
>> record. i don't mind if it's not applied as my bat scripts handle it
>> automagically. :)
>>
>> 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
>

Re: [dcplusplus-devel] patch: boost build script

[<edv...@zo...>]

Citeren Jacek Sieka <arn...@gm...>:

> The first part is obviously wrong and a copypaste leftover, but I 
> think the second part should stay,
> boost should not need the standard dc++ include paths to compile...
>
> /J
>
> poy wrote:
>> this is a patch i always apply before compiling DC++; otherwise, i get
>> file access errors ("couldn't open boost/*") when SCons gets to compile
>> boost.
>> apparently i'm the only one who needs this, but here it is for the
>> record. i don't mind if it's not applied as my bat scripts handle it
>> automagically. :)
>>
>> 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
>

Re: [dcplusplus-devel] patch: boost build script

[<edv...@zo...>]

Citeren Jacek Sieka <arn...@gm...>:

> The first part is obviously wrong and a copypaste leftover, but I 
> think the second part should stay,
> boost should not need the standard dc++ include paths to compile...
>
> /J
>
> poy wrote:
>> this is a patch i always apply before compiling DC++; otherwise, i get
>> file access errors ("couldn't open boost/*") when SCons gets to compile
>> boost.
>> apparently i'm the only one who needs this, but here it is for the
>> record. i don't mind if it's not applied as my bat scripts handle it
>> automagically. :)
>>
>> 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] please help me

[ROBERT K. <dob...@ho...>]

how do i unsubscribe to this whatever it is
please help i cant figure it out
i thought i did it once but i guess not because i keep getting the emails
i cant even figure out what its for nor do i know what to do with the info =
i am getting=

Re: [dcplusplus-devel] patch: updates VC headers to match changes in GCC headers

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

--------------------------------------------------
From: "Jacek Sieka" <arn...@gm...>
Sent: Sunday, November 11, 2007 4:23 PM
To: "Patches & development discussion" 
<dcp...@li...>
Subject: Re: [dcplusplus-devel] patch: updates VC headers to match changes 
in	GCC headers

> What's the deal with the min/max comment? afair windows.h defines ugly 
> versions of min/max?

It was all commented out, and all the places which use std::min or std::max 
are wrapped in parentheses as the comment notes (except one). I don't think 
it needs to have the commented-out defines, but the comment could be left 
instead?

> James Ross wrote:
>> Note that there are other patches I've got to completely make building
>> with MSVC work.
> Well, the msvc maintainer post is open =) As long as they're not 
> workarounds for deficiencies in the
> compiler, they're most welcome in the main repository...

Thanks, most of it was making it link with openssl (and compiling openssl 
with the right flags). :)

-- 
James Ross 

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

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

> The simplest, but less than ideal, fix I've found is to move the common
> control check in the Seed constructor into WidgetListView::create. Better
> ideas welcome - especially ones which don't do the check on every list 
> view
> creation!

thought about that, and doing the check on every listview creation was 
definitely a problem to avoid; that's why the function is static in the 
first place.
i just added a debug line in getCommonControlsVersion and i can confirm it's 
only called on the program start, not afterwards when other list views are 
created.

> Note that the most likely reason this has affected me and not others is 
> that
> I'm probably the only one building with MSVC. I am only to assume GCC is
> being lucky here, as I can't find any indication that it's actually a bug 
> in
> either compiler, it's just undefined behaviour, which is a right pain.

if it is undefined behaviour and GCC is only being lucky, it has to be 
fixed, though i don't really know how. however i can imagine that GCC isn't 
only being lucky, but also being smart in that it understands that the 
critical section has to be initialized first...

poy 

Re: [dcplusplus-devel] patch: updates VC headers to match changes inGCC headers

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

good to know MSVC can still build DC++, i'd like to see how you made it =
work. :)

poy
  ----- Original Message -----=20
  From: James Ross=20
  To: DC++ Devel=20
  Sent: Sunday, November 11, 2007 7:42 AM
  Subject: [dcplusplus-devel] patch: updates VC headers to match changes =
inGCC headers


  This patch updates the MSVC desktop headers file to have the necessary =
includes to build, makes sure they are targeting Windows version 5.1 =
(XP) like the GCC ones, and moves the header defines into the GCC =
headers file as they are unnecessary with MSVC (2005).

  Note that there are other patches I've got to completely make building =
with MSVC work.

  --=20
  James Ross


-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  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

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

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

> Unfortunately, this introduces a dependency on the ordering of C++ static 
> initialisers in separate translation units - which is undefined by the C++ 
> spec, as far as I can see.
didn't think of that..

> The simplest, but less than ideal, fix I've found is to move the common 
> control check in the Seed constructor into WidgetListView::create. Better 
> ideas welcome - especially ones which don't do the check on every list view 
> creation!
usually a static (member) function that returns a reference to a static local variable does the
trick and initializes just once in natural order...
> 
> Note that the most likely reason this has affected me and not others is that 
> I'm probably the only one building with MSVC. I am only to assume GCC is 
> being lucky here, as I can't find any indication that it's actually a bug in 
> either compiler, it's just undefined behaviour, which is a right pain.
> 
yup

/J

Re: [dcplusplus-devel] patch: updates VC headers to match changes in GCC headers

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

What's the deal with the min/max comment? afair windows.h defines ugly versions of min/max?

James Ross wrote:
> This patch updates the MSVC desktop headers file to have the necessary
> includes to build, makes sure they are targeting Windows version 5.1
> (XP) like the GCC ones, and moves the header defines into the GCC
> headers file as they are unnecessary with MSVC (2005).
>  
> Note that there are other patches I've got to completely make building
> with MSVC work.
Well, the msvc maintainer post is open =) As long as they're not workarounds for deficiencies in the
compiler, they're most welcome in the main repository...

/J

Re: [dcplusplus-devel] patch: boost build script

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

The first part is obviously wrong and a copypaste leftover, but I think the second part should stay,
boost should not need the standard dc++ include paths to compile...

/J

poy wrote:
> this is a patch i always apply before compiling DC++; otherwise, i get
> file access errors ("couldn't open boost/*") when SCons gets to compile
> boost.
> apparently i'm the only one who needs this, but here it is for the
> record. i don't mind if it's not applied as my bat scripts handle it
> automagically. :)
> 
> poy

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

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

--------------------------------------------------
From: "poy" <po...@12...>
Sent: Friday, November 09, 2007 6:11 PM
To: "dcplusplus-devel" <dcp...@li...>
Subject: [dcplusplus-devel] Fw:  patch: let windows draw ListView arrows

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

Unfortunately, this introduces a dependency on the ordering of C++ static 
initialisers in separate translation units - which is undefined by the C++ 
spec, as far as I can see.

The static initialisers are all done before the 'main' starts executing, and 
this particular call chain is the problem:

win32\WinUtil.cpp: const SmartWin::WidgetListView::Seed 
WinUtil::Seeds::listView;
-> causes the static construction of ->
smartwin\source\widgets\WidgetListView.cpp: WidgetListView::Seed::Seed
-> calls common controls check, which ultimately uses the static lock at ->
smartwin\source\LibraryLoader.cpp: Utilities::CriticalSection 
LibraryLoader::itsCs;

Now, the problem is that the initialisation of LibraryLoader::itsCs is also 
a static initialiser. If the itsCs lock is not initialised before the Seed 
constructor, the application crashes on startup.

Which is exactly what happens for me. :-(

The simplest, but less than ideal, fix I've found is to move the common 
control check in the Seed constructor into WidgetListView::create. Better 
ideas welcome - especially ones which don't do the check on every list view 
creation!

Note that the most likely reason this has affected me and not others is that 
I'm probably the only one building with MSVC. I am only to assume GCC is 
being lucky here, as I can't find any indication that it's actually a bug in 
either compiler, it's just undefined behaviour, which is a right pain.

-- 
James Ross

P.S. I hope I got all that right, I've spent most of the day periodically 
searching the little information on the web about C++ static initialisers, 
their orderings and compiler-specific behaviours and it's all starting to 
blur a bit. 

[dcplusplus-devel] patch: update the main window title

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

update the main window title when the active child frame changes.
i added an event called onTitleChanged in WidgetTabView, not using any 
dispatcher struct but simply with a callback function.
also, i'm not sure about that static_cast from Widget* to WidgetWindow*, but 
it works fine here...

poy 

[dcplusplus-devel] patch: boost build script

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

this is a patch i always apply before compiling DC++; otherwise, i get file 
access errors ("couldn't open boost/*") when SCons gets to compile boost.
apparently i'm the only one who needs this, but here it is for the record. i 
don't mind if it's not applied as my bat scripts handle it automagically. :)

poy 

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

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

fixed, 1 #define to add. :)

poy

----- Original Message ----- 
From: "Jacek Sieka" <arn...@gm...>
To: "dcplusplus-devel" <dcp...@li...>
Cc: <ju...@fi...>
Sent: Friday, November 09, 2007 8:22 PM
Subject: [dcplusplus-devel] [Fwd: DC++ on FileHippo.com]


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

Re: [dcplusplus-devel] patch: update AboutDlg copyright

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

Ok.
/J

James Ross wrote:
> Just updates the about dialog copyright from "2001-2006" to "2001-2007".
>  
> -- 
> James Ross

Re: [dcplusplus-devel] patch: load the correct column info (order + widths) for the transfer view

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

Ah. I was wondering why that didn't work =)

/J

James Ross wrote:
> This has been bugging me for a while, but turns out this was an easy one
> to fix. Smile emoticon
>  
> The columns in the transfer view are now loaded correctly (they were
> already being saved correctly).
>  

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

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

Simple and working is better than not working =) I'll go for the black ones - most people will
probably see the comctl6 ones anyway...(apart from me =)

/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