Yes i did put checkres after the dialog is closed - sorry wasnt clear
Board index FiveWin for Harbour/xHarbour Application Slowdown
Page: 1 2 (24 posts)
When I look at the TBtnbmp class it does appear that all the bitmaps are being released. I suggest building the smallest test program you can with just a dialog and a btnbmp and seeing if all the bitmaps are being released. If they are not, please post your test program here.
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Peter
There were some cases in previous fwh releases where fonts and brushes were not correctly released, concerning xbrowse, gets..etc
This was fixed in fwh 10.9 and upwards
If you can upgrade from 10.6 , i think it can help solving your problem
On another hand concerning the checkres file, i do not use setresdebug just the checkres and the reading of the file is very clear, program and line n°, it helped me fixing memory consuption issues in my application.
HTH
Richard
Richard,
can you show me an example of your code where you use checkres as when i tried nothing happened.
I'm not sure i can upgrade from 10.06 yet as future versions caused me some display problems - see viewtopic.php?f=3&t=19786&start=0
Peter
At the very beginning of my application this is what i have
SetKey( VK_F11, { || FERASE("CHECKRES.TXT"),CHECKRES() } )
when i want to check the resources , i press F11 and get the file
Hth
Richard
Uwe,
My customers have installed the software and have noted that it has improved performance - is there any way of doing what this app is doing programtically?
As I cant upgrade FW, i cant see if the latest memory leaks are actually the cause and if it will help the problems im getting
Best regards,
Pete
Pete,
>My customers have installed the software and have noted that it has improved performance - is there any way of doing what this app is doing programatically?
I assume you are referring to the memory monitoring software that Uwe suggested? If so, then there is nothing similar built into FW.
>As I cant upgrade FW, i cant see if the latest memory leaks are actually the cause and if it will help the problems im getting.
You can be sure that memory leaks will slow down a computer, and many apps (not just FW apps) have memory leaks so over time, a computer will get slower. Regular reboots will help. More RAM will also help by delaying the effects. You can set computers to reboot automatically during the night (timed so they are not doing backups, etc.).
You may have also introduced memory leaks yourself in your code (we all do it). When you define fonts, bitmaps, etc. you have to remember to End() them too. You can look through your code for such problems.
Regards,
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Hi James,
I recently went through my code and made sure I was ending all my defined fonts. I don't use many bitmaps in my app except on BtnBmps - do you think i should end these when i close any dialogs? (please say no!!)
I have just written a small routine that i call when the dialog is closed (in the valid clause):
I noticed that when my routine showed which object was being ended, it was only removing every other object. For example, if the dialog had 6 tSay objects, the first, third and fifth tSay object would end!! - Would the above code help to remove any objects remaining open in a dialog or am i barking up the wrong tree? Could this be demonstrating that when a dialog is closed, not all the objects are being destroyed properly?
Pete
I recently went through my code and made sure I was ending all my defined fonts. I don't use many bitmaps in my app except on BtnBmps - do you think i should end these when i close any dialogs? (please say no!!)
I have just written a small routine that i call when the dialog is closed (in the valid clause):
FUNCTION CompleteEnd(oDlg)Â Â
  LOCAL nCount  := 0
  LOCAL lFolder := .F.
  LOCAL oFolder
  //First check to see if there is a folder within the dialogÂ
  FOR nCount := 1 TO Len(oDlg:aControls)
    IF Alltrim( Upper( oDlg:aControls[nCount]:Classname() ) ) == "TFOLDER"
      lFolder := .T.
      oFolder := oDlg:aControls[nCount]
    ENDIF Â
  NEXT
  IF lFolder
    //Folder Exists, End objects within folders
    FOR nCount := 1 TO Len(oFolder:aDialogs)     Â
      Aeval(oFolder:aDialogs[nCount]:aControls,{|o| IF(o <> NIL, (Msginfo("FOLDER " + o:ClassName()), o:End()), .T.)})
    NEXT
  ENDIF Â
  //End objects within dialog
  Aeval(oDlg:aControls,{|o| IF(o <> NIL, (Msginfo(o:ClassName()), o:End()), .T.)})
RETURN NILI noticed that when my routine showed which object was being ended, it was only removing every other object. For example, if the dialog had 6 tSay objects, the first, third and fifth tSay object would end!! - Would the above code help to remove any objects remaining open in a dialog or am i barking up the wrong tree? Could this be demonstrating that when a dialog is closed, not all the objects are being destroyed properly?
Pete
Pete,
Barking up the wrong tree.
Controls are ended automatically when the parent is ended. The controls themselves are supposed to end any resources they are using. If a control is not ending all the resources it is using, you ending it before closing the parent is not going to help--it is a bug in the control. The issue is not that the parent is not ending the control, but rather the control is not ending the resource or resources.
Remembering to end resources that you have initiated in your code will help since there is no way for FW to automatically do this.
Regards,
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Page: 1 2 (24 posts)