Out of memory exception in CreateGraphics (GdipCreateFromHWND) - winforms

on certain machines that vary in configuration (OS, graphics card and memory) I get an OutOfMemory exception. Some tests showed that there is no significant increase in virtual memory consumed. That's the piece of code where the exception is raised:
public override Size GetPreferredSize(Size proposedSize)
{
try
{
using (Graphics g = this.CreateGraphics())
{
SizeF measured = g.MeasureString(this.Text, this.Font); // <= OutOfMemoryException
measured += new SizeF(1, 1);
return measured.ToSize();
}
}
catch (OutOfMemoryException oom)
{
System.Diagnostics.Trace.WriteLine(oom.ToString());
}
return proposedSize;
}
The class is derived directly from label.
CreateGraphics() makes a call to the GDI+ function GdipCreateFromHWND which could in some cases return a status (3) that raises the OutOfMemoryException I face:
[EditorBrowsable(EditorBrowsableState.Advanced), SecurityPermission(SecurityAction.LinkDemand, Flags=SecurityPermissionFlag.UnmanagedCode)]
public static Graphics FromHwndInternal(IntPtr hwnd)
{
IntPtr zero = IntPtr.Zero;
int status = SafeNativeMethods.Gdip.GdipCreateFromHWND(new HandleRef(null, hwnd), out zero);
if (status != 0)
{
throw SafeNativeMethods.Gdip.StatusException(status); // status = 3 throws an OutOfMemoryException with text "Out of memory"
}
return new Graphics(zero);
}
But unfortunately I have not found documentation on the function and cases when it returns Out Of Memory.
The issue is at least repeatable on one customers machine very fast. All he has to do is click on a button that creates a new window where one of this derived Label is placed and which is used to display content in a WebBrowser control.
If you have any ideas that could help me find reasons of the exception it would be great!
Cheers,
Michael

The un-solution: Don't use Graphics. If your application runs SetCompatibleTextRenderingDefault(false) at startup (which it should, because it yields better text rendering), you should use TextRenderer.MeasureText instead of MeasureString, because otherwise you will use GDI+ for measuring and GDI for drawing which will create discrepancies between actual rendering and measurement.
Another solution could be not caching the Graphics object but caching the size. Since you are not using proposedSize anyway, simply measure the text whenever the Text or Font property change and return that cached value in GetPreferredSize.

This might work:
private Graphics _graphics;
protected override void OnPaint(PaintEventArgs e)
{
_graphics = e.Graphics;
base.OnPaint(e);
}
public override Size GetPreferredSize(Size proposedSize)
{
try
{
SizeF measured = _graphics.MeasureString(this.Text, this.Font);
measured += new SizeF(1, 1);
return measured.ToSize();
}
catch (OutOfMemoryException oom)
{
System.Diagnostics.Trace.WriteLine(oom.ToString());
}
return proposedSize;
}
The documentation at http://msdn.microsoft.com/en-us/library/system.windows.forms.control.creategraphics.aspx states "you cannot cache the Graphics object for reuse, except to use non-visual methods like Graphics.MeasureString", which is exactly what you are trying to do. This will fail if GetPreferredSize is called before the control is painted, and you'll want to Dispose the Graphics object, but maybe this will help get you closer to a viable solution.

Related

How can the 'fling/flick scrolling' be disabled in CefSharp.Wpf?

