AFAICS, on WinHttpQueryDataAvailable failure dwSize is undefined; it may be 0; it may be junk. You haven't indicated if that call failed or not. In that case, it is not clear what awful behavior happens if you then call WinHttpReadData. Why waste time chasing phantom cases? Just remove the bogus pathway. Unless you are using the debugger to examine dwSize, I don't see it being output anywhere. I have to wonder what the difference is between dwSize and dwDownloaded. What is supposed to happen when they are different? The symptom you report is that an often used operation of a common type generates an exception. The object is a class member that is neither initialized or reset in the function that generates the exception. You might want to examine how this object is used before the call to the function. Is it being locked? Is there a call to GetBuffer/ReleaseBuffer? etc. You should be able to trace into the CString class and determine the exact cause of the exeption.

Normally I would say "Stop trying to write code until you understand what you are trying to accomplish." However, here that is the only way you can demonstrate effort. When you know what you are tying to do it will be easier to see how the various classes/objects function. Maybe I'd like to start a new game. Maybe I'd like to quit the program. Maybe I'd like to save the game I'm in. Maybe... Who displays these to the user? When? Who gets the user selection? When? So, controller says,

While not quit
	Display menu
	Get menu selection

Where are all these menu things located?

You haven't provided enough evidence that the diagnosis of the problem is correct. You might try to: - replace the TRY-CATCH_ALL macros - use a try-catch on the "Read the Data" block rather than the whole function - properly handle the case of WinHttpQueryDataAvailable failure. - verify that m_strResponse is valid before you attempt to concatinate to it. It may have "worked" before; I would add "by the grace of God." The code is flawed.

You are given a clue about the controller class in main: "Start the game" If you are the game controller and I tell you "Start the game" what do you need to do?

What do you mean by "switch targets"? As for the nmake aruments, -n and -m are the ones I think you want and pipe the output to a file. Another is -B to force a full build; a test I do is build with -B then without and if the second does anything I look further. Occassionaly we get problems with the system clock on different system and around when daylight savings time changes.

A Senior Software Developer should be able to evaluate C++ and C#.

Look here You won't find the splitter window in the dialog resource because it is a window! The splitter window must be attached to a frame window, so you have to manufacture one of these in the dialog class. Each of the splitter window panes requires a view class so you have to generate these as well. See CreateViews() in the sample application.

Does this compile?

class MyClass
{
static MyClass m_instance;
}

MyClass* MyClass::m_instance = 0; // different types here

and this

MyClass->Start(); // MyClass as a pointer????

I'm also doubtful about the use of shared data segment memory as an interprocess mechanism.

Why not bitfields?

struct filter
{
unsigned Bus : 3; // range : 0 - 7
unsigned Route : 5; // range : 0 - 31
unsigned Xmit : 1; // range : 0 - 1 // constraint: exclusive with Rcv
unsigned Rcv : 1; // range : 0 - 1 // constraint: exclusive with Xmit
unsigned Msg : 5; // range : 0 - 31
unsigned dummy : 1; // padding to 16 bits
};

This pattern presents a maintenance problem to me. What happens when you add more CItem types? How useful is CNode if the code needs to detect the type of the contents? The solution to me is to specialize the CNode class for the different CItems it holds,

// generic class
class CNode
{
public:
virtual bool process() = 0
{
// common default function
}
};

class CEmbossNode : public CNode
{
public:
virtual bool process()
{
// access CItem or CEmboss data/functions
return CNode::process(); // or call default
}
protected:
int GetOrientation() const { return mnOrient; }
private:
int mnOrient;
CEmboss * mpItem;
}

class CAnnealNode : public CNode
{
public:
virtual bool process()
{
// access CItem or CAnneal data/functions
// or call default
}
private:
CAnneal * mpItem;
};

class CList
{
// ...
CNode * mpListHead;
}

The types are hidden behind a polynorphic interface. Adding new types requires the definition of the polymorphic interface. Each CItem knows what it is and can use special knowledge or do just the default action. IMHO, these outwiegh the cost of the virtual function. // edit: remove multiple EmbossNode declarations

