I have a small application (MDI) that is running as a service using the timer event on the only sheet in the application. The timer event is set at 5 sec interval. When the event is triggered, it checks to see if it is currently processing any requests. If it is then it exits the event and waits another 5 seconds. If it is not running then it executes the 'process' function and exits the timer event. The process function sets an instance boolean to true and processes the requests (printing labels). When the process function is done, it sets the boolean to false.
Timer event:
if Ib_processing then
return
else
of_process()
end if
Of_process():
ib_processing = true
// retrieve data from database and process //
Ib_process = false
return
This is very basic stuff. Most of the time there are no requests to process. However, every 5 seconds the application grows 34Kb. Not a lot but over several days it gets very large. I could understand this if it was constantly printing labels as other objects are invovled and there may be an issue with thos objects. I did test this with the queue empty (database table has no rows) and let it run for a couple of hours and it still grows.
I have read some of the other posts about nulling out arrays but this application does not use any. It basically retrieves a list via a datawindow (which is only created once on the open event) and spins through the list. If no rows are retrieved, it will exit the function.
Any Ideas??
That's a YES! The Reset() releases all buffer memory. The DataObject = "" unloads the DWO & frees it's memory. The Yield() command allows the unload & free to complete. To be ultra safe, you could also throw in a GarbageCollect() could command as well. HTH
Regards ... Chris
does all this simply not happen when the DS is destroyed without being reset first? If so that does sound like a giant memory leak waiting to happen.
In "theory" yes but I've found (since PB 4.0 when the DS feature was 1st added) that the PBVM does not always cleanup these resources or if it does (via Garage Collection) that it can take a while (ie: just marking memory as logically deleted vs releasing it immediately). Also, using PB versions since 1.0, I've found that switching to newer C++ compilers (ie: PB2019 => VC++2010, PB2022 => VC++2019, PB2022R2 => VC++2022) can introduce varying behaviours around PBVM function & memory on various features. I learned a way back that the procedure I gave you was the best way to force the PBVM to better handle DS management. I've had this code in my STD Framework since before the PFC was released that addressed this one perspective of DS memory control. HTH
Regards ... Chris