Is there a way to disable the 'touch fling scrolling' behaviour in CefSharp.Wpf (or potentially via Cef, Chromium, etc)?
I appreciate it's an unusual request as touch fling scrolling is a great feature. But unfortunately, I need to integrate with a dodgy touch screen hw/driver which works nicely for drag.. but fails miserably when flick scrolling as it consistently 'over scrolls'. e.g. a gentle flick on the screen causes the page content to scroll multiple pages (instead of just a few lines).
There's no CefSharp/Cef/Chromium flag or public method available to cancel Chromium's fling behavior.
Fortunately though, Chromium does internally cancel the fling behavior under certain scenarios (refer Chromium's fling_controller.cc). One such scenario is a user touch down event.
So the trick is to simulate a touch down cancel event pair. Because CefSharp doesn't offer a 'post touch down' event for users to implement the logic (i.e. too much of an edge case), the easiest way is to implement the feature via a derived class.
Here's a complete example (with dependency property binding) in case it helps anyone else look for the same solution..
public class ChromiumWebBrowserEx : ChromiumWebBrowser
{
public static readonly DependencyProperty IsFlingDisabledProperty = DependencyProperty.Register("IsFlingDisabled", typeof(bool), typeof(ChromiumWebBrowserEx));
public bool IsFlingDisabled
{
get => (bool) GetValue(IsFlingDisabledProperty);
set => SetValue(IsFlingDisabledProperty, value);
}
protected override void OnTouchUp(TouchEventArgs e)
{
base.OnTouchUp(e);
if (IsFlingDisabled)
CancelFling(e);
}
private void CancelFling(TouchEventArgs e)
{
// cancel the fling by creating a pseudo touch down followed by a cancellation
var touchPoint = e.GetTouchPoint(this);
if (touchPoint.Action == TouchAction.Up)
{
var touchEvent = new TouchEvent
{
Id = e.TouchDevice.Id,
X = (float) touchPoint.Position.X,
Y = (float) touchPoint.Position.Y,
PointerType = PointerType.Touch,
Modifiers = WpfExtensions.GetModifierKeys(),
Type = TouchEventType.Pressed
};
GetBrowser().GetHost().SendTouchEvent(touchEvent);
touchEvent.Type = TouchEventType.Cancelled;
GetBrowser().GetHost().SendTouchEvent(touchEvent);
}
}
}

Multiple NotifyIcon images in task status area

I have a WPF application I like to keep quietly running when the user closes the main window. I do this using a NotifyIcon in the task status area, and use it as such in my App.xaml.cs:
protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);
_notifyIcon = new NotifyIcon();
_notifyIcon.DoubleClick += (sender, args) => ShowMainWindow();
_notifyIcon.Icon = Wpf.Properties.Resources.QDrive;
_notifyIcon.Visible = true;
CreateContextMenu();
new Bootstrapper().Run();
Debug.Assert(Current.MainWindow != null, "Application.Current.MainWindow != null");
Current.MainWindow.Closing += MainWindowOnClosing;
}
private void CreateContextMenu()
{
_notifyIcon.ContextMenuStrip = new ContextMenuStrip();
_notifyIcon.ContextMenuStrip.Items.Add("Open Q-Drive...").Click += (sender, args) => ShowMainWindow();
_notifyIcon.ContextMenuStrip.Items.Add("Exit").Click += (sender, args) => ExitApplication();
}
private void ExitApplication()
{
_isExit = true;
Debug.Assert(Current.MainWindow != null, "Application.Current.MainWindow != null");
Current.MainWindow.Close();
_notifyIcon.Visible = false;
_notifyIcon.Dispose();
_notifyIcon = null;
}
Yet after closing and restarting the app a few times while debugging in VS2017, I have multiple icons visible, of which all but the active one vanish on mouse-over. I notice this is a bug with a few other applications I use that I have not developed myself.
How can I prevent this?
NotifyIcon leaves its icon behind if you exit the program without hiding the icon first.
You're hiding it in ExitApplication, of course. I suspect that while debugging, though, you're not always exiting the program by selecting the Exit item on the menu, but simply by stopping Visual Studio. That's why the orphaned icon gets left behind.
This isn't unusual in development, but it won't affect your users unless they use the Task Manager to force an immediate halt to your program.
If it bothers you, though, you could write a global exception handler (something you should probably do anyway) and in that handler you could hide the icon, taking care first to make sure it still exists.
Of course, if you break on exceptions in Visual Studio and you abruptly terminate the program, even that global exception handler won't hide the NotifyIcon.

Mouse.Capture returns false and fails

To simulate a modal dialog in WPF, I display a Window and call: Mouse.Capture(dialogBoxArea, CaptureMode.SubTree);
The call returns false.
Mouse.Captured is null.
dialogBoxArea.Visibility is Visibility.Visible.
dialogBoxArea.IsEnabled is true.
If the line is called again a second time, it returns true and correctly captures the mouse.
What condition might I be missing that is preventing the capture from working?
Edit
Here's what I've tried so far.
if (Mouse.Captured != null)
{
// Not called, so presumably, nothing has already captured the mouse
MessageBox.Show("already captured");
}
if (dialogBoxArea.Visibility != Visibility.Visible)
{
// Not called
MessageBox.Show("not visible");
}
if (!dialogBoxArea.IsEnabled)
{
// Not called
MessageBox.Show("not enabled");
}
// According to documentation, this should release mouse capture from anything that holds it
Mouse.Capture(null);
// Attempt to capture the mouse
if (!Mouse.Capture(dialogBox, CaptureMode.SubTree))
{
// This is called
Mouse.Capture(null);
Mouse.Capture(dialogBox, CaptureMode.SubTree);
}
As a first iteration i would talk to your client.
The following opens a dialog option window that is always on top of the original window and blocks calls to it, but does not hinder the overall execution at all. If your customer sees the behaviour he may be happy with that.
namespace StackoverflowExample
{
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
void NewWindowAsDialog(object sender, RoutedEventArgs e)
{
Window myOwnedDialog = new Window();
myOwnedDialog.Owner = this;
myOwnedDialog.ShowDialog();
}
}
}
I will post another option later here that will illustrate how to load a window into a subdivision (grid etc.) of your xaml. You could filter all other calls based on the content that is loaded into that division rather then filtering the mouscall. Your filtering could run into the problem of the logical vs the viewtree - you only ever want to look at the trees if you create your own templates from scratch.

