dcplusplus-devel — Developer's list

Re: [dcplusplus-devel] patch: chat refactoring

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

Sounds reasonable - go ahead...

/J

poy wrote:
> as there are many commonalities between hub and PM windows, here is a 
> proposal to group the duplicated code into a new AspectChat class.
> as a start, i've only moved the /clear stuff, but there are of course a 
> lot more methods that could be moved later on.
> 
> poy
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

[dcplusplus-devel] patch: chat refactoring

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

as there are many commonalities between hub and PM windows, here is a 
proposal to group the duplicated code into a new AspectChat class.
as a start, i've only moved the /clear stuff, but there are of course a lot 
more methods that could be moved later on.

poy 

[dcplusplus-devel] string stop...

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

Hi, just uploaded the pot's to launchpad so no new strings until release please...

/J

[dcplusplus-devel] Translations...

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

Ok, so later today I'll upload the new translations to lp so it's freeze time in a few hours - 
translators, from tomorrow and on you have a few days =)

Thanks/J

Re: [dcplusplus-devel] [dwt] being able to capture all messages in dialog message loops

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

Hm,

This should probably be per dialog (per message loop...) then...it certainly shouldn't be the same 
filter as for windows at least...maybe it would make sense to add some sort of message loop class 
which takes care of these details and works for both windows and dialogs?

/J

poy wrote:
> the addFilter/etc functions in dwt::Application are useful when one wants to 
> capture all messages sent in the main message loop; for example, they are 
> used to dispatch key presses to the help window when it is opened.
> 
> however, when a dialog opens, it enters into its own message loop, so 
> messages aren't sent anymore to these filter functions. it would be nice to 
> have similar filter functions that catch all messages sent in dialog message 
> loops (they are caught in Policies::modalDialog).
> the use case for DC++ is being able to forward key presses to the help 
> window when it is opened from the settings dialog.
> 
> poy 

[dcplusplus-devel] [dwt] being able to capture all messages in dialog message loops

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

the addFilter/etc functions in dwt::Application are useful when one wants to 
capture all messages sent in the main message loop; for example, they are 
used to dispatch key presses to the help window when it is opened.

however, when a dialog opens, it enters into its own message loop, so 
messages aren't sent anymore to these filter functions. it would be nice to 
have similar filter functions that catch all messages sent in dialog message 
loops (they are caught in Policies::modalDialog).
the use case for DC++ is being able to forward key presses to the help 
window when it is opened from the settings dialog.

poy 

Re: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable

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

Ok, I'll take poy's solution as an intermediate solution since it might take a while before accels 
get properly implemented...typedtable is not always used so it makes sense to keep it in table for 
now, and then we'll see...

/J

poy wrote:
> i linked to that thread so that patch can go there; also, i guess Jacek's 
> comments in there apply to your patch too since it's basically the same as 
> the 2nd one i posted, except yours applies only to TypedTable's whereas mine 
> was about making it for all Table's.
> 
> poy
> 

Re: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable

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

i linked to that thread so that patch can go there; also, i guess Jacek's 
comments in there apply to your patch too since it's basically the same as 
the 2nd one i posted, except yours applies only to TypedTable's whereas mine 
was about making it for all Table's.

poy

----- Original Message ----- 
From: "Pär Björklund" <per...@gm...>
To: "poy" <po...@12...>; "Patches & development discussion" 
<dcp...@li...>
Sent: Monday, July 07, 2008 4:35 PM
Subject: Re: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable


>I don't know much about Smartwin/DWT but your patch linked to in that
> thread seems overly complex for such a smal feature Poy.
>
> And looking at the tryFire code it seems to not follow the Windows way
> of short circuiting the message loop once a message is deemed handled.
> This could probably lead to some interesting behavior where two
> different handlers think they handled the message. Could probably lead
> to handler ordering bugs and other things that are unpleasant to track
> down.
>
> I did not try my patch that much but it seems to give the expected
> behavior, please give an example where it would fail.
>
> On Mon, Jul 7, 2008 at 2:49 PM, poy <po...@12...> wrote:
>> https://bugs.launchpad.net/dcplusplus/+bug/203763
>>
>> poy
>>
>> ----- Original Message -----
>> From: Pär Björklund
>> To: dcp...@li...
>> Sent: Saturday, July 05, 2008 1:35 PM
>> Subject: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable
>>
>>
>> A small patch to fix the ctrl+a handler for TypedTable
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>
>>
>>
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>
>
> 

