dcplusplus-devel

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

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

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. 

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