WPF imaging problems

Okay I have a an wpf image object, and it displays live images. So I have used a timer to refresh the image.
public void LoadLiveImage()
{
System.Windows.Media.PixelFormat pf = PixelFormats.Bgr24;
int stride = 4 * ((24 * cameraFrame.img_width + 31) / 32);
BitmapSource bmpImage= BitmapSource.Create(cameraFrame.img_width, cameraFrame.img_height, cameraFrame.img_width, cameraFrame.img_height, pf, null, cameraFrame.img_pixel, stride);
RemoteCameraImage.Source = bmpImage;
}
void dispatcherTimer_Tick(object sender, EventArgs e)
{
LoadLiveImage();
}
No issues, this is working fine.
However, I tried to move this to a thread and no image is displayed.
private void showLiveImage()
{
while (this.isCameraViewOpen)
{
if (RemoteCameraImage.Dispatcher.CheckAccess())
{
System.Windows.Media.PixelFormat pf = PixelFormats.Bgr24;
int stride = 4 * ((24 * cameraFrame.img_width + 31) / 32);
BitmapSource bmpImage = BitmapSource.Create(cameraFrame.img_width, cameraFrame.img_height, cameraFrame.img_width, cameraFrame.img_height, pf, null, cameraFrame.img_pixel, stride);
RemoteCameraImage.Source = bmpImage;
System.Threading.Thread.Sleep(5);
}
else
this.RemoteCameraImage.Dispatcher.Invoke(DispatcherPriority.Normal, new ImageUpdater(this.showLiveImage));
}
}
The showLiveImage isrunning as a thread. The image is received, there is not problem in that. I tested by saving the img_pixel array to a bmp file and file is generated. Just that the image is not displayed on. So I put a messagebox to be shown after the source is assigned, and then I m able to see the image on Image object. SO I think the problem I increased the Sleep time, but even the image is not refreshed. WHAT could be the issue?
EDIT:
After moving the code which was updating the image to another function, it works fine. And I used BeginInvoke() instead of invoke an all works fine.
Sometime ago I had similiar problems and I found this on Stackoverflow, which sovled it for me
Images on second thread
WPF Dispatcher {"The calling thread cannot access this object because a different thread owns it."}
If you have no intention of modifying the image once you have created
it you can freeze it using Freezable.Freeze and then assign to
GeneratedImage in the dispatcher delegate (the BitmapImage becomes
read-only and thus threadsafe as a result of the Freeze). The other
option would be to load the image into a MemoryStream on the
background thread and then create the BitmapImage on the UI thread in
the dispatcher delegate with that stream and the StreamSource property
of BitmapImage.
Try to use the Application.Current.Dispatcher instead of the one you used.
I believe this will do the trick.
Cheers

Invoke or BeginInvoke cannot be called on a control until the window handle has been created