Re: [dcplusplus-devel] Patch: made SearchFrame::openWindowcompilable in gcc and msvc

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

i asked about this in ##iso-c++ on freenode and opinions were mitigated; but 
we agreed on concluding that using default arguments with binders is 
undocumented and that one shouldn't rely on it.

the tr1 draft doesn't mention any default argument.
however, the current C++0x draft 
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2691.pdf) contains 
(page 180):
"The return type, the parameter-type-list, the ref-qualifier, and the 
cv-qualifier-seq, but not the default arguments (8.3.6) or the exception 
specification (15.4), are part of the function type. [ Note: function types 
are checked during the assignments and initializations of 
pointer-to-functions, reference-to-functions, and 
pointer-to-member-functions. -end note ]"

so in order to get rid of these default arguments, i think Pär's patch is 
the best option.

(attached is the chat log, if anyone's interested...)

poy

----- Original Message ----- 
From: "Pär Björklund" <per...@gm...>
To: "Patches & development discussion" 
<dcp...@li...>
Sent: Monday, July 07, 2008 12:22 AM
Subject: Re: [dcplusplus-devel] Patch: made 
SearchFrame::openWindowcompilable in gcc and msvc


>I know that the provided patch is not pretty so it would be nice if
> someone else could verify my results as well.
>
> MSVC seems to be ok with removing the default values.
> g++ still complains about unresolved overload even if the default
> values are removed.
>
> On Sun, Jul 6, 2008 at 10:44 PM, Jacek Sieka <arn...@gm...> 
> wrote:
>>
>> I think a better solution would be to remove the defaults on the 
>> parameters, no? Otherwise both are reasonable candidates if you have only 
>> one parameter (I have no intention of investigating what the standard 
>> actually says in this case). I have neither msvc nor gcc4.3 so I can't 
>> verify it though...
>>
>> /J
>>
>> On Sat, Jul 5, 2008 at 1:35 PM, Pär Björklund <per...@gm...> 
>> wrote:
>>>
>>> Well the subject says it all. Fixed the SearchFrame::openWindow to 
>>> compile with both g++ 4.3 alpha and msvc 9. Had to resort to creating 
>>> two separate functions to avoid the unambiguous overload error.
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> dcplusplus-devel mailing list
>>> dcp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>>
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
> 

Re: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable

[P. B. <per...@gm...>]

I don't know much about Smartwin/DWT but your patch linked to in that
thread seems overly complex for such a smal feature Poy.

And looking at the tryFire code it seems to not follow the Windows way
of short circuiting the message loop once a message is deemed handled.
This could probably lead to some interesting behavior where two
different handlers think they handled the message. Could probably lead
to handler ordering bugs and other things that are unpleasant to track
down.

I did not try my patch that much but it seems to give the expected
behavior, please give an example where it would fail.

On Mon, Jul 7, 2008 at 2:49 PM, poy <po...@12...> wrote:
> https://bugs.launchpad.net/dcplusplus/+bug/203763
>
> poy
>
> ----- Original Message -----
> From: Pär Björklund
> To: dcp...@li...
> Sent: Saturday, July 05, 2008 1:35 PM
> Subject: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable
>
>
> A small patch to fix the ctrl+a handler for TypedTable
>
>
>
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>
>
>
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>

Re: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable

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

https://bugs.launchpad.net/dcplusplus/+bug/203763

poy

----- Original Message ----- 
From: Pär Björklund
To: dcp...@li...
Sent: Saturday, July 05, 2008 1:35 PM
Subject: [dcplusplus-devel] Patch: Fixed ctrl+a handler for TypedTable


A small patch to fix the ctrl+a handler for TypedTable






-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08



_______________________________________________
dcplusplus-devel mailing list
dcp...@li...
https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel 

Re: [dcplusplus-devel] Patch: made SearchFrame::openWindow compilable in gcc and msvc

[P. B. <per...@gm...>]

I know that the provided patch is not pretty so it would be nice if
someone else could verify my results as well.

MSVC seems to be ok with removing the default values.
g++ still complains about unresolved overload even if the default
values are removed.

On Sun, Jul 6, 2008 at 10:44 PM, Jacek Sieka <arn...@gm...> wrote:
>
> I think a better solution would be to remove the defaults on the parameters, no? Otherwise both are reasonable candidates if you have only one parameter (I have no intention of investigating what the standard actually says in this case). I have neither msvc nor gcc4.3 so I can't verify it though...
>
> /J
>
> On Sat, Jul 5, 2008 at 1:35 PM, Pär Björklund <per...@gm...> wrote:
>>
>> Well the subject says it all. Fixed the SearchFrame::openWindow to compile with both g++ 4.3 alpha and msvc 9. Had to resort to creating two separate functions to avoid the unambiguous overload error.
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>

Re: [dcplusplus-devel] Patch: made SearchFrame::openWindow compilable in gcc and msvc

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

I think a better solution would be to remove the defaults on the parameters,
no? Otherwise both are reasonable candidates if you have only one parameter
(I have no intention of investigating what the standard actually says in
this case). I have neither msvc nor gcc4.3 so I can't verify it though...

/J

On Sat, Jul 5, 2008 at 1:35 PM, Pär Björklund <per...@gm...>
wrote:

> Well the subject says it all. Fixed the SearchFrame::openWindow to compile
> with both g++ 4.3 alpha and msvc 9. Had to resort to creating two separate
> functions to avoid the unambiguous overload error.
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>

Re: [dcplusplus-devel] White space, cross compiling and branch / mod friendly translations

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

Michael Jones wrote:
> Just got a few queries / suggestions . . . . 
> 
> In October i sent in a patch to this mailing list to remove a lot of white space from the source code, but since it was so big, it needed to be "authorized" or something.  Since a lot has changed in the source since then, the old one i did is useless and will need to be redone (and never turned up here).  So to prevent this issue in the future can i commit whitespace removal directly, or should i open a launchpad bug report, which could always stay open and just receive patches for removing white space ?
Commit janitorial tasks directly

> On a side note with this, i remember that in the copy write notice on the top of all the DC++ files there was a full stop followed by two spaces, it would make white space finding and removal a lot easier if this was changed to one space following the full stop.  So in a future whitespace patch, would it be acceptable to remove this extra space from the copy write notices ?
Feel free to remove any redundant whitespace (and convert spaces to tabs where needed, assuming 4 
spaces per tab.

> Regarding cross compiling, when i was using 32bit ubuntu, and now on 64bit debian this had to be added to the command line scons call
> prefix=i586-mingw32msvc-
> whereas on compiling with windows it isn't needed.
> So could a SConscript change be made so that if OS == Windows, leave as is, and if OS == Linux automatically use that prefix.  Just to make it nicer / easier.
> Or is there a case where i386 mingw maybe used on Linux ?
It depends on the linux distribution...debian uses i386 for example...you can put that (or any) 
option in a file called custom.py:
------ cut
prefix = "blabla"
------ cut

> Regarding translations, FleetCommand mentioned earlier that BCDC uses PM in the time sense, and this could conflict with the User Commands page occurrence of PM (for Private Message), and i thought in this case, the User Commands one could just be changed to Private Message.
> This also got me thinking, since BCDC uses launchpad now for the bzr repository, they have to sync translations with DC++'s updates.  Whereas DC++ has the nice launchpad translation page, BCDC is deprived of this.  To make this nicer for branches / mod's of DC++ i thought that a "dummy.cpp" file could be added to both dcpp and win32 directories, which is skipped from compiling, but scanned by gettext.  This would mean that if mod authors could put text's in there, to be translated, and would turn up on the launchpad's translation page.  And it wouldn't / shouldn't affect DC++ adversely.
Mods should keep their own translation pages - I don't want to burden translators with extra work 
that they might not want to do.

[dcplusplus-devel] White space, cross compiling and branch / mod friendly translations

[Michael J. <mrm...@ho...>]

Just got a few queries / suggestions . . . . 

In October i sent in a patch to this mailing list to remove a lot of white space from the source code, but since it was so big, it needed to be "authorized" or something.  Since a lot has changed in the source since then, the old one i did is useless and will need to be redone (and never turned up here).  So to prevent this issue in the future can i commit whitespace removal directly, or should i open a launchpad bug report, which could always stay open and just receive patches for removing white space ?

On a side note with this, i remember that in the copy write notice on the top of all the DC++ files there was a full stop followed by two spaces, it would make white space finding and removal a lot easier if this was changed to one space following the full stop.  So in a future whitespace patch, would it be acceptable to remove this extra space from the copy write notices ?


Regarding cross compiling, when i was using 32bit ubuntu, and now on 64bit debian this had to be added to the command line scons call
prefix=i586-mingw32msvc-
whereas on compiling with windows it isn't needed.
So could a SConscript change be made so that if OS == Windows, leave as is, and if OS == Linux automatically use that prefix.  Just to make it nicer / easier.
Or is there a case where i386 mingw maybe used on Linux ?


Regarding translations, FleetCommand mentioned earlier that BCDC uses PM in the time sense, and this could conflict with the User Commands page occurrence of PM (for Private Message), and i thought in this case, the User Commands one could just be changed to Private Message.
This also got me thinking, since BCDC uses launchpad now for the bzr repository, they have to sync translations with DC++'s updates.  Whereas DC++ has the nice launchpad translation page, BCDC is deprived of this.  To make this nicer for branches / mod's of DC++ i thought that a "dummy.cpp" file could be added to both dcpp and win32 directories, which is skipped from compiling, but scanned by gettext.  This would mean that if mod authors could put text's in there, to be translated, and would turn up on the launchpad's translation page.  And it wouldn't / shouldn't affect DC++ adversely.

thanks
MikeJJ
_________________________________________________________________

http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/

[dcplusplus-devel] Translation stop

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

Hi,

0.707 is nearing so no more string updates - translators, this is where you come in =)

/Jacek

Re: [dcplusplus-devel] patch: MSVC compiling

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

i've looked into the errors i was getting when trying to build intl/ with 
MSVC and they were pretty easy to solve; it was only a matter of changing 
#define's in config.h. so using precompiled libraries may not be needed 
after all. :)

