I am generating new windows via the code below and displaying a webpage there and then close it. But after a while software gives out of memory exception. So there is memory leak happening. What might be the cause and how to solve it ? Thank you.
This is how do i start new window . i am doing a loop so there are being started thousands of new windows. As you can see after 60 seconds new window get itself close.
NewWindowThread<TitleWindow, string>(c => new TitleWindow(c), "the url that is going to be displayed at new window");
private void NewWindowThread<T, P>(Func<P, T> constructor, P param) where T : Window
{
Thread thread = new Thread(() =>
{
T w = constructor(param);
w.Show();
w.Closed += (sender, e) => w.Dispatcher.InvokeShutdown();
System.Windows.Threading.Dispatcher.Run();
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
}
public class TitleWindow : Window
{
WebBrowser webnew = new WebBrowser();
public TitleWindow(string srUrl)
{
DockPanel dk = new DockPanel();
dk.Width = 900;
dk.Height = 600;
this.AddChild(dk);
webnew.Navigated += new NavigatedEventHandler(wbMain_Navigated);
System.Windows.Threading.DispatcherTimer dispatcherTimer3 = new System.Windows.Threading.DispatcherTimer();
dispatcherTimer3.Tick += new EventHandler(dispatcherTimer_Tick3);
dispatcherTimer3.Interval = new TimeSpan(0, 0, 0, 60, 0);
dispatcherTimer3.Start();
webnew.Height = 600;
webnew.Width = 900;
dk.Children.Add(webnew);
webnew.Navigate(srUrl);
this.WindowState = WindowState.Minimized;
}
void dispatcherTimer_Tick3(object sender, EventArgs e)
{
this.Close();
}
}
I immediately suspect that the WebBrowser control is not releasing it's resources when the window is closed as you are not calling it's Dispose() method. The WebBrowser control is a thin wrapper around the ActiveX MSHTML control.
Add a callback on the window Closing or Closed events to do this. e.g. webnew.Dispose().
Related
Async/Await is nice way to code responsive GUI but as I suppose cheese here isn't free. I think only the way to realize Await statement is a memory stack. Each time you call Await, there is a new pointer put in memory stack. Therefore if you call to frequently Await and result delays, you get stack overflow (that is the keyword you can't search here :))
Let's suppose we check some connection status asynchronously periodically.
Create a simple windows forms project with Form1 and form code is here.
using System;
using System.Threading.Tasks;
using System.Windows.Forms;
namespace testasync
{
public partial class Form1 : Form
{
int CallCount = 0;
int CalBackCount = 0;
Random r = new Random();
private Button butStart = new Button();
private Button butStop = new Button();
private Timer timer1 = new Timer();
private Label labCalls =new Label();
private Label labReturns = new Label();
public Form1()
{
this.ClientSize = new System.Drawing.Size(450, 200);
butStart.Location = new System.Drawing.Point(51, 38);
butStart.Size = new System.Drawing.Size(139, 47);
butStart.Text = "Start";
butStart.Click += new System.EventHandler(this.butStart_Click);
butStop.Location = new System.Drawing.Point(237, 38);
butStop.Size = new System.Drawing.Size(139, 47);
butStop.Text = "Stop";
butStop.Click += new System.EventHandler(this.butStop_Click);
labCalls.Location = new System.Drawing.Point(48, 149);
labCalls.Size = new System.Drawing.Size(100, 23);
labReturns.Location = new System.Drawing.Point(237, 149);
labReturns.Size = new System.Drawing.Size(100, 23);
Controls.Add(this.labCalls);
Controls.Add(this.labReturns);
Controls.Add(this.butStart);
Controls.Add(this.butStop);
timer1.Interval = 5;
timer1.Tick += new System.EventHandler(this.timer1_Tick);
}
private void butStart_Click(object sender, EventArgs e)
{
timer1.Enabled = true;
}
private void butStop_Click(object sender, EventArgs e)
{
timer1.Enabled = false;
}
private async Task myWork()
{
CallCount++;
await Task.Delay(2000);
if (r.Next(100)>10) //Check Connection
await Task.Delay(100000000);
CalBackCount++;
}
private async void timer1_Tick(object sender, EventArgs e)
{
labCalls.Text = CallCount.ToString();
await myWork();
labReturns.Text = CalBackCount.ToString();
}
}
}
instead of checking connection I use random check to wait long time for connection response.
If we run the project and hit start button, we'll see that memory consumption by the application rises by time. Therefore I suppose this is not the right way to use Await statement, I think better way is use threading with delegates or nice component BackgroundWorker with progress events. Or maybe there are better solutions?
Your assumptions on how async-await works aren't correct.
Each asynchronous method will be converted in a state machine that splits the method into several methods (the parts between the start, awaits and end) and orchestrates its execution.
A rogue asynchronous method will more likely exhaust the heap than the stack.
I have a MainForm and method which opens new window:
private void OpenWindow(object source, ElapsedEventArgs e)
{
var form = new SomeForm();
form.MdiParent = this;
form.Show();
}
And timer:
System.Timers.Timer timer = new System.Timers.Timer();
timer.Elapsed += new ElapsedEventHandler(OpenWindow);
timer.Interval = 10000;
timer.Enabled = true;
And it throws error on setting MdiParent: form.MdiParent = this;
Cross-thread operation not valid: Control 'MainForm' accessed from a
thread other than the thread it was created on.
How can I solve this problem?
You could use one of the other Timers because they handle the threading differently.
Explained here: Why there are 5 Versions of Timer Classes in .NET?
Based on Threading Model article, I think this should works in your cas:
var form = new SomeForm();
if (form.InvokeRequired)
{
form.Invoke(new MethodInvoker(delegate {
form.MdiParent = this;
}));
}
form.Show();
Or like this:
Invoke(new Action(() =>
{
form.MdiParent = this;
form.Show();
}));
I have a UserControl with a big table that is displaying values using a lot of converters. I am trying to display a ProgressBar in a new Window with Indeterminate State that is closing automatically when the UserControl Loaded event is fired.
This is the Thread creation in the backcode of my UserControl :
Thread progressBarThread = new Thread(new ThreadStart(delegate {
ProgressBarWindow progressBarWindow = new ProgressBarWindow();
progressBarWindow.IsIndeterminate = true;
progressBarWindow.LaunchProgressBarInBackground();
progressBarWindow.ShowDialog();
}));
progressBarThread.SetApartmentState(ApartmentState.STA);
progressBarThread.Start();
this.Loaded += (sender, e) => { Dispatcher.FromThread(progressBarThread).InvokeShutdown(); };
This code is "working", it is opening progressBarWindow but when I shutdown the thread using InvokeShutdown (the ugliest way to do it, i agree). The problem is that the DoWork from my backgroundWorker.
Here is the DoWork function :
private void BackgroundWorker_WaitUntilShouldStop(object sender, DoWorkEventArgs e)
{
// Do not access the form's BackgroundWorker reference directly.
// Instead, use the reference provided by the sender parameter.
BackgroundWorker bw = sender as BackgroundWorker;
// Start the time-consuming operation.
while (!bw.CancellationPending)
{
Thread.Sleep(500);
}
}
I would like to call my function contained in ProgressBarWindow to stop the DoWork from runnning and close the ProgressBarWindow normaly using :
progressBar.StopProgressBarInBackground();
This method is calling backgroundWorker.CancelAsync();
This will result in backgroundWorker terminating and progressBarWindow closing automatically.
But I don't have access to progressBar that is inside the progressBarThread. I tried to pass my UserControl using :
progressBarThread.Start(this);
this being the main window.
When trying to pass a variable from the main thread, this error is thrown :
An exception of type 'System.InvalidOperationException' occurred in WindowsBase.dll but was not handled in user code Additional information: The calling thread cannot access this object because a different thread owns it.
Does someone have a nice and correct way to do it without using myThread.InvokeShutdown() ?
Edit 1 :
I found a solution to my problem using a volatile variable :
volatile bool _isLoaded;
void CreateAndStopProgressBarWhenIsLoaded()
{
Thread progressBarThread= new Thread(new ThreadStart(
{
Controls.ProgressBar.ProgressBar progressBar = new Controls.ProgressBar.ProgressBar();
progressBar.IsIndeterminate = true;
progressBar.LaunchProgressBarInBackground();
DispatcherTimer dispatcherTimer = new DispatcherTimer();
dispatcherTimer = new DispatcherTimer();
dispatcherTimer.Tick += (sender, e) => {
if (_isLoaded)
progressBar.StopProgressBarInBackground();
};
// Try to stop `progressBar` every 500 ms
dispatcherTimer.Interval = TimeSpan.FromMilliseconds(500);
dispatcherTimer.Start();
progressBar.ShowDialog();
// Will only be reached once progressBar.ShowDialog(); returns
dispatcherTimer.Stop();
}));
progressBarThread.SetApartmentState(ApartmentState.STA);
progressBarThread.Start();
this.Loaded += (sender, e) => {
_isLoaded = this.IsLoaded;
progressBarThread.Join(); // Wait for progressBarThread to end
};
}
Now the question is do you have a better solution ?
Edit 2 :
Here is my final solution thanks to #AlexSeleznyov :
void CreateAndStopProgressBarWhenIsLoaded()
{
Controls.ProgressBar.ProgressBar pb = null;
ManualResetEvent manualResetEvent = new ManualResetEvent(false);
Thread progressBarThread = new Thread(new ThreadStart(delegate
{
Controls.ProgressBar.ProgressBar progressBar = new Controls.ProgressBar.ProgressBar();
pb = progressBar;
manualResetEvent.Set();
progressBar.IsIndeterminate = true;
progressBar.LaunchProgressBarInBackground();
progressBar.ShowDialog();
}));
progressBarThread.SetApartmentState(ApartmentState.STA);
progressBarThread.Start();
this.Loaded += (sender, e) => {
pb.Dispatcher.Invoke(delegate {
manualResetEvent.WaitOne();
pb.StopProgressBarInBackground();
});
progressBarThread.Join();
};
}
You might try this approach, to cache ProgressBar instance and then use it from another thread. Dispatcher.Invoke eradicates need for CheckAccess I've mentioned in comments.
void CreateAndStopProgressBarWhenIsLoaded()
{
var pb = new Controls.ProgressBar.ProgressBar[1];
Thread progressBarThread= new Thread(new ThreadStart(
{
Controls.ProgressBar.ProgressBar progressBar = new Controls.ProgressBar.ProgressBar();
pb[0] = progressBar;
progressBar.IsIndeterminate = true;
progressBar.LaunchProgressBarInBackground();
progressBar.ShowDialog();
}));
progressBarThread.SetApartmentState(ApartmentState.STA);
progressBarThread.Start();
this.Loaded += (sender, e) => {
pb[0].Dispatcher.Invoke(()=>pb[0].Close());
};
}
I think that you can use BackgroundWorker.RunWorkerCompleted in ProgressBarWindow - it will be invoked when you cancel a backgroundWorker.
private void backgroundWorker_RunWorkerCompleted(object sender,
RunWorkerCompletedEventArgs e)
{
if (e.Cancelled)
{
//close the window
}
}
My WPF application shows a window and when the user clicks a button, it begins to run its tasks and minimizes to a tray item in the notification area with a context menu where I would like the user to be able to cancel the operation.
The context menu worked before using a BackgroundWorker, however, cancellation did not. Since I've implemented a background worker,the context menu does not appear once the .runworkerasync() method has run.
My Notify Icon:
public NotifyIcon myNotifyIcon;
When my application runs I set it up like this:
private void setup_NotifyIcon()
{
myNotifyIcon = new NotifyIcon();
setTrayIcon();
myNotifyIcon.MouseDown += new MouseEventHandler(myNotifyIcon_MouseDown);
var menuItemCancel = new MenuItem("Cancel Parsing");
var contextMenu = new ContextMenu();
menuItemCancel.Click += new System.EventHandler(this.menuItemCancel_Click);
contextMenu.MenuItems.AddRange(new System.Windows.Forms.MenuItem[] { menuItemCancel });
myNotifyIcon.ContextMenu = contextMenu;
}
private void menuItemCancel_Click(object Sender, EventArgs e)
{
//do something
}
void myNotifyIcon_MouseDown(object sender, MouseEventArgs e)
{
if (e.Button == MouseButtons.Right)
{
//do something
}
}
Then when the user clicks the button:
worker.RunWorkerAsync();
Why won't myNotifyIcon.MouseDown += new MouseEventHandler(myNotifyIcon_MouseDown); trigger the context menu?
The solution turned out to be a threading issue as suggested by Sebastian in the comments.
The key was to start the icon on another thread using Application.Run() and to make the icon visible within that code.
Once this was done, right-clicking on the icon worked, as did the cancellation functionality being handled.
private void setup_NotifyIcon()
{
Thread notifyThread = new Thread(
delegate ()
{
myNotifyIcon = new NotifyIcon();
setTrayIcon();
myNotifyIcon.MouseDown += new MouseEventHandler(myNotifyIcon_MouseDown);
mnuCancel = new MenuItem("Cancel Parsing");
menu = new ContextMenu();
mnuCancel.Click += new System.EventHandler(menuItemCancel_Click);
menu.MenuItems.AddRange(new System.Windows.Forms.MenuItem[] { mnuCancel });
myNotifyIcon.ContextMenu = menu;
myNotifyIcon.BalloonTipIcon = System.Windows.Forms.ToolTipIcon.Info; //Shows the info icon so the user doesn't thing there is an error.
myNotifyIcon.BalloonTipText = "The P6 Parser will minimize to the system tray while working.";
myNotifyIcon.BalloonTipTitle = "Processing...";
myNotifyIcon.Visible = true;
myNotifyIcon.ShowBalloonTip(500);
myNotifyIcon.Visible = true;
System.Windows.Forms.Application.Run();
});
notifyThread.Start();
}
in Program.cs change the Attribute [STAThread] to [MTAThread]
I've googled this problem for the past week, it's killing my peace! Please help... EventArrivedEventHandler is stuck in a loop, and if I stop it, then it won't catch events. But when I use a handler method, the thread is still concentrating on the loop, and won't give attention to the new form I'm trying to make in the handler! Strange thing is, if I just use something small, like a MessageBox, it doesn't cause an issue, just trying to instantiate a form causes the buttons to NOT draw. Then shortly after the program stops responding. In case you're wondering where the form code is, it's just a standard form made by .NET, that works everywhere else in the code except for in the event handler.
Thanks!
class MainClass
{
public static void Main()
{
TaskIcon taskbarIcon;
EventWatch myWatcher;
taskbarIcon = new TaskIcon();
taskbarIcon.Show();
myWatcher = new EventWatch();
myWatcher.Start();
Application.Run();
}
}
public class TaskIcon
{
public void Show()
{
NotifyIcon notifyIcon1 = new NotifyIcon();
ContextMenu contextMenu1 = new ContextMenu();
MenuItem menuItem1 = new MenuItem();
MenuItem menuItem2 = new MenuItem();
contextMenu1.MenuItems.AddRange(new MenuItem[] { menuItem1, menuItem2 });
menuItem1.Index = 0;
menuItem1.Text = "Settings";
menuItem1.Click += new EventHandler(notifyIconClickSettings);
menuItem2.Index = 1;
menuItem2.Text = "Exit";
menuItem2.Click += new EventHandler(notifyIconClickExit);
notifyIcon1.Icon = new Icon("app.ico");
notifyIcon1.Text = "Print Andy";
notifyIcon1.ContextMenu = contextMenu1;
notifyIcon1.Visible = true;
}
private static void notifyIconClickSettings(object Sender, EventArgs e)
{
MessageBox.Show("Settings Here");
}
private static void notifyIconClickExit(object Sender, EventArgs e)
{
//taskbarIcon.Visible = false; // BONUS QUESTION: Why can't I hide the tray icon before exiting?
Application.Exit();
}
}
public class EventWatch
{
public void Start()
{
string thisUser = WindowsIdentity.GetCurrent().Name.Split('\\')[1];
WqlEventQuery query = new WqlEventQuery();
query.EventClassName = "__InstanceCreationEvent";
query.Condition = #"TargetInstance ISA 'Win32_PrintJob'";
query.WithinInterval = new TimeSpan(0, 0, 0, 0, 1);
ManagementScope scope = new ManagementScope("root\\CIMV2");
scope.Options.EnablePrivileges = true;
ManagementEventWatcher watcher = new ManagementEventWatcher(scope, query);
watcher.EventArrived += new EventArrivedEventHandler(showPrintingForm);
watcher.Start();
}
void showPrintingForm(object sender, EventArrivedEventArgs e)
{
// MessageBox.Show("This will draw just fine");
Form1 myForm;
myForm = new Form1();
myForm.Show(); // This causes a hangup
}
}
My guess would be that the ManagementEventWatcher calls the EventArrived handler from a different thread than the UI thread. Then your showPrintingForm is executed on that thread and accessing UI from a different thread than the UI thread is bad. You need to marshal your code back onto the UI thread.