I have a SafeInvoke Control extension method similar to the one Greg D discusses here (minus the IsHandleCreated check).
I am calling it from a System.Windows.Forms.Form as follows:
public void Show(string text) {
label.SafeInvoke(()=>label.Text = text);
this.Show();
this.Refresh();
}
Sometimes (this call can come from a variety of threads) this results in the following error:
System.InvalidOperationException occurred
Message= "Invoke or BeginInvoke cannot be called on a control until the window handle has been created."
Source= "System.Windows.Forms"
StackTrace:
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
at DriverInterface2.UI.WinForms.Dialogs.FormExtensions.SafeInvoke[T](T control, Action`1 action)
in C:\code\DriverInterface2\DriverInterface2.UI.WinForms\Dialogs\FormExtensions.cs:line 16
What is going on and how do I fix it? I know as much as it is not a problem of form creation, since sometimes it will work once and fail the next time so what could the problem be?
PS. I really really am awful at WinForms, does anyone know a good series of articles that explains the whole model and how to work with it?
It's possible that you're creating your controls on the wrong thread. Consider the following documentation from MSDN:
This means that InvokeRequired can
return false if Invoke is not required
(the call occurs on the same thread),
or if the control was created on a
different thread but the control's
handle has not yet been created.
In the case where the control's handle
has not yet been created, you should
not simply call properties, methods,
or events on the control. This might
cause the control's handle to be
created on the background thread,
isolating the control on a thread
without a message pump and making the
application unstable.
You can protect against this case by
also checking the value of
IsHandleCreated when InvokeRequired
returns false on a background thread.
If the control handle has not yet been
created, you must wait until it has
been created before calling Invoke or
BeginInvoke. Typically, this happens
only if a background thread is created
in the constructor of the primary form
for the application (as in
Application.Run(new MainForm()),
before the form has been shown or
Application.Run has been called.
Let's see what this means for you. (This would be easier to reason about if we saw your implementation of SafeInvoke also)
Assuming your implementation is identical to the referenced one with the exception of the check against IsHandleCreated, let's follow the logic:
public static void SafeInvoke(this Control uiElement, Action updater, bool forceSynchronous)
{
if (uiElement == null)
{
throw new ArgumentNullException("uiElement");
}
if (uiElement.InvokeRequired)
{
if (forceSynchronous)
{
uiElement.Invoke((Action)delegate { SafeInvoke(uiElement, updater, forceSynchronous); });
}
else
{
uiElement.BeginInvoke((Action)delegate { SafeInvoke(uiElement, updater, forceSynchronous); });
}
}
else
{
if (uiElement.IsDisposed)
{
throw new ObjectDisposedException("Control is already disposed.");
}
updater();
}
}
Consider the case where we're calling SafeInvoke from the non-gui thread for a control whose handle has not been created.
uiElement is not null, so we check uiElement.InvokeRequired. Per the MSDN docs (bolded) InvokeRequired will return false because, even though it was created on a different thread, the handle hasn't been created! This sends us to the else condition where we check IsDisposed or immediately proceed to call the submitted action... from the background thread!
At this point, all bets are off re: that control because its handle has been created on a thread that doesn't have a message pump for it, as mentioned in the second paragraph. Perhaps this is the case you're encountering?
I found the InvokeRequired not reliable, so I simply use
if (!this.IsHandleCreated)
{
this.CreateHandle();
}
Here is my answer to a similar question:
I think (not yet entirely sure) that
this is because InvokeRequired will
always return false if the control has
not yet been loaded/shown. I have done
a workaround which seems to work for
the moment, which is to simple
reference the handle of the associated
control in its creator, like so:
var x = this.Handle;
(See
http://ikriv.com/en/prog/info/dotnet/MysteriousHang.html)
The method in the post you link to calls Invoke/BeginInvoke before checking if the control's handle has been created in the case where it's being called from a thread that didn't create the control.
So you'll get the exception when your method is called from a thread other than the one that created the control. This can happen from remoting events or queued work user items...
EDIT
If you check InvokeRequired and HandleCreated before calling invoke you shouldn't get that exception.
If you're going to use a Control from another thread before showing or doing other things with the Control, consider forcing the creation of its handle within the constructor. This is done using the CreateHandle function.
In a multi-threaded project, where the "controller" logic isn't in a WinForm, this function is instrumental in Control constructors for avoiding this error.
Add this before you call method invoke:
while (!this.IsHandleCreated)
System.Threading.Thread.Sleep(100)
Reference the handle of the associated control in its creator, like so:
Note: Be wary of this solution.If a control has a handle it is much slower to do things like set the size and location of it. This makes InitializeComponent much slower. A better solution is to not background anything before the control has a handle.
var that = this; // this is a form
(new Thread(()=> {
var action= new Action(() => {
something
}));
if(!that.IsDisposed)
{
if(that.IsHandleCreated)
{
//if (that.InvokeRequired)
that.BeginInvoke(action);
//else
// action.Invoke();
}
else
that.HandleCreated+=(sender,event) => {
action.Invoke();
};
}
})).Start();
I had this problem with this kind of simple form:
public partial class MyForm : Form
{
public MyForm()
{
Load += new EventHandler(Form1_Load);
}
private void Form1_Load(Object sender, EventArgs e)
{
InitializeComponent();
}
internal void UpdateLabel(string s)
{
Invoke(new Action(() => { label1.Text = s; }));
}
}
Then for n other async threads I was using new MyForm().UpdateLabel(text) to try and call the UI thread, but the constructor gives no handle to the UI thread instance, so other threads get other instance handles, which are either Object reference not set to an instance of an object or Invoke or BeginInvoke cannot be called on a control until the window handle has been created. To solve this I used a static object to hold the UI handle:
public partial class MyForm : Form
{
private static MyForm _mf;
public MyForm()
{
Load += new EventHandler(Form1_Load);
}
private void Form1_Load(Object sender, EventArgs e)
{
InitializeComponent();
_mf = this;
}
internal void UpdateLabel(string s)
{
_mf.Invoke((MethodInvoker) delegate { _mf.label1.Text = s; });
}
}
I guess it's working fine, so far...
What about this :
public static bool SafeInvoke( this Control control, MethodInvoker method )
{
if( control != null && ! control.IsDisposed && control.IsHandleCreated && control.FindForm().IsHandleCreated )
{
if( control.InvokeRequired )
{
control.Invoke( method );
}
else
{
method();
}
return true;
}
else return false;
}

Resources