Announcement

**Lance Edmonds** · 1 Jun 2001, 05:00 AM

It sounds very much like a GDI resource leak is hitting your app. Under Win9x, GDI resources are limited to 64K for all running apps. NT/2000 have a substantially greater (almost limitless?) GDI pool.

The most common cause of GDI leaks is caused by forgetting to reselect the original font/pen/brush/bitmap into a DC _before_ deleting the GDI object you created. If you create GDI objects that are going to be used for the life of a dialog or window (ie, created in %WM_INITDIALOG or %WM_CREATE), be sure to destroy these objects in %WM_DESTROY.

Another common error is creating a new font in response to every %WM_CTLCOLORxxx message. You only need to create each font one, and simply return the font handle in response to these messages.

You can test for GDI leaks in Win2K using TaskManager. Select the Process tab, and watch the "GDI Objects" column (you may have to add this to the window via the View menu. Now run your app and watch if the GDI Object count starts climbing.

For more advanced memory-leak testing, consider using an application such as MemCheck. Search the BBS for "memcheck" and you should find some discussions on using it, and where to download a trial version.

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Chris Boss** · 1 Jun 2001, 06:29 AM

Branko;

I follow the rule of thumb "design for the lowest OS" your customers
may use.

Each version of Windows (95,98,2000,NT,ME) has significant differences
in the API. There are also different versions of the common controls
as well to cause problems.

If you design for Windows 2000 and then expect the app to run on
Win 95, you are in for big trouble.

I design my software using Windows 95 and then have it tested on
Windows 98, 2000, NT and ME. I check the API docs to see what
API functions have changed between OS's and I always use the syntax
for Windows 95. This sometimes means I can't use some advanced features
found in the later OS.

To give an example, I use the PathToRegion API function in my Drag
Handle control to convert a Path created using GDI functions (lines, etc.)
to a Region. In Windows NT/2000 most of the GDI functions can be
used to create the path that will be converted to a region. You can
use 21 different GDI drawing functions to create the path.

Now in Windows 95, only 12 of those 21 GDI functions can be used to
create the path for building a region. If I used any of the other
11 GDI functions in a Windows 95 app to create the path for my region
the code would fail and the results would be disastrous.

My point is, that IMO, it is not practical to write apps on Windows
98, NT, 2000 or ME and then expect them to run flawlessly on
Windows 95. There are enough differences between each version of
Windows to cause havoc for your apps on the earlier OS.

Get yourself an older PC with Windows 95 on it and then attempt to
find the API functions that are not backwards compatible with 95 and
the controls/window messages not supported by 95 and test your app
fully on 95. Make sure you don't use any API structures based on
later versions of Windows for API calls. Later versions have changed
the structures and made them larger. If an earlier OS API function gets
the larger version of the structure passed to it, the first member
which is usually the size of the structure will be wrong and you
may possibly crash your app.

------------------

[This message has been edited by Chris Boss (edited June 01, 2001).]

**Tom Hanlin** · 1 Jun 2001, 08:02 AM

The Win95/98/ME operating systems have somewhat defective memory management.
If your code is doing a lot of REDIMs, it is possible to run out of memory
even if there is plenty of memory left, due to memory block fragmentation.
This is not an issue with the NT/Win2k operating systems.

The only way to resolve the fragmentation issue with the Win95-based OSes is
to exit your program and restart it, or apply techniques that avoid REDIMs.

------------------
Tom Hanlin
PowerBASIC Staff

**Branko Bedenik** · 1 Jun 2001, 08:49 AM

Lance said:
You can test for GDI leaks in Win2K using TaskManager.

Indeed! I've checked GDI objects and in one of my loops they were
actually increasing as I was refreshing Textbox with loop index.
I fixed it now, but have to wait
until Monday to see if it helps (as I have no W98 computer).

Thanks
Branko S. Bedenik

------------------

**Branko Bedenik** · 4 Jun 2001, 10:02 AM

Lance,
I think I found the problem. I have a toolbar with IMGBUTTONX icons,
so an user clicks on it and it changes the meaning AND the Bitmap of
the button from Mx to My,then Mxy, then Mx and so on (see Code below).
I checked GDI objects counter with TaskManager
and it IS INCREASING with every click on that button. WHY? What am I
doing wrong?

Thanks
Branko

DIALOG NEW hWndMain, "Toolbar",SirinaOkna-SI+1,0,SI, VisinaOkna-11,%WS_CHILD,0 TO hToolBarRezultati1
.
.
CONTROL ADD IMGBUTTONX, hToolBarRezultati1, %XSMER , "MX" , 0, 3.25*SI, SI, SI
.
.
DIALOG SHOW MODELESS hToolBarRezultati1 CALL WndProc

FUNCTION WndProc (BYVAL hWnd AS LONG, BYVAL wMsg AS LONG, _
BYVAL wParam AS LONG, BYVAL lParam AS LONG) EXPORT AS LONG

SELECT CASE wMsg
CASE %WM_COMMAND

SELECT CASE LOWRD(wParam)

CASE %XSMER
Moment=Moment+1
IF Moment>3 THEN Moment=1
IF Moment=1 THEN CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MX"
IF Moment=2 THEN CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MY"
IF Moment=3 THEN CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MXY"
CALL DolociMaksimalneVrednosti
FUNCTION = 0: EXIT FUNCTION

END SELECT
END SELECT
FUNCTION = DefWindowProc(hWnd, wMsg, wParam, lParam)

END FUNCTION

------------------

**Tom Hanlin** · 4 Jun 2001, 11:05 AM

GUI work is not my forte but I'd speculate that you need to free the old
images once you're done with them.

------------------
Tom Hanlin
PowerBASIC Staff

**Lance Edmonds** · 4 Jun 2001, 11:15 AM

Change images like this:

Code:

CONTROL SEND CBHNDL, Id&, %STM_GETIMAGE, %IMAGE_BITMAP, 0 TO hBmp&
CONTROL SET IMGBUTTONX hDlg&, Id&, NewImage$
DeleteObject hBmp&

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Branko Bedenik** · 5 Jun 2001, 04:14 AM

Lance,
I'm not using CallBack Function (see Code from yesterday!),
even though can you please clarify 2nd and 3rd parameters:
CONTROL SEND CBHNDL, Id&, %STM_GETIMAGE, %IMAGE_BITMAP, 0 TO
hBmp&,
instead I tried to use
CONTROL HANDLE hDlg&, Id& TO hCtl& followed by
DeleteObject hCtl& with no luck.

The other thing I noticed:
If I drag Dialog box across the screen the number of GDI objects
is increasing enormuously!!!

It seems to me that Mike Jenkins is having the same problems, see his topic

Regards
Branko

------------------

**Lance Edmonds** · 5 Jun 2001, 05:35 AM

I'm not using CallBack Function (see Code from yesterday!),

Actually you are! Your code has one called "WndProc", which is (surprise surprise, a callback function. It is not a PowerBASIC "CALLBACK" function though. The do the exact same job though, but if you use a CALLBACK, you can use the DDT system variables CBHNDL, CBCTL, CBMSG, etc.

can you please clarify 2nd and 3rd parameters:
CONTROL SEND CBHNDL, Id&, %STM_GETIMAGE, %IMAGE_BITMAP, 0 TO hBmp&

No problem:

Code:

CBHNDL        = hWnd (the handle to the parent dialog)
id&           = the id number of the control (not it's window handle) - in your code that would be %XSMER
%STM_GETIMAGE = the message to request the handle to the current image
%IMAGE_BITMAP = the type of image we want the handle to
0             = zero   [img]http://www.powerbasic.com/support/forums/wink.gif[/img]

instead I tried to use
CONTROL HANDLE hDlg&, Id& TO hCtl& followed by
DeleteObject hCtl& with no luck.

This would not work because you are retrieving the control's window handle, and then trying to delete a GDI object using the same number. Window handles and GDI handles are completely different entities.

The other thing I noticed:
If I drag Dialog box across the screen the number of GDI objects
is increasing enormuously!!!

This is a good clue that your callback code (probably the %WM_PAINT handler) is not cleaning up after itself properly. Remember to reselect all of the original/initial GDI objects back into the DC and then delete the ones you created, *before* calling EndPaint().

If you have not done so, get yourself a good Windows programming book... it will save you a few headaches if you understand how the GDI subsystem works before writing production code with it!

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Branko Bedenik** · 14 Jun 2001, 09:51 AM

Lance

I've cleared my Code now as suggested.
The only thing that does not work is changing a bitmap in a control.
You've suggested:

CONTROL SEND CBHNDL, Id&, %STM_GETIMAGE, %IMAGE_BITMAP, 0 TO hBmp&
CONTROL SET IMGBUTTONX hDlg&, Id&, NewImage$
DeleteObject hBmp&

with parameters
CBHNDL = hWnd (the handle to the parent dialog)
id& = the id number of the control (not it's window handle) - in your code that would be %XSMER
%STM_GETIMAGE = the message to request the handle to the current image
%IMAGE_BITMAP = the type of image we want the handle to
0 = zero

but it does not work!

Try it with IMGBUTTONX and see it yourself.

Regards

Branko S. Bedenik

------------------

**Lance Edmonds** · 14 Jun 2001, 09:21 PM

Sorry, but it works fine for me...

How about posting some code that clearly demonstrates your problem. BTW, the image you are using is a bitmap, right? If not, you'll have to adjust the message parameters accordingly.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Branko Bedenik** · 15 Jun 2001, 12:00 AM

Lance,
YES, I'm changing BITMAP,
here is the actual code from FUNCTION WndProc,
but only the part where i'm changing bitmaps

CASE %XSMER
Moment=Moment+1
IF Moment>3 THEN Moment=1
CONTROL SEND hToolBarRezultati1 , %XSMER, %STM_GETIMAGE, %IMAGE_BITMAP, 0 TO hBmp&
IF Moment=1 THEN CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MX"
IF Moment=2 THEN CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MY"
IF Moment=3 THEN CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MXY"
DeleteObject hBmp&
FUNCTION = 0: EXIT FUNCTION

Original initial bitmap is created at Dialog hToolBarRezultati1 creation
CONTROL SET IMGBUTTONX hToolBarRezultati1 , %XSMER, "MX"

Thanks for the help
Branko S. Bedenik

------------------

**Lance Edmonds** · 15 Jun 2001, 12:43 AM

Ok, have you stepped through the code and verified that hBmp& receives the image handle (ie, hBmp& is non-zero)?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Branko Bedenik** · 15 Jun 2001, 04:12 AM

Well,
this is the problem,
hBmp& is ZERO, so it does not acctually get proper handle
regards
Branko

------------------

**Lance Edmonds** · 15 Jun 2001, 05:22 AM

Duh! It suddenly occurred to me that you should be using %BM_GETIMAGE (for button controls) instead of %STM_GETIMAGE (for image controls).

It has been ages since I tested this technique, but I did do it with all DDT image controls and the method worked fine!

Sorry for the confusion!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Branko Bedenik** · 15 Jun 2001, 02:12 PM

Dear Lance
I am thinking if I should just say THANKS to you for the solution
of the problem (of course it works fine this way) or should
I mention it to BOB ZALE about problems we average programmers
have mastering PB/DLL, which is VERY good .
I've suggesated several "wish list" things and I only hope
new (still better) PB/DLL will come out soon
Thanks
Branko S. Bedenik

------------------

Announcement

W98, W95 Problems

W98, W95 Problems

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment