EventArgs Example

Company | Articles & Research | Services | Software |

Our Company

All SharePoint Articles

Security

Development

Accounting / Dynamics

AIS / Dynamics GP

Other

Consulting Services

Freeware / Experiments

Applications	WebParts	Security Components
SharePoint Field Diff And Copy Utility * Written In January, 2012 SharePoint Security Scanner * Written In January, 2012 SharePoint Kerberos Buddy * Written In Feburary, 2011 BioPoint: SharePoint Biometric Authentication * Written In September, 2007 SharePoint List Security Migrator * Written In August, 2007 SharePoint Anti-Keylogger™ * Written In April, 2006 S.M.A.R.T SharePoint™ * Written In May, 2006 SharePoint Sentinel™ * Written In June, 2006 SharePoint Scrubber™ * Written In July, 2006 SharePoint Safeguard™ * Written In August, 2006	SecureSilverlight For SharePoint * Written In January, 2010 Simple Rollup WebPart For SharePoint * Written In Novemember, 2009 SimpleChart For SharePoint * Written In December, 2009 SimpleSecurity For SharePoint * Written In June, 2009 CrytoCollaboration (Encryption) * Written In June, 2007 Sample AJAX Rotator WebPart * Written In July, 2007 Sample SharePoint Redirector WebPart * Written In August, 2006 WFE Server Name WebPart * Written In January, 2006	PDF IRM Protector * Written In December, 2010 ADAM Role Provider * Written In February, 2007 Universal Provider Framework * Written In April, 2007

Contact

In one my past posts, I talked about that CryptoCollaboration using the EventArgs base class because it keeps things nice and generalized, allowing for expanasion for the handling of future event integration. A person emailed me and asked for a practical example of when would use such a thing in a SharePoint WebPart. Eh, ok.

I am going to use an example of a progress class, that, well, as you can guess will display the progress of some sort of execution that happens with a SharePoint WebPart.

The first class is the Process Arguments class (ProcessArgs), that inherits from the EventArgs base class.

PLAIN TEXT

C#:

public class ProgressArgs : EventArgs
{
private int m_nPercentageComplete = 0;
private DataRow m_oDataRow;
public ProgressArgs(DataRow dataRow, int percentageComplete)
{
this.m_oDataRow = dataRow;
this.m_nPercentageComplete = percentageComplete;
}
public DataRow CurrentDataRow
{
get
{
return this.m_oDataRow;
}
}
public int PercentageComplete
{
get
{
return this.m_nPercentageComplete;
}
}
}

In the next class, there will be the establishment of the event handler that will be called from a sister class by use of a delegate.

PLAIN TEXT

C#:

public delegate void ProgressEventHandler(object sender, ProgressArgs e);

Now that the delegate is established, you can call it in some general class file.

PLAIN TEXT

C#:

public event ProgressEventHandler ProgressEvent;
protected virtual void OnProgress(ProgressArgs e)
{
if (this.ProgressEvent != null)
{
this.ProgressEvent(this, e);
}
}

Then calculate out the progress.

PLAIN TEXT

C#:

ProgressArgs e = new ProgressArgs(row, (int) ((((double) num) / ((double) this.DBDataTable.Rows.Count)) * 100));
this.OnProgress(e);

I am not saying that this is the only way to do it, but with applications that you plan on extending later it is the route that I have choosen to go in the past. I may at some point explore the deficiencies in a such an approach, however at this current time I just want to finish the damn thing.