Correction: I have verified and this happens on both 1.0 and 1.1. Looks like an issue that no one has noticed before? ;)

You probably have to write a separate program and use pre- or post- build events to call that program. That means the program should be command line (Console).

Found a weird bug in an app that we are writing, and I narrowed down to this special case: double a = double.NaN; Console.WriteLine("a = {0}", a); Console.WriteLine("(int)a = {0}", (int)a); Console.WriteLine("Math.Round(a) = {0}", Math.Round(a)); Console.WriteLine("(int)Math.Round(a) = {0}", (int)Math.Round(a)); We just moved to 1.1 so this appears to be a 1.1 issue. For debug build, the output is: a = NaN (int)a = 0 Math.Round(a) = NaN (int)Math.Round(a) = 0 For release build, the output is: a = NaN (int)a = 0 Math.Round(a) = NaN (int)Math.Round(a) = -2147483648 It seemed for some reason Release does not behave the same and that was causing my problem. Granted I shouldn't depend on the cast to be 0 because it is NaN (should never depend on undefined behaviour ;P), but at least give me a consistent answer or throw an exception if NaN is used in Math.Round()? Again when my runtime was 1.0 it seemed fine, so could this be just a weird bug? :confused:

This looks suspicious as well:

while(*(pTabBinPort+k)==1)
{
*(pTabBinPort+k)=0;
Table.ConvertBinToNum(k,pTabBinPort,pTabNumPort);
k--;
}

Could there be any chance that k is <0 and you step out of bounds? Putting an assert on k after decrement or (better yet?) VERIFY(--k >= 0) should help detect this problem in debug mode.

That's why I always believe that if a programmer cannot write a decent for loop him/herself s/he shouldn't be programming at all... ;)

That's why we use typedef's a lot (to save some keystrokes I guess?). For example:

typedef std::list<MyItem> CMyList;

Is this also an evil then?

Is bool less efficient? I don't think so... I usually use bool for pure C++ logic, and BOOL for UI/Win API related stuff. I have seen a lot of people mixing them and IMHO is not a good idea in terms of readability.

You should:

• use the TEXT() or _T() macros for all your string literals
• use TCHAR instead of char
• include tchar.h
• and if you have UNICODE and _UNICODE defined (ie you are using unicode version of wsprintf), make sure you check the "Display unicode strings" options under the Debug tab of the VC++'s Options dialog.

PS. Are you sure you have a valid buffer in Description? PPS. Just saw you assigning Description from the results of wsprintf. Did you read the docs at all? LPTSTR is not a string class :mad:! You are making the Description pointer to point to some invalid address after the function call.

Nice morning exercise to start the day! ;) Let me outline my steps:

1. Take out the C runtime library (idea from ATL):
   The compiler by default will link in CRT startup code before actually calling your entry point function.  So the first step (and the biggest) step is to remove those CRT stuff since you are just using Win32 API.  Borrowing idea from ATL's WinMainCRTStartup I put something like this:
   void WinMainCRTStartup(void) {     WinMain(GetModuleHandle(NULL), NULL, NULL, 0);     return; }
   This takes 20K :omg: out of the exe and it is down to 16K.
2. I tried a few things and I think the compiler just won't reduce the size further.  It always give you 3 segments and stuff.  So I thought of UPX, the exe compression tool (I know I cheated a bit here, but I don't know assembly! :-D).  I used it to compress my exe and boom... it is down to 2560 bytes!
3. Without resorting to assembly (I don't know the PE format too much :p ), I opened up the original exe in binary mode and I noticed a lot of blanks (to fill up the segments I suppose).  So I thought, "if I could make the segments more blank then I may be able to get more compression out of this".  I notice that I am calling 2 functions from Win32 API, killing 1 of them should make the import table more compressible.  Since I am not interested in the module handle, I make that NULL:
       WinMain(NULL, NULL, NULL, 0);
   Unfortunately that didn't work, UPX still compressed it to 2560 bytes.
4. My final step is to realize that I am doing a 2-step function call to get to the MessageBox.  So I killed my WinMain and make my entry point function call MessageBox directly:
   void WinMainCRTStartup(void) {     MessageBox(NULL, "Hello World","Hello", MB_OK); }
   Now, that didn't do much in terms of the compiler, it still gave me 16K, but UPX made it down to 2048 bytes!  I guess my code segment is more compressible now.

To sum up, here is a little table for you:

                       Before UPX  After UPX

Plain old WinMain() 36384 12288
Minus CRT 16384 2560
Minus GetModuleHandle() 16384 2560
Direct call 16384 2048

So there you have it, my morning exercise. I

Nish [BusterBoy] wrote: I was just advised to use BSTR* as my out parameters I meant to say that actually, must be smoking crack... Sorry for the confusion ;-P

I might want to add: - use BSTR for your [in] param - use BSTR* for your [out] param Edit: fixed the little bug in my 2nd statement ;-P

BSTR is already a pointer. So BSTR** is a "triple pointer" (omg! :confused: ), which of course is not supported by automation. From MSDN: typedef OLECHAR FAR* BSTR;

I would have to say that this is one of the cases that you may want to use the DDX_ functions. One of the overrides does exactly just that. But there are limitations to those functions so if you are hitting on those limitations, you may still have to roll your own code.

Not sure about WinXP, but I imagine it to be the same as Win2k. Take a look at KB article Q236621. I have done it before, took me the whole evening to do it. It was a pain so from that time on I made sure I picked a large enough partition to install NT/2K... Hope this helps.

Can you POST (not send) yourself a (WM_USER + n) message to your dialog towards the end of OnInitDialog()? However, based on what you are saying here, if your dialog does not need any user input, why create and show the dialog in the first place?

If possible, you may also use raw_interfaces_only and raw_native_types with your #import directive, then subsitute _com_ptr_t, _bstr_t, _variant_t with CComPtr/CComQIPtr, CComBSTR and CComVariant.

If you are talking about the MDI "document windows", you need to send WM_MDI* messages to the "MDI client", the window that is usually in the dark gray colour.

You can try the good old djgpp or the mingw versions of it. Do a web search on those 2 and you should find tons of references.

In the event that the CLSID of the CoClass object is not known, you can: - use the COM category manager (ICatInformation) and enumerate the objects' CLSIDs at runtime - do category management under your own registry key(s), basically you store the list of COM object CLSIDs and you call CoCreateInstance() on those CLSID and get your interface using QueryInterface() after that

For your XML parsing problem, have you checked out the IXMLDOMNode::selectNodes() method?