Is this just an XP bug?

When I run this section of code in my program, Windows XP comes up and says "program.exe has encountered a problem and needs to close. We are sorry for the inconvenience". Now, I dont know if this is just XP or if I'm doing something wrong. Here's the code:

Code:

void ProcessCommand(HWND hDlg) 
{ 
    TCHAR temp[MAX_PATH];

	if(strcmp(command, "about") == 0)
	{
		GetDlgItemText(hDlg, IDC_OUTPUT, temp, MAX_PATH);
		strcat(temp, "sample text\n");
		
		SetDlgItemText(hDlg, IDC_OUTPUT, temp);
	}
}

NOTE: ProcessCommand() is called everything the program recieves an IDOK message (this is inoked in my program every time the user presses [ENTER]) so TCHAR temp; is delared then destroyed a few times, but i dont know if it has anyting to do with this.

Thanks
-Chris

Oh, and the reason I take what was previously inside the edit box and then output it again is becuase I want to keep the original text in the when new text is placed there...

I see two problems with your code:
First, you're declaring an array of MAX_PATH TCHARs (i.e., if MAX_PATH was 20, then you're declaring an array of 20 TCHARs) and then getting up to MAX_PATH TCHARs from IDC_OUTPUT. This could fill up the entire array if enough TCHARs are present. After your call to GetDlgItemText() you call strcat(), which does not have bounds checking. You could be overstepping the bounds of your TCHAR array.

Second, I don't believe strcat() will work with a TCHAR string. The reason: as far as I know, all the strxxx() (e.g. strcpy, strcat, strcmp, etc.) functions assume that the string you're passing to them is made up of one byte characters. With TCHARs (Unicode characters), this is not the case. I'm not sure of the Unicode equivalent of strcat(), you'll have to find it yourself. Try www.google.com.

Or use a char variable. I would advise checking the length of the string before joining them. Although the it is unlikely that they will exceed 256 (what _MAX_PATH is defined as in stdlib.h)

Unicode version in Windows is

lstrcatW()

I think, look up lstrcat()
(most of the C functions were upgraded with an 'l' prefix for Win98)

Ok, I changed it to this, but now the program just automaticly crashes...

Code:

void ProcessCommand(HWND hDlg) 
{ 
    char temp[240];

	if(strcmp(command, "about") == 0)
	{
		GetDlgItemText(hDlg, IDC_OUTPUT, temp, 240);
		strcat(temp, "Example");
		
		SetDlgItemText(hDlg, IDC_OUTPUT, temp);
	}
}

A little help please...

Code:

#define      ADD_THIS        "Example"
#define      STR_LEN         256
void ProcessCommand(HWND hDlg) 
{ 
    char temp[STR_LEN];

    if(strcmp(command, "about") == 0)
    {
        GetDlgItemText(hDlg, IDC_OUTPUT, temp, STR_LEN);
        if((lstrlen(temp)+lstrlen(ADD_THIS)) < STR_LEN)
        {
             strcat(temp,ADD_THIS);
             SetDlgItemText(hDlg, IDC_OUTPUT, temp);
        }//else error
    }
}

or

Code:

#define      STR_LEN         256
void ProcessCommand(HWND hDlg) 
{ 
    char temp[128],sFinal[256],sAddThis[64]="Add this to the end";//the two smaller strings can't exceed the long one

    if(strcmp(command, "about") == 0)
    {
        if(GetDlgItemText(hDlg, IDC_OUTPUT, temp, 128))//return is number copied into string
        {
              sprintf(sFinal,"%s %s",temp,sAddThis);
              SetDlgItemText(hDlg, IDC_OUTPUT, sFinal);
        }//else error
    }
}

Just avoid using strcat() altogether:

Code:

void ProcessCommand(HWND hDlg) {
   char *buffer = new char[256];
   memset(buffer, 0, 256);

   if (strcmp(command, "about") == 0) {
      GetDlgItemText(hDlg, IDC_OUTPUT, buffer, 256);
      strcpy(buffer + strlen(buffer), "Example");
      SetDlgItemText(hDlg, IDC_OUTPUT, buffer);
   }
   delete [] buffer;
}

If you expect the text returning from GetDlgItemText() to be just at 256 chars, increase the size of buffer to create room for "Example," but don't tell GetDlgItemText() about it:

Code:

   char *buffer = new char[264];
   memset(buffer, 0, 264);

   ...
   GetDlgItemText(hDlg, IDC_OUTPUT, buffer, 256);

Either way, the snippet works by simply copying "Example" into the string just after the last letter via some handy pointer arithmetic.

thanks, johnnie2, that worked perfectly