Posted 8 September 2017, 3:22 pm EST
Even though this thread is a year old I’ve just received a similar problem from the field. Like mchargue I cannot reproduce this in my environment however I CAN guarantee that it is happening at ONE customer installation (multiple instances at their location). I have concluded of course that our customer has some “strange” configuration that’s causing the problem…
We’re using Spread v9.35.20161.0 (I’ve attempted to upgrade to v10 however am unable to do so due to a different bug with v10 which is critical to our operation and so we’ve reverted back to 9.35 which works better - except for this issue.)
Customer is running Win 7 64-bit.
As Sean Lawyer pointed out a year ago “…Spread should be handling this case better and automatically ignore invalid settings for VisualStyles instead of throwing an exception…”
My question is: Has this been fixed? Has there been any traction on this issue at all? Is there a work-around? I’ve attempted to set
spread.VisualStyles = FarPoint.Win.VisualStyles.Off
I understand the complexity of attempting to fix a bug that you cannot reproduce in your lab environment or with a simple test case - nonetheless this IS happening.
Here’s MY pertinent log information:
2017-04-04 14:14:15.4011 [ERROR] [TSMain.frmTsMain] Unhandled Exception. System.InvalidOperationException: Visual Styles-related operation resulted in an error because visual styles are currently disabled in the client area.
at System.Windows.Forms.VisualStyles.VisualStyleRenderer.IsCombinationDefined(String className, Int32 part)
at FarPoint.Win.DropDownButtonElement.OnPaintBackground(Graphics g, Rectangle rectInput)
at FarPoint.Win.ElementWindowless.PaintElements(Graphics g, Rectangle faceRect)
at FarPoint.Win.ElementWindowless.OnPaint(Graphics g, Rectangle rectInput)
at FarPoint.Win.SuperEditBase.OnPaint(PaintEventArgs e)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at FarPoint.Win.SuperEditBase.WndProc(Message& m)
at FarPoint.Win.FpCombo.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.VisualStyles.VisualStyleRenderer.IsCombinationDefined(String className, Int32 part)
at FarPoint.Win.DropDownButtonElement.OnPaintBackground(Graphics g, Rectangle rectInput)
at FarPoint.Win.ElementWindowless.PaintElements(Graphics g, Rectangle faceRect)
at FarPoint.Win.ElementWindowless.OnPaint(Graphics g, Rectangle rectInput)
at FarPoint.Win.SuperEditBase.OnPaint(PaintEventArgs e)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at FarPoint.Win.SuperEditBase.WndProc(Message& m)
at FarPoint.Win.FpCombo.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
What’s curious however is that my customer was able to temporarily resolve this issue by DISABLING the Themes service… So themes WAS running when the error occurs but stopping it FIXED the problem… My conclusion of course is that something related to but not the Themes-service proper has resulted in this problem - finding the WHAT is the needle in the haystack.