in the attached patch i've created 2 config.h files, 1 for each compiler; to 
avoid having "#ifdef compiler"s all over the config file. also, tsearch 
added as MSVC needs it. things should remain exactly the same as before when 
using GCC.

poy 

Re: [dcplusplus-devel] patch: MSVC compiling

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

poy wrote:
>> Please commit boost and openssl upgrade, const / other minor code fixes 
>> that also work for gcc
> 
> i've committed all of it except the intl and openssl changes; you may want 
> to read the paragraph about tr1 i've added in Compile.txt.
oh, and tr1 containers (unordered*) are not part of boost (yet)...

/J

Re: [dcplusplus-devel] patch: MSVC compiling

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

poy wrote:
>> Please commit boost and openssl upgrade, const / other minor code fixes 
>> that also work for gcc
> 
> i've committed all of it except the intl and openssl changes; you may want 
> to read the paragraph about tr1 i've added in Compile.txt.
> on boost upgrade: are there any particular changes to do in the boost/ dir 
> once it's updated? it works fine by simply updating but still...
Not really - I can't decide whether it's better to add just the bare minimum we need or everything - 
in the first case scons works faster, in the second it's easier to update...overall I'd prefer the 
first option - one fine day I must have a look at how to make scons skip scanning the boost headers 
for changes when doing its dep scan...

