I have been having a problem with the api roundrect for the last few months. It runs fine for a while, but never seems to make it through one or two days. The program I am using it in runs 24/7 and it is called about every 5-15 seconds. Below is what I have been using. I have modified it because I originally wanted to use gradient fill.
SUB RoundRectangle(WINDOW win,INT l,INT t,INT Width,INT Height,INT Rad,UINT border,UINT lfill,UINT fill)
int phdc,r,g,b
string d2h
uint mcolor
d2h=HEX$(fill)
d2h=RIGHT$("00000000" + d2h,8)
r=hex2dec(MID$(d2h,3,2))
g=hex2dec(MID$(d2h,5,2))
b=hex2dec(MID$(d2h,7,2))
mcolor=rgb(r,g,b)
phdc=GetHDC(win)
SETLINESTYLE win,@LSSOLID,2
FRONTPEN win,border
RoundRect (phdc,l,t,l+Width,t+Height,Rad,Rad)
FLOODFILL win,l+(Width/2),t+(Height/2),mcolor
RELEASEHDC win,phdc
ENDSUB
This following code has run for a week and is still working. It is simply a basic rectangle.
SUB RoundRectangle(WINDOW win,INT l,INT t,INT Width,INT Height,INT Rad,UINT border,UINT lfill,UINT fill)
int phdc,r,g,b
string d2h
uint mcolor
d2h=HEX$(fill)
d2h=RIGHT$("00000000" + d2h,8)
r=hex2dec(MID$(d2h,3,2))
g=hex2dec(MID$(d2h,5,2))
b=hex2dec(MID$(d2h,7,2))
mcolor=rgb(r,g,b)
SETLINESTYLE win,@LSSOLID,2
FRONTPEN win,border
RECT win,l,t,Width,Height,rgb(0,0,0),mcolor
ENDSUB
Why does one work, and not the other?? The GetHDC or RoundRect have a memory leak?? Or am I not calling something correctly.
Later,
Clint
it looks that you have conflict between built-in DC functions and API dc functions,
if you think that GetHDC cose problems use direct api function GetDC(hwnd)...look
in api declares...
good luck ;)
Heh...
starange nobody else have something to say ::)
don't be scared i wont bite.. ;D
Clint
I can't tell you specifically what your problem is but this may be helpful.
There is a huge difference in what is going on in your two different blocks of code posted above.
First, understand this:
All the IWBasic graphic commands(FRONTPEN,LINE,CIRCLE,FLOODFILL, etc) get and release the device context associated with the parent window. Some of those commands are real straightforward internally while others modify some of the internal variables of the WINDOW structure.
In all cases the fundamental steps are the same for every command:
1)get the dc
2) create the necessary pens, brushes, etc
3)do the drawing
4)release the necessary pens, brushes, etc
5)release the dc
In your 2nd example the preceding 5 steps occur one time and that is internal to the RECT command.
In the first example you are doing this:
1)get the dc
-FRONTPEN
1)get the dc
create pen and store handle in WINDOW element
5)release the dc
2) create the necessary pens, brushes, etc
3)do the drawing
4)release the necessary pens, brushes, etc
-FLOODFILL
1)get the dc
2) create the necessary pens, brushes, etc
3)do the drawing
4)release the necessary pens, brushes, etc
5)release the dc
5)release the dc
As you can see you are nesting the get and release of the dc in two places which is something that doesn't normally happen in the normal use of IWB commands.
So, like I said, I can't say what is causing your problem exactly but this is how I'd changed your subroutine to get rid of that nesting.
SUB RoundRectangle(WINDOW win,INT l,INT t,INT Width,INT Height,INT Rad,UINT border,UINT lfill,UINT fill)
int phdc,r,g,b
string d2h
uint mcolor
d2h=HEX$(fill)
d2h=RIGHT$("00000000" + d2h,8)
r=hex2dec(MID$(d2h,3,2))
g=hex2dec(MID$(d2h,5,2))
b=hex2dec(MID$(d2h,7,2))
mcolor=rgb(r,g,b)
SETLINESTYLE win,@LSSOLID,2
FRONTPEN win,border
phdc=GetHDC(win)
RoundRect (phdc,l,t,l+Width,t+Height,Rad,Rad)
RELEASEHDC win,phdc
FLOODFILL win,l+(Width/2),t+(Height/2),mcolor
ENDSUB
Let me know if that makes any difference.
P.S. - What are you doing that would make you need to redraw that every 5-15 seconds?
Thanks a lot for your replies. I understand a little better how things work, and how that could cause a problem.
I am listening in on a com port while several devices are being polled (which happens every 5 - 15 sec/device), and as the data comes in, I update the screen accordingly with a background color that corresponds to the information coming in, as well as placing new data in the rectangle.
Later,
Clint
If that's the case I'd put it all in the WM_PAINT portion of the message handler , have the data in global variables that the WM_PAINT uses for drawing and let the com port update the global variables.
Also test when the com port gets data, issue an invalidaterect command(api) to force a redraw.
In your WM_PAINT olny redo the color when it needs to be changed. That means a global variable to store the last color used in.
If you want to redo it then send me your code and I'll help you with it.
Thanks for your offer Larry, but my code is a mess, do to the fact that I've piece it together trying all kind of things. I started out with gradient fill, so I had to set my text to transparent background. That meant that every time data came in the gradient rectangle needed redrawing as well as the text. There can be up to 255 devices that can be polled (usually 30 or less), and I just redraw the rectangle for that device that just came in.
I still wish Larry S. would fix the CommLib to handle ports over 9. I currently am just polling the comm routine I made to see if there is any data in the buffer. :(
If I get stuck, I may take you up on your offer Larry.
Later,
Clint
can you post a screenshot of what all these rectangles look like
I was playing around a little and came up with this.
It involves super-classing buttons.
Since I don't have any com ports doing anything I have a timer firing every 1/10 second to simulate the com ports.
I'm changing the color and the text each timeout for the next rgnbutton.
The 3 regular buttons are just to show what you have to do to keep the superclassing from bothering them.
The source, rgn bitmap, and an exe are in the zip.
Thanks LarryMc. Sorry it took so long to get back to you. I've been busy with other things.
Here is a screen shot of my rounded rectangles. It is for a pond monitoring system.
Later,
Clint
Nice looking app.