I knew that I'd seen something about this before on this board.

Anyways, I loathe gdi coding, but I've got a static control that I want to be red so it'll stand out a bit more. Occasionally in the past I've used this same technique to change the colors of static controls, but this is the first time that I've ever needed to periodically update the text in that static control. The code is already posted several times in this thread so I won't bother posting it again.

What's happening is that when a button is pressed the text of the static control gets updated but it's overlapping the previous text. It's almost 4am and I'm going cross-eyed. Bottom line is I've tried a bunch of different things that when I stop to think about it, didn't make much sense at all. Hindsight's wonderful eh.

If I comment out the wm_ctlcolorstatic code the problem disappears. And when the wm_ctlcolorstatic code is there, and the text gets changed, all I have to do is minimize/restore the program (presumably firing a wm_paint msg?) and it's fine. The problem is a combination of me knowing dick about gdi coding and just plain exhaustion. I'm guessing that I've got to handle the wm_paint message somehow?

So if some kind soul can decipher my ramblings and solve the problem I'd appreciate it. Otherwise I'll just remove the wm_ctlcolorstatic code cause it's not worth the headache.
Posted on 2002-02-24 04:56:12 by Will
I don't know if it is known by most coder or even if i am doing the things wrong.... When you use WM_CTLCOLORSTATIC or EDIT and you are contintenly using your program or even not....
I thought i had it made until i start check MEMORY being used with the System in the control Panel under Performance....

I have a habit of check and forgot...But when i went back to doing it it will take your avarge 86% down to 46% with-in a hour of using active windows changeing.......It EAT up LIKE HELL WINDOWS MEMORY.... ...Posted on 2002-02-24 06:04:16 by cmax
cmax: You probably forgot to destroy GDI resources like brushes, pens etc.

Thomas
Posted on 2002-02-24 06:20:24 by Thomas
cmax:
I have seen that with other apps. With the wm_ctlcolorstatic (for 1 control) Window Task Manager's Mem Usage (using win2k) column shows that my program uses 837k of memory. Without that code it shows 816k. I've been monitoring both versions of my program simultaneously for the last 20 minutes and the numbers may go up or down a little bit if I minimize/restore/move them but for the most part they stay fairly close to the level that they started off with.

Thomas:
The only brush that I was using was a stock one, returned by GetStockObject. But according to microsoft:
"It is not necessary (but it is not harmful) to delete stock objects by calling DeleteObject."


Again, I don't know much about gdi coding but I seriously doubt that having one single static control's color changed would bring down your system memory from 86% to 46%.....at least using the same code that I was using.

Aah well, I removed the code anyways, but if someone does know how to fix the problem I was having I'd still be interested in a solution.
Posted on 2002-02-24 12:35:30 by Will
I figured that it a Microsoft i don't care thing.....(now go get NET)
I still using a 200Mz NEC from 1997 and since i started trying to be an programmer i monitier program mem use because i don't want my program to be a hog on someone who still in love with his 386...I hope some one can find an answer because i never saw a real one yet....But code is everywhere for it...But no body seem to know how to fix it..

No Reflection on you Thomas, Not at All

i was just curious for over 2 years...

Thanks

4oh4, most of any asm program open up and use 1k - 4k. even if it's extra large COM project. Remember back in the day. Also i did a lot of minizing and jumping from windows to windows and every time the my a program move it seems that it get redraw, so mem ususage go's up some how. My codes programing is always tight with out it im back to normal...My maching never fall below 82% in life so i just stop using it...There got to be another way if the fix is not out there... This is ASM. Nothing is Imposible the way i'm dreaming with it . I can't figure much out on my own anyway without a jump start. I Tried Hard... But heckI got time, i can wait...(i hope)

Se ya
Posted on 2002-02-24 16:48:39 by cmax
I can't leave like that, I forgot to say maybe I'm still doing it all wrong and could have not looked yet into what Mr. Thomas suggestion was.

Don't let my experence stop you... Just a note for everyone. Keep an eye on your MeM used. There are more 386, 486, that people going to stick with for many moons to come. This is ASM..
Posted on 2002-02-24 17:43:37 by cmax
Hey Guys
I think i found out why my wm_ctlcolorstatic was eating up all of my memory. It was in my ret.

I don't know why because i had it there but what i did was to give it its own jump ReturnColor. I seen someone something like it in a post.

jum ReturnColor

ret
ReturnColor:

And it seem that its may be as it should. I got a lot of WM_ stuff in it packed with code so it could have gotten tisted up somehow.

It's just like a situation that i had of over flowing buffers but everthing was layed out perfectly. 99.9% sure all DD first than DB..To The Number.... but what i had to do was (by trial and error) was to put a big 16KB emty buffer betweens the many, many of buffer and now it's just like brand new again and it seem that the code is even launching faster.... But it cost me 16k to do it. Stranges but true... Well anyway, Masm is not perfect but that's where detirmintion luck comes in...I'll use that buffer for a help file or a picture or something if possible latter if i can't ever get rid of it... Its Working Like Mad...
Posted on 2002-03-21 19:53:41 by cmax