> on openssl upgrade: should the libs in openssl/lib be updated too? it works 
> fine by simply updating header files in openssl/include but still...
Definately - otherwise it's still the old version of the actual code (without whatever fixes they 
put in between the versions)!

> poy 
> 
> 

Re: [dcplusplus-devel] patch: MSVC compiling

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

> Please commit boost and openssl upgrade, const / other minor code fixes 
> that also work for gcc

i've committed all of it except the intl and openssl changes; you may want 
to read the paragraph about tr1 i've added in Compile.txt.
on boost upgrade: are there any particular changes to do in the boost/ dir 
once it's updated? it works fine by simply updating but still...
on openssl upgrade: should the libs in openssl/lib be updated too? it works 
fine by simply updating header files in openssl/include but still...

poy 

Re: [dcplusplus-devel] patch: MSVC compiling

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

Please commit boost and openssl upgrade, const / other minor code fixes that also work for gcc

don't include unsorted* all over dwt - create a dwt_unsorted* and include that instead

I still need to think about the added libs (compiled openssl, intl, etc), and what implications that 
might have...

/J

poy wrote:
> i have tried again using the boost folder from the current repository, and 
> it appears the include error was much easier to solve than updating all 
> boost files... all i had to do was make the "BOOST_HAS_GCC_TR1" define 
> available for MSVC too (yes, it doesn't sound correct, but boost assumes you 
> have all tr1 containers only in that case; that's up to future boost 
> versions to fix that...).
> 
> note; when compiling with MSVC 9, boost warns "Unknown compiler version - 
> please run the configure tests and report the results". this is not 
> important, and upgrading boost to 1.35 would remove the warning.
> 
> the new patch is much lighter and hopefully easier to read. its 1MB+ size is 
> caused by the pre-compiled openssl libraries that are included.
> 
> the mailing-list still won't accept it so it's here: 
> http://www.sendspace.com/file/gmlr5h
> 
> poy
> 
> ----- Original Message ----- 
> From: "poy" <po...@12...>
> To: "dcplusplus-devel" <dcp...@li...>
> Sent: Sunday, May 18, 2008 1:52 AM
> Subject: [dcplusplus-devel] patch: MSVC compiling
> 
> 
>> note; mostly because of the boost updating, the patch is huge (50 MB) so
>> i've uploaded it here: http://www.sendspace.com/file/8htnse
>>
>> since the MSVC people recently released the final version of their tr1
>> add-on for MSVC 9 (2008), i tried to compile DC++ again with MSVC. i must
>> say i've been pleasantly surprised by the fact that it took few changes
>> (code-wise) for DC++ to be compilable with MSVC again. moreover, there is 
>> no
>> added work-around; changes suggested/forced by MSVC actually all make 
>> sense.
>> besides minor changes here and there, the patch fixes the following in 
>> order
>> to make DC++ compilable with MSVC (it's roughly a change-log of what i had
>> to do...):
>>
>> - SCons was always using MinGW and the Environment creation wasn't correct
>> after my recent help changes; fixed.
>>
>> - updated boost to 1.35 and added the fusion/ sub-directory, required when
>> compiling with MSVC.
>>
>> - include fixes for tr1 containers in dwt (since GCC uses <tr1/X> and
>> MSVC/STLPort use <X>).
>>
>> - operator() had to be const in dwt dispatchers.
>>
>> - added precompiled header generation with MSVC using the SCons PCH 
>> builder.
>>
>> - fixed some duplicate IDC_STATIC ids, and made 3 more strings 
>> translatable.
>>
>> - openssl: added .lib files in openssl/lib compiled statically with MASM
>> (optimized); updated include files to the latest version.
>>
>> - intl: gettext tools can't be compiled with MSVC anymore ("MS Visual 
>> C/C++
>> with "nmake" is no longer supported." in the gettext win32-readme), so 
>> i've
>> downloaded compiled .lib and .dll intl files from
>> http://www.gtk.org/download-windows.html and that library is dynamically
>> linked when compiling with MSVC (see comments in intl/SConscript).
>>
>> - added a little trick to add a Common Controls 6 manifest directly in the
>> exe.
>>
>> - updated Compile.txt; there's a link to that tr1 feature pack. i've 
>> stated
>> that MSVC is supported again (provided that one has MSVC 9 and the tr1
>> add-on) and boost/STLPort means of getting tr1 containers are deprecated.
>>
>> poy
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>
>>
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> 

