1 of 1 people found this helpful
I'll bet that you have already taken care of this, but, just in case:
Assuming you are no longer utilizing MBS WebView.InstallCallback, I'd make sure that there are no traces of invoking that particular code so as to free up any extra resources that feature consumes.
Like I said -- you have probably taken care of this, but on the off chance that you still have any residual references to that code, it seemed worth mentioning.
Good luck! I will be watching this thread with interest to see if anyone has some good advice to offer.
I had actually missed removing the Install Callback step. Good catch!
It removed about a 10mb memory overhead.
UPDATE TO ISSUE:
I have done some testing and here is what I have found.
In my particular case, once the user reaches the layout on which all his work is done, the memory hit is at 111mb. After completing an order cycle in the record (data input, order processing) the memory increases by about 9* mb. After creating a new record and loading the html onto that large webviewer, the memory increases 10mb. I did several iterations, and they all average at about the same increases in memory, rounding of to 20 mb per record creation and capture in a single session.
I tried to flush cache to disk. No tangible impact.
I tried to refresh window flushing both options. No impact at all.
Then I tried closing the window. On a single iteration test (one record), the memory increased by 19.6mb during data capture. Upon closing the window, about exactly that same amount decreased in memory.
I will do some more tests later today, but I thought I'd get the ball rolling and see if these tests help spark any ideas that might eventually give us a tangible solution. Knowing exactly how/when/what triggers filemaker to close it's connection with the embedded IE program inside of Filemaker would be ideal... But any and all ideas are welcome.