Michael Dunn wrote: Jambolo wrote: BSTR( L"< ParticleSystem />" ); That is still not correct, you need to make a real BSTR or use a wrapper class like _bstr_t Well, it worked just fine, so I'm not convinced. Regardless, I am using CComBSTR for the real code, but I will keep that in mind for next time.

Thanks for your help. I finally found that my problem was a combination of two different problems. 1. Here was the real problem: I was loading (as binary) a Unicode file that has a BOM (byte-order mark) at the front of the file. Then I passed the text to loadXML. Apparently, loadXML can't handle Unicode special characters. I consider this a bug in loadXML. 2. In order to test loadXML, I was creating a BSTR like this: BSTR( "< ParticleSystem />" ); Like you said, the constructor was not converting the string to a Unicode string as I expected it to do. loadXML was able to parse this: BSTR( L"< ParticleSystem />" );

What could be wrong here??? I get the error "Invalid at the top level of the document"; however, loading the exact same text from a file using load() works! CoInitialize(); CComPtr< IXMLDOMDocument2 > pDocument; pDocument.CoCreateInstance( CLSID_DOMDocument40, NULL, CLSCTX_INPROC_SERVER ); VARIANT_BOOL status; pDocument->loadXML( BSTR( "< ParticleSystem />" ), &status );

Both are multithreaded. However, I found that linking with the MFC DLL causes linker errors, and linking statically does not. My guess is that for some weird reason (a bug?), the MFC DLLs export some STL symbols.

I have a non-MFC project using std::string that is compiled into a library (Confetti.lib). My main project is an MFC project that uses this library. I get the following linker errors: msvcprtd.lib(MSVCP70D.dll) : error LNK2005: "public: __thiscall std::basic_string::~basic_string(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in Confetti.lib(ParticleSystem.obj) msvcprtd.lib(MSVCP70D.dll) : error LNK2005: "public: __thiscall std::basic_string::basic_string(char const *)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z) already defined in Confetti.lib(ParticleSystem.obj) Can anyone tell me why this is happening and how to fix it? Also, if I ignore msvcprtd.lib, then I get lots of dll import/export errors for std::basic_string.

I wrote a function that gets a attribute value that is in hex. Am I reinventing the wheel? The problem is that I can't get it to work. Here was my first attempt which failed because it didn't convert to hex (even though the the type is xsd:hexBinary):

HRESULT		hr;
CComVariant	value;

hr = pElement->getAttribute( CComBSTR( sName ), &value );
hr = value.ChangeType( VT\_UINT );

Here is my second attempt which works for values using digits '0'-'9' but fails for values using digits 'a'-'f' (and 'A'-'F') (VarParseNumFromStr returns DISP_E_TYPEMISMATCH):

HRESULT		hr;
CComVariant	value;
NUMPARSE		np	= { 10, NUMPRS\_HEX\_OCT|NUMPRS\_USE\_ALL, 0, 0, 4 };
unsigned char	digits\[10\];
CComVariant	vHex;

hr = pElement->getAttribute( CComBSTR( sName ), &value );

hr = VarParseNumFromStr( value.bstrVal, GetUserDefaultLCID(),
			 NUMPRS\_HEX\_OCT|NUMPRS\_USE\_ALL,
			 &np, digits );
np.nBaseShift = 4;
hr = VarNumFromParseNum( &np, digits, VTBIT\_UI4, &vHex );
hr = vHex.ChangeType( VT\_UINT );

Anyone know what is wrong or what the right way to do this is?

I found a sample app in the MS Platform SDK called IconPro. It works perfectly and it even allows you to make 32-bit icons.

I have a 256-color 96x96 BMP and I want to use it for an icon. The problem is that when I paste the image into the 96x96x256 icon in the VS.NET resource editor, the palette entries are shifted (apparently). How do I do this? Also, how do I create the nice 24-bit icons for XP?

Really what you are asking is, "Why can't you just change the memory location of an object?" The answer is that other objects may be referencing it. If you use memcpy, it is not possible for the affected pointers to be fixed, like they could if you used copy constructors and/or assignment operators. A linked-linked is a good example. If you swap nodes using memcpy, the list would become corrupted. Doing it the slow and safe way gives the objects the chance to reinsert themselves into the list correctly.

GetAsyncKeyState() is a Windows function that will tell you the state of a particular key.

You need to change the code page or the LOCALE or something like that.

d=(double)f; d=static_cast(f); Interesting. This always works for me: d = f; ;)

emrosa wrote: cos(90. degrees)=-3.4914833611094e-15 cos(90. degrees)=-6.1230317691119e-017 You should never expect to get exactly 0. Floating-point numbers and operations are not exact. It seems to me that -0.0000000000000034914833611094 and -0.000000000000000061230317691119 are pretty close to 0.

Here are some examples of when this is used: 1. Sometimes you will see it as a function parameter. For example, registering a callback: Server::RegisterCallback( this ); 2. It is used for a lot of overloaded operators: Vector const & operator +( Vector const & b ) { ... return *this; } 3. When overloading operator= you must make sure that the source is not the same as the destination: Vector const & operator =( Vector const & b ) { if ( this != &b ) { ... } return *this; } You will probably never see "this->" because there is never a need for it -- it is automatic.

Vimal Earnest wrote: extern "C" { #include "yourheader.h" } This is generally not a good idea. yourheader.h may include other header files that contain C++ code (windows system files, for example). A better way to do it is to put

#if defined( __cplusplus )
extern "C" {
#endif // defined( __cplusplus )

inside yourheader.h before declarations (but after includes) and

#if defined( __cplusplus )
}
#endif // defined( __cplusplus )

inside yourheader.h at the end.

You can do is something like this:

class CMyClass
{
static char const __CLASS__[];
...
void DisplayMyName();
}

...
char const CMyClass::__CLASS__[] = "CMyClass";

However in this case, __CLASS__ is not a macro and the value is not available at compile time. You can't do compile-time string concatenation.

Read up on how to use static member variables. Initialize it outside of the declaration like this:

class RCanalTree : public CTreeCtrl
{
...
static int m_icons[];
...
};

...

int RCanalTree::m_icons[]={
IDI_ICON_SYSTEM,
IDI_ICON_CANAL,
IDI_ICON_SITE,
IDI_ICON_WELL,
IDI_ICON_TURNOUT,
IDI_ICON_PUMP,
0 // NULL place holder used to terminate the array.
};

Take it from a veteran... Avoid casting whenever possible, even when you know what you are doing. Casting has always been and will always be a potent source of bugs.

If you are using .NET, files in the folder ...\Microsoft Visual Studio .NET/Vc7/vcprojectitems show up in the "New Item" template list. I'm not sure if this is the "right" way to do it, but it works. If anyone knows the "right" way, let me know.

BTW, the type (except for signed/unsigned) is ignored for fields. The following are all exactly the same:

struct s_Person { char Letter1 : 10, Letter2 : 10, Letter3 : 12; };
struct s_Person { short Letter1 : 10, Letter2 : 10, Letter3 : 12; };
struct s_Person { int Letter1 : 10, Letter2 : 10, Letter3 : 12; };
struct s_Person { signed Letter1 : 10, Letter2 : 10, Letter3 : 12; };