modified on Monday, March 24, 2008 1:43 PM

This isn't a bug. This is physical coupling. The library modules are mixing the different classes together. In this case, the module that contains the static class function C::Func1() also contains the definition of B::Func2(). That function will drag in all of classes A and B. If you want the library to generate a small footprint, you need to minimize the physical coupling. Separate the classes into distinct modules. In this case you can simply create a separate file to hold C::Func1(). Have the linker generate the map file and check the symbols and modules being included. You can get incremental improvements here so you don't have to do everything at once.

Good catch! Yes, I missed a few things here. Sorry.

Why? I don't understand.

further...I would anticipate that you might need to interface to the legacy C code from the C++ code. In the C++ code mark the legacy C headers as C code:

// legacycode.h

extern int stableAPI(int icount);

// NewCppAPI.cpp

extern "C" {
#include "legacycode.h"
}

void CppFunction()
{
// do new things
std::vector <int> vNumbers;
vNumbers.push(1);
vNumbers.push(2);
vNumbers.push(3);

// call the stable code
int iResult = stableAPI(vNumbers.size());

}

When you have to pass information to the legacy code, it can only pass C types; don't pass pointers to C++ types. Be sure you know who owns what memory. A simple solution is to write copy API's in the C++ code that are called by the legacy C code in the same way that windows API's do. You pass in a pointer to a buffer with a pointer to a length that is the size of the buffer. If the buffer is too small the function returns an error and set the length to the size needed:

int CopyCppData(char * pszBuffer, int * ilength);

This doesn't add up. You don't need to rewrite the whole application in C++. You should be able to interface the legacy C code with any C++ changes. Write a C interface to the C++ code:

// legacy C code

#include "NewCppAPI.h"

void legacy_Code()
{
// doing things with stable code
// call the new code
int iResult = NewCppAPI();
// check return code
}

// NewCppAPI.h

#ifdef __cplusplus
extern "C" {
#endif

int NewCppAPI();

#ifdef __cplusplus
}
#endif

// NewCppAPI.cpp

#include "NewCppAPI.h"

int NewCppAPI()
{
int iResult = 0;

// do the new stuff

return iResult;

}

I have to guess that there must be some other constraints you are not mentioning.

Also, the assignment operator fails to insure there will be no buffer overwrite. Simple assignments such as,

A Astring;
Astring = "too long";

will cause errors. Changing the size of the buffer won't be enough. The arguments to the assignment operator should be constant; unless you intend to allow it to change its argument?!?

A& operator = (LPCSTR Astr)
{
// reset the buffer
::memset(str, 0, sizeof(str));

if (!Astr)
	return \*this;

int len = ::strlen(Astr);
if (len <= sizeof(str)) {		// too short or just right
	::strcpy(str, Astr);
} else if (sizeof(str) < len) {	// too long
	// Q: how to handle the terminal nul???
	::strncpy(str, Astr, sizeof(str) - 1 );	// truncate
	str\[1\] = '\\0';							// terminate
}	
	
return \*this;

}

Should probably check for the degenerate case of an empty string as well.

Hard of hearing; practically deaf in some cases!

Try posting the SW_RESTORE command to the application.

Comment #1: Try to remove "magic numbers" in the code. Comment #2: check_name is intialized with how many values? What happens in the following code if, by some chance, check_name[n] is a character string longer than 11?

char check_name[12][5];
char pns_name[12];

//...
sprintf(pns_name, "%s.PNS", check_name[n]);

Comment #3: Walk through code in the debugger. Use small numbers.

This doesn't sound like a Tooltip. This is more like a popup menu or window. It also sounds like you would get into a rather annoying state where the user would be trying to "chase" the hyperlink in the tooltip window before the tooltip window disappeared. If you code a tooltip around that to keep the tooltip window visible until you get off it then you have the problem of access to the screen region under the tooltip. I would suggest two CP classes: the CXHyperLink class by Hans Dietrich and the CTitleMenu class by Arthur Westerman.