Some bugs

Topics: SharpMap v2.0, WinForms Controls
Dec 7, 2007 at 6:41 PM
Edited Dec 7, 2007 at 6:44 PM
I'm working on a test program with SharpMap v2beta1_updated,and found some bugs as follow:

1, when I resize my form,the map in mapcontrol can not refresh and keeps it's previous size(can we add some process code to the event method of mapcontrol resize?).
Then I add some codes to form_resize event method like this:
private void frmMap_Resize(object sender, EventArgs e)
if (!this.MapControl.Size.IsEmpty)
and then,sharpMap throwed a exception in file "Mappresenter2D.cs",error infos is "newEnvelope cannot be empty",is this a bug? How to fix it?

2, First,I add a layer to mapcontrol,code like as follow;
string sDataFile = System.IO.Path.Combine(DATAPATH, "countries.shp");
SharpMap.Data.Providers.ShapeFile.ShapeFileProvider oShapeFile = new SharpMap.Data.Providers.ShapeFile.ShapeFileProvider(sDataFile);
SharpMap.Layers.ILayer oLayer = new GeometryLayer("country",oShapeFile);
SharpMap.Styles.VectorStyle oStyle = new SharpMap.Styles.VectorStyle();
oStyle.Fill = new SharpMap.Styles.SolidStyleBrush(SharpMap.Styles.StyleColor.Chocolate);
oStyle.Outline.BackgroundBrush = new SharpMap.Styles.SolidStyleBrush(SharpMap.Styles.StyleColor.Blue);


oLayer.Style = oStyle;

then,I remove the layer from the mapcontrol


and then,I reload the "countries" shapefile as a vector layer to mapcontrol,a exception throwed,error infos like these:
file "countries.shp" is used by another thread currently,so the thread can not access this file.

How can I deal with the exception?

3,I load a layer to MapControl,and then minimize the winform,the map graphy can not redraw after the winform redraw.How the mapcontrol works,and how to redraw the map?

Dec 8, 2007 at 5:22 PM

I think, this is the same issue of using ActualWidth/ActualHeight because they are not properly updated.
If I try to create offscreen WPF control I can't see anything at all, because ViewSize will be reported as zero.
Maybe it's necessally to patch the code.
Dec 29, 2007 at 5:47 PM
Hi, I was facing the problem of the MapControl not drawing after calling Refresh on the control, minimizing and maximizing , or in essence, painting of the Control. After struggling so hard to fix it, I downloaded the source code for the control and with the help of the poor-man's debugger (MessageBox.Show), I was able to trace the problem to the OnPaint method of the control. There is a Queue used to store the objects that are going to be renderred. The objects are Dequeue'd from the Queue one after another and drawn as such. That means, at the end of the draw process, the Queue is empty and the next time you call it, it draws EMPTY. A quick fix is to copy the Queue before drawing and using the copy while maintaining the original for future drawing purposes. I think (and I THINK, just a suggestion) a permanent fix will be to use a List instead of a Queue. See fix below

/* Original version
while (_renderObjectQueue.Count > 0)
GdiRenderObject ro = _renderObjectQueue.Dequeue();

/* Quick fix
Queue<GdiRenderObject> quest = new Queue<GdiRenderObject>(_renderObjectQueue);

while (quest.Count > 0)
GdiRenderObject ro = quest.Dequeue();


If you don't have the source code, I can send ova 2 u my compiled version for your use.

Dec 30, 2007 at 1:36 PM
Edited Dec 30, 2007 at 1:37 PM
Another suggestion is to iterate over the queue without deque elements such using foreach-statement.
By the way, i can't undestand the logic at all - why is something will (over)drawed at all, it the queue is empty - which will results in empty drawing(s), and this only once. ... or more times? There are must be NO MESSAGES in the queue that can be proceed to drawing functions. This is really very strange...
Jan 4, 2008 at 9:50 AM
Very True, Alex74. I thought by copying it would be faster but using the IEnumerable seems to give better performance. In spite of using the IEnumerable, the performance is still not good enough. I think there has to be some rasterisation of the features along the line in order to improve speeds.
Jan 4, 2008 at 10:48 AM
Edited Jan 4, 2008 at 1:35 PM
Correct. Sometimes using of IEnumerable is not a good option, because of some work for initialising. If there are less elements to iterate it's better to use for this[].
... but, if the overall complete work take a 100000 times more as initialisation, there are no reasons not to use the IEnumerable.