Re: [dcplusplus-devel] patch: MSVC compiling

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

i have tried again using the boost folder from the current repository, and 
it appears the include error was much easier to solve than updating all 
boost files... all i had to do was make the "BOOST_HAS_GCC_TR1" define 
available for MSVC too (yes, it doesn't sound correct, but boost assumes you 
have all tr1 containers only in that case; that's up to future boost 
versions to fix that...).

note; when compiling with MSVC 9, boost warns "Unknown compiler version - 
please run the configure tests and report the results". this is not 
important, and upgrading boost to 1.35 would remove the warning.

the new patch is much lighter and hopefully easier to read. its 1MB+ size is 
caused by the pre-compiled openssl libraries that are included.

the mailing-list still won't accept it so it's here: 
http://www.sendspace.com/file/gmlr5h

poy

----- Original Message ----- 
From: "poy" <po...@12...>
To: "dcplusplus-devel" <dcp...@li...>
Sent: Sunday, May 18, 2008 1:52 AM
Subject: [dcplusplus-devel] patch: MSVC compiling


> note; mostly because of the boost updating, the patch is huge (50 MB) so
> i've uploaded it here: http://www.sendspace.com/file/8htnse
>
> since the MSVC people recently released the final version of their tr1
> add-on for MSVC 9 (2008), i tried to compile DC++ again with MSVC. i must
> say i've been pleasantly surprised by the fact that it took few changes
> (code-wise) for DC++ to be compilable with MSVC again. moreover, there is 
> no
> added work-around; changes suggested/forced by MSVC actually all make 
> sense.
> besides minor changes here and there, the patch fixes the following in 
> order
> to make DC++ compilable with MSVC (it's roughly a change-log of what i had
> to do...):
>
> - SCons was always using MinGW and the Environment creation wasn't correct
> after my recent help changes; fixed.
>
> - updated boost to 1.35 and added the fusion/ sub-directory, required when
> compiling with MSVC.
>
> - include fixes for tr1 containers in dwt (since GCC uses <tr1/X> and
> MSVC/STLPort use <X>).
>
> - operator() had to be const in dwt dispatchers.
>
> - added precompiled header generation with MSVC using the SCons PCH 
> builder.
>
> - fixed some duplicate IDC_STATIC ids, and made 3 more strings 
> translatable.
>
> - openssl: added .lib files in openssl/lib compiled statically with MASM
> (optimized); updated include files to the latest version.
>
> - intl: gettext tools can't be compiled with MSVC anymore ("MS Visual 
> C/C++
> with "nmake" is no longer supported." in the gettext win32-readme), so 
> i've
> downloaded compiled .lib and .dll intl files from
> http://www.gtk.org/download-windows.html and that library is dynamically
> linked when compiling with MSVC (see comments in intl/SConscript).
>
> - added a little trick to add a Common Controls 6 manifest directly in the
> exe.
>
> - updated Compile.txt; there's a link to that tr1 feature pack. i've 
> stated
> that MSVC is supported again (provided that one has MSVC 9 and the tr1
> add-on) and boost/STLPort means of getting tr1 containers are deprecated.
>
> poy
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
> 

