Hi all,
Experiencing an exception when trying to use a large bitmap (800 x 480) as a buffer before committing it to the LCD screen:
An exception of type ‘System.ObjectDisposedException’ occurred in Microsoft.SPOT.Graphics.dll but was not handled in user code
I have specified the custom heap to be 4MB. I’ve declared it as static, and I even tried instructing the garbage collector to ignore it GC.SuppressFinalize(bufferBMP).
Nevertheless I still get the above exception - am I missing something obvious?
Thanks,
Michael.
Can you please provide a very small example code showing the problem?
Gus,
It’s difficult as it’s fairly well integrated with quite a large project. (and I suspect my programming skills with regards to Object Oriented development are somewhat lacking)
Essentially the program works as follows:
A touch event calls a function which updates a buffer bitmap.
Following this the Invalidate(); function is called.
The on render event for the control copies the buffer bitmap to the canvas element. (Thus eliminating the need for a DispatchTimer…?)
The exception occurs during a draw to the buffer bitmap within the graphics update function (which shouldn’t be accessed by anything else since it was called from the only other function which uses it).
I’ve also tried using a Lock statement on all the instances where the buffer bitmap is accessed to try to ensure that it’s thread safe.
What is confusing me is that the error implies that the object has been cleared by GC even though I’ve declared it as static and stated that it shouldn’t be. Are there any other circumstances where this exception could be thrown?
Are there any GHI or other code samples showing the use of custom heap allocated large bitmaps being written to the screen?
I will have a go at paring the code down to the essentials in a format that I can attach (I’ll try and get it done today).
I will also try a smaller dimensioned buffer (so it gets allocated to the managed heap) and see if this makes any difference.
Cheers,
Michael.
There is nothing special about large bitmap beside it is loaded on customheap and so you need to free it manually when you are done using it. What you are seeing is not related to “large bitmap” I do not think