>>>Should I be concerned with these numbers - I run a single test and didn't do much
>>>
>>>Booking_Schedule form loading... Memory currently used is 3840
>>>
>>>Booking_Schedule form destroying... Memory currently used is 5934 (using sys(1011))
>>
>>..I think that you have something, because this is not memory, but memory handles.
>>In C language, when you need to use variables, arrays and other type of data from Heap memory, you need to "open" (reserve) that memory to use it (like the fopen in VFP for low level file handles), but once that this memory was used must be given back to the system, so you "free" that handle (like the fclose()) so the memory segment is free. If you do not close that memory handle or you misuse the reserved memory segment, then you have memory leak, and I think that this is what is happening here.
>>You can have a little amount of handles of difference (may be 10 or 20 that eventually should clean up), but having more than 2000 memory handles leaked are too much.
>>
>>You should put this function before and after some operations (methods) and even at a form level (before loading and after releasing) and may be adding a INKEY(1) (just for testing) to let the VFP automatic collector do his job, and measure the handles again to make sure that this numbers are so high.
>>
>>Every memory assignment, object reference and the like uses memory handles, so take care of cross-object references too, like passing object references to the form that are saved as properties or the like.
>
>I added inkey(1) before recording the memory. All I did is opened the form and closed it (didn't do anything). This is what I got in the log
>
>2017.03.01 16:04:16.442 ADMIN NAOMI 5 Booking_Schedule form loading... Memory currently used is 3336 BOOK_SCHEDULE.LOAD() WEBPAGES
>2017.03.01 16:04:26.315 ADMIN NAOMI 5 Booking_Schedule form destroying... Memory currently used is 5891 BOOK_SCHEDULE.DESTROY() WEBPAGES

Just to make sure, these are some use cases:

1) Modal form (simplest case)

log sys(1011) && log refers to saving in a log file or output to screen
do form whatever
log sys(1011) && log refers to saving in a log file or output to screen

2) Normal form

log sys(1011) && log refers to saving in a log file or output to screen
do form whatever && must clear events to close
read events
log sys(1011) && log refers to saving in a log file or output to screen

3) Object form reference on class

log sys(1011) && log refers to saving in a log file or output to screen
LOCAL loFrm as form
loFrm = createobject("YourFormClass")
loFrm.show(1) && The form must clear events and hide itself
loFrm.Relese()
loFrm = NULL
RELEASE loFrm
log sys(1011) && log refers to saving in a log file or output to screen

If your form is in a READ EVENTS, then the READ EVENTS loop have many handles open. Just when the form is hidden and closed and any reference to it is NULLed and RELEASEd, the memory handles can be confidently queried.

Memory leaks are one of the hardest problems to track down, and the problem may be even have nothing to do with the code, but with the OCX itself. The only way to make sure is taking out the OCX from the form (temporarily) and using the form without it a little, then close it again, so you can know if the difference on handles varies too much.

There is a lot of testing for this...