Thread: Winapi woes

*sigh*. I always seem to butt my head against probs. that make no sense when I use the win32 api. Anyone have some insites on the problem that follows?

When the code below executes, at the Edit_SetText macro call, I get a:

Unhandled exception in fontConstruct.exe (NTDLL.DLL): oxC00000FD: Stack Overflow

Code:

Code:

void SizeChanged() {
	int charsCopied = 0;
	TCHAR * buff;
	TCHAR * buffptr;
	TCHAR * buff2;
	int len;
	int i = 0;
	HWND ctrl;

	ctrl = GetDlgItem(hdlgActive, IDE_FONTSIZE);

	len = Edit_GetTextLength(ctrl);
	if(!len) {
		// feild cleared
		// set flag
		return;
	}
	buff = (TCHAR*) malloc(sizeof(TCHAR)*(len + 1));
	buffptr = buff;
	buff2 = (TCHAR*) malloc(sizeof(TCHAR)*(len + 1));
	if(buff == NULL) {
		// error
	}

	Edit_GetText(ctrl, buff, len+1);

	while(*buffptr != '\0') {
		if(isdigit(*buffptr)) {
			buff2[i++] = *buffptr;
		}
		buffptr++;
	}
	buff2[i] = '\0';
	
	Edit_SetText(ctrl, buff2); // ERROR HERE
	
	free(buff);
	free(buff2);
}

TIA for any help
-John

Thanks for the suggestion but I don't belive that's it According to "Win32 Programming" "Another odd-and undocumented-feature is that the length you give must be one character longer than the maximum line lenght your can retrieve. Although the EM_GETLINE message does not put a terminating NUL byte at the end of the string, it assumes that you problaby will do this. Hence, it will not copy more then the character count minus one character to the buffer. This is for GETLINE, but by single stepping through the code, I found the ALMOST the same situation for GETTEXT but it does put the terminator in. So the +1 is nessesary. As for the alternate code, I suppose could do that, but don't see the need other then a possible marginal increase in speed by gettin rid of the array access. The program is (suppose to be) quick and dirty hacked together prog for to make a header file and bitmap of a selected true type font for a font engine for a dx lib. I'm wriing. So speed doesn't really mater at all, and that's the first way that came to mind
I'm wondering if it's a similar bug I was having in another proj. that had NO rational explenation and I had to make the buffer larger then a certain size to make it work. Or turn the compiler to creating the release version. Was very strange. Like this is too me. Hmmm... maybe I'll try compiling under release rules.

*sigh*. Nope. Still didn't work under release.

Unfortuantly I already tryed a statically allocated array of 255 TCHARS. Same result And actually tried allocating a larger buffer dynamically 2. Again, same results *sigh* Very confusing.

Here, these r the values gotten by watching the memory while single stepping through the code. Data in comments. I changed the implementation to the last one I posted as it really is nicer and I can't be workin on the rest till I get this done anyways... lol

Code:

1 enter'd into edit field.  EN_CHANGE msg calls funtion.

void SizeChanged() {
	int charsCopied = 0;
	TCHAR * buff;
	TCHAR * buffptr;
	TCHAR * buffptr2;
	int len;
	int i = 0;
	HWND ctrl;
	FILE * debug;

	ctrl = GetDlgItem(hdlgActive, IDE_FONTSIZE);

	len = Edit_GetTextLength(ctrl);
         // len == 1

	if(!len) {
		// feild cleared
		// set flag
		return;
	}

	buff = new TCHAR[len+1];
	buffptr = buffptr2 = buff;
	if(buff == NULL) {
		// error
	}

	Edit_GetText(ctrl, buff, len+1);
         // buff == {'1', 0 } "1"

	while(*buffptr) {
		if(isdigit(*buffptr))
                         // 1st run, tests true
			*buffptr2++ = *buffptr;
                         // buff == {'1', 0}
                         // buffptr2 == {0} ""
		buffptr++;
                 // buffptr == {0} ""
	}
         // Second run, exits out of while

	*buffptr2 = '\0';
         //  buffptr2 == buff[1] == {0}

	debug = fopen("debug.txt", "w");
	fprintf(debug, "%s\n", buff);
	fflush(debug);
	fclose(debug);

	buff == {'1', 0} "1" 
	Edit_SetText(ctrl, buff);
         // CRASH!!!!!!!!!!!
	
	delete [] buff;
}

If a invalid char is enter'd, it doens't crash. In anther words, if the string passed to SetText is a empty string it seems to be ok.

WAIT A MINUTE! Lol. If settin the text causes a WM_UPDATE msg, Rn't I gonna be updating for the rest of my life. Lol. Hmmmmmmmm. I wonder if that has to do with it. Gonna have to not update if the text is valid and no changes where made. I'll make that change now and get back.

WOOHOOO! Stupid mistake fixed. Problem solved Man, I hate spending hours working on a stupid short sight... lol, and u never look at the stupid shortsight. Always looking in the wrong spot.
Thanks much
-John