[dcplusplus-devel] patch: MSVC compiling

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

note; mostly because of the boost updating, the patch is huge (50 MB) so 
i've uploaded it here: http://www.sendspace.com/file/8htnse

since the MSVC people recently released the final version of their tr1 
add-on for MSVC 9 (2008), i tried to compile DC++ again with MSVC. i must 
say i've been pleasantly surprised by the fact that it took few changes 
(code-wise) for DC++ to be compilable with MSVC again. moreover, there is no 
added work-around; changes suggested/forced by MSVC actually all make sense. 
besides minor changes here and there, the patch fixes the following in order 
to make DC++ compilable with MSVC (it's roughly a change-log of what i had 
to do...):

- SCons was always using MinGW and the Environment creation wasn't correct 
after my recent help changes; fixed.

- updated boost to 1.35 and added the fusion/ sub-directory, required when 
compiling with MSVC.

- include fixes for tr1 containers in dwt (since GCC uses <tr1/X> and 
MSVC/STLPort use <X>).

- operator() had to be const in dwt dispatchers.

- added precompiled header generation with MSVC using the SCons PCH builder.

- fixed some duplicate IDC_STATIC ids, and made 3 more strings translatable.

- openssl: added .lib files in openssl/lib compiled statically with MASM 
(optimized); updated include files to the latest version.

- intl: gettext tools can't be compiled with MSVC anymore ("MS Visual C/C++ 
with "nmake" is no longer supported." in the gettext win32-readme), so i've 
downloaded compiled .lib and .dll intl files from 
http://www.gtk.org/download-windows.html and that library is dynamically 
linked when compiling with MSVC (see comments in intl/SConscript).

- added a little trick to add a Common Controls 6 manifest directly in the 
exe.

- updated Compile.txt; there's a link to that tr1 feature pack. i've stated 
that MSVC is supported again (provided that one has MSVC 9 and the tr1 
add-on) and boost/STLPort means of getting tr1 containers are deprecated.

poy 

Re: [dcplusplus-devel] Patch: multicopy in hubframe userlist

[<co...@pa...>]

co...@pa... wrote:
> In response to https://bugs.launchpad.net/bugs/230972

Whoops, missed a file. This patch actually compiles.

-cologic

[dcplusplus-devel] Patch: multicopy in hubframe userlist

[<co...@pa...>]

In response to https://bugs.launchpad.net/bugs/230972

-cologic