ATL / WTL / STL

VS 2005, Boost and STLPort

14-Dec-05 9:21

srimayank11_codeproject wrote:
I need to color a button using ATL, WTL or WIN 32 API..I can easily do it using MFC but because of the Application requirementI have to do it by using the above mentioned technologies only.

Here's a good start with WTL:

class CColorButton : public CWindowImpl<CColorButton, CButton> {
public:
   DECLARE_WND_SUPERCLASS(_T("CColorButton"), _T("BUTTON"))
   
   // Don't forget REFLECT_NOTIFICATIONS() in the parent window message map!
   BEGIN_MSG_MAP(CColorButton)
      MSG_OCM_DRAWITEM(OnDrawItem)
   END_MSG_MAP()
   
public:
   void OnDrawItem(UINT uCode, LPDRAWITEMSTRUCT pdis) {
      // Do your owner draw painting here, as prescribed by the MSDN docs
   }
};

Please note that you will have to make your button BS_OWNERDRAW (window style flag). This unfortunately makes the button unable to work properly as a default button. If you need this functionality, I can provide that code as well. I just wanted to make this code as simple and easy to understand as possible, as it illustrates how to draw the button yourself easily. Also, please do not forget to add REFLECT_NOTIFICATIONS() in your parents message handler. If you don't, your button will not be drawn.. at all! Smile | :)

--
Pictures[^] from my Japan trip.

Rob Caldecott14-Dec-05 2:26

Rob Caldecott

14-Dec-05 2:26

As many of you probably know, Visual Studio 2005 contains a nasty std::iostream bug that causes a memory leak. If, like me, you use streams such as stringstream/wstringstream, fstream, etc. you will be affected. The fix is to rebuild the MSVCRT80.DLL, which is a major undertaking and, IMHO, not worth the pain.

Hence I thought I'd investigate STLPort. I have heard good things about this library, and it would allow me to work around the iostream bug, as I wouldn't be using the MS implementation.

However, I also use Boost, and there doesn't seem to be a config for VS 2005 _and_ STLPort! Sob. Has anyone here made the three work together?

The Rob Blog
Google Talk: robert.caldecott

Jörgen Sigvardsson14-Dec-05 9:10

14-Dec-05 9:10

Robert Edward Caldecott wrote:
The fix is to rebuild the MSVCRT80.DLL, which is a major undertaking and, IMHO, not worth the pain.

It's also a pain because you'd have to put the DLL next to your binary. You never know which app will overwrite that file. So in essence, it'd be like using a static library, but with a bigger startup overhead! D'Oh! | :doh:

Robert Edward Caldecott wrote:
However, I also use Boost, and there doesn't seem to be a config for VS 2005 _and_ STLPort! Sob. Has anyone here made the three work together?

I don't see how boost comes into the picture..? IIRC, STLPort is supposed to be a drop in replacement for the regular STL library that ships with Visual Studio. As for the missing config for VS 2k5, have you tried using the 2k3 config? It might work straight out of the box...

--
Pictures[^] from my Japan trip.

Rob Caldecott14-Dec-05 11:38

Rob Caldecott

14-Dec-05 11:38

Jörgen Sigvardsson wrote:
I don't see how boost comes into the picture..?

Boost has different jam configs when building for VC + STLPort, so I think it must be relevanr somehow...

The Rob Blog
Google Talk: robert.caldecott

Nemanja Trifunovic15-Dec-05 1:47

15-Dec-05 1:47

Jörgen Sigvardsson wrote:
It's also a pain because you'd have to put the DLL next to your binary. You never know which app will overwrite that file.

What do you mean by this?

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Jörgen Sigvardsson15-Dec-05 3:24

15-Dec-05 3:24

If you rebuild the crt dll, and install it in say Windows\System32, it could be overwritten by another program. Overwritten with the "original" crt dll which has the memory leaks.

If you put the dll alongside the binary, the chances of another application overwriting it is virtually zero. Smile | :)

--
Pictures[^] from my Japan trip.

Nemanja Trifunovic15-Dec-05 4:41

15-Dec-05 4:41

Jörgen Sigvardsson wrote:
If you rebuild the crt dll, and install it in say Windows\System32,

Shudder. Never even cross my mind to install anything in System32, but you are right - many people actually do that

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Jörgen Sigvardsson15-Dec-05 4:59

15-Dec-05 4:59

Uh huh. I've stopped doing that as well. It used to be "correct practice" once I believe, but it's just asking for headaches. I do DLLs only these days, but I put them side by side with the executable. It won't be much better than .libs from an optimization point of view (shared code, etc). But it is easier from a maintainence point of view, as I only have to patch affected DLLs, and not the entire app.

Another great benefit with DLLs is that it's very easy to debug code on site, as it's just a matter of replacing the DLLs which contains TRACE messages, and/or similar debugging I/O.

I like DLLs. Does it show? Smile | :)

--
Pictures[^] from my Japan trip.

Nemanja Trifunovic15-Dec-05 7:19

15-Dec-05 7:19

Jörgen Sigvardsson wrote:
I like DLLs

Me too. Although it wouldn't hurt if we got some standard C++ module/component system on top of them. The .NET component system is one of the rare things where .NET is really a better development environment than C++. I know there is COM, but a) it is bloated and b) it is not portable.

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Stuart Dootson14-Dec-05 21:42

Stuart Dootson

14-Dec-05 21:42

I'd ask on the Boost Users mailing list - that's probably more likely to get a useful (or at least definitive) reply...

Nemanja Trifunovic15-Dec-05 1:56

15-Dec-05 1:56

Robert Edward Caldecott wrote:
The fix is to rebuild the MSVCRT80.DLL, which is a major undertaking and, IMHO, not worth the pain.

Apparently, there is another "unofficial" way: Look at the third reply from the bottom of this page:[^]

Steps:

1) Open up istream in \Program Files\Microsoft Visual Studio 8\VC\Include
2) Before line 29, insert the following code

explicit __CLR_OR_THIS_CALL basic_istream(_Mysb *_Strbuf, bool _Isstd, bool _Noinit)
: _Chcount(0)
{ // construct from stream buffer pointer
if (!_Noinit)
_Myios::init(_Strbuf, _Isstd);
}

3) In the same file (istream), look for the following line:

: basic_istream<_Elem, _Traits>(_Strbuf, false),

and change it to:

: basic_istream<_Elem, _Traits>(_Strbuf, false, true),

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.