We are now seeing an exception “System.ArgumentException: Parameter is not valid.” from within your DesktopEdition component. Call stack is provided below. Your code appears to be responding to a mouse move event, then a bunch of those obfuscated methods in the stack, and finally a call to the Bitmap ctor that results in the exception. Unfortunately with your obfuscated methods there is no reasonable way to determine what lead up to the exception.
Please review to determine how this could happen, and how to avoid it. It really looks like the type of thing your code should be checking for, and if detected, rather than a general and unhelpful exception from the bitmap ctor, return an exception indicating what was actually wrong, and where possible what it relates to. For example, “Detected invalid bitmap with height of 0 processing InMemoryFeatureLayer named ‘lakes’”. Anything is better than “System.ArgumentException: Parameter is not valid.” when I can’t even see what the parameters were.
System.ArgumentException: Parameter is not valid.
at System.Drawing.Bitmap…ctor(Int32 width, Int32 height, PixelFormat format)
at System.Drawing.Bitmap…ctor(Int32 width, Int32 height)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.mhQ=(RectangleShape extent, Overlay overlay, Int32 width, Int32 height, GeographyUnit geographyUnit)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.nRQ=(IEnumerable`1 drawingOverlays)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.lBQ=(RectangleShape extent)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.khQ=(Int32 delayInterval, RectangleShape extent)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.Refresh(RectangleShape extent, IEnumerable`1 overlays)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.Refresh(RectangleShape extent, Overlay overlay)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.hhQ=(InteractionArguments interactionArguments)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.gRQ=(Object sender, CRU= e)
at ThinkGeo.MapSuite.DesktopEdition.MouseEventAnalyzer.OnMouseEvent(CRU= e)
at ThinkGeo.MapSuite.DesktopEdition.MouseEventAnalyzer.BRU=(Double screenX, Double screenY, Double worldX, Double worldY)
at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.hBQ=(Object sender, MouseEventArgs e)
at System.Windows.Forms.Control.OnMouseMove(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseMove(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
Bitmap ctor exception - only TG in the call stack
Hi Russ,
That should caused by the width or height equal zero for now.
The width and height value is directly read from current control, so please keep they are bigger than zero.
Regards,
Don
So, you are saying that the Winforms Map control itself was zero in size? That does not fit with the report I got from the field. The report was that they were using the map, which would imply a non-zero size. And the call stack indicates a “mouse move” which seems highly unlikely with a zero sized window. I’ll investigate further with the user on what they might have done regarding size so that we can find a work around to avoid future crashes on this build.
In any case I very much do not think your control should throw an exception if dynamic resizing results in a zero size. Between resizable frames, splitters, and any number of dynamic UI layouts your control could find itself part of, it is not unreasonable at all to expect that it might periodically find itself with a zero dimension as the user or application allocates space to other higher priority functions, then reallocating screen space back the map when again needed. Please request a fix to add defensive programing to prevent this exception in your release build as soon as possible.
I just tried this on our RC product. With both “floated” map (in it’s own window) and docked in the main app. When resized to “zero” using the window frame or the splitter, I do not get this exception. That combined with the mouse move message that was obviously being handled in the all stack leads me to believe there is something else going on here.
For an update, I did manage to get it with the map floated and resized to a zero height.
I can set a min size on our container window to avoid that in future builds, but I still maintain that your code should not throw an exception like that. This case is particularly bad because you are responding to a mouse-move message, so your clients can’t even catch and handle the exception, so you are guaranteed to crash the application.
Hi Russ,
I just guess that from your exception information, because you can see the exception is thrown by system API, for the system API the only reason should be one of the parameters equal zero, from the code I found the two parameters are directly read from control. I am not sure why our developers hadn’t handled possible system exception here, but I will let them know your suggestion. Thanks for your suggestions for our product.
In fact we found another similar exception last week, when you refresh map by timer and make the map minimization, for some type of window it will throw exception.
I think our developer only make sure map refresh well when it’s size is bigger than zero, so please avoid refresh map when its size equal zero.
Regards,
Don