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

try

Edit_GetText(ctrl, buff, len);

not

Edit_GetText(ctrl, buff, len+1);

as you found it had len characters and only alloc ed the buffer len (+1 for the terminator)

also why not

Code:

TCHAR *buffptr2=NULL;

buffptr2=buff2;
while(*buffptr != '\0') 
{
      if(isdigit(*buffptr)) 
	   *buffptr2++ = *buffptr++;
       else
            *buffptr++;//is not a digit
}

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.

I also consider'd doing something liek....

Code:

buffptr 
buffptr2
buffptr = buffptr2 = buff;


while(*buffptr) {
     if(isdigit(*buffptr))
          *buffptr2++ = *buffptr;
     buffptr++;
}
*buffptr2 = '\0';

But I didn't feel like thinking it through to make sure I didn't have any logic problems when I had a working solution. Lol. Ya, I can have lazy prog. syndrome as indicated by the // where I need to put in error checking. lol.

What is i and what is len at

buff2[i] = '\0'; //is i==len here?


try taking all the dynamic allocation out or increasing the size alloced.

or

Set the text limit in the edit and declare a large char buffer to get the data. EM_LIMITTEXT

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.

Oddly, in another area of the code I do.....

Code:

sprintf(tmp, "%d", font.lfHeight);
		Edit_SetText(GetDlgItem(hdlgActive, IDE_FONTSIZE), tmp);

and that works fine. It was just put in while I developed other parts, but it worked without a problem.

ps. Opps, I see I should have been responding to EN_UPDATE. I changed that though and still same responce.

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