In my dll I expose an event like so:
public delegate void LogMsgEventHandler(object sender, LogEventArgs e);
public event LogMsgEventHandler newLogMessage;
public class LogEventArgs : EventArgs
{
public string logMsg;
}
protected virtual void OnChanged(LogEventArgs e)
{
if (newLogMessage != null)
newLogMessage(this, e);
}
The various methods fire the event to log operation details. On my main form that uses the dll I output any log msgs to a listbox:
slotUtil.newLogMessage += new slotUtils.LogMsgEventHandler(slotUtil_newLogMessage);
..
void slotUtil_newLogMessage(object sender, slotUtils.LogEventArgs e)
{
lbDebug.Items.Add(e.logMsg);
}
The problem is if the logging event is fired too rapidly, the form freezes up. I assume this is a threading problem? How can I fix this design where the form updates fluidly? Is this a bad design? My alternate design id was too store all logging in a private string in the dll and then only dump the log when a particular method is called. Thoughts?
Thanks!
It is not a Threading issue if instances of classes from your dll aren’t in another thread. The event handler
executes in the same thread where it is registered.
So if your instances are in the UI thread this event handler is executing in the UI thread also. It adds new item to the ListBox which triggers new listbox redraw. If events are firing faster than the drawing occurs, then event handlers will pile up in a queue waiting for Invalidates to finish. If this is the case you should try to, at least do something like this:
The adding of the items to the listbox will happen either when five logs are ready or a second has elapsed after last log. You can add whatever number of logs in the array (just change it’s size) before they are added to the listbox.