You can use a library called ExcelLibrary. It's a free, open source library posted on Google Code:
ExcelLibrary
This looks to be a port of the PHP ExcelWriter that you mentioned above. It will not write to the new .xlsx format yet, but they are working on adding that functionality in.
It's very simple, small and easy to use. Plus it has a DataSetHelper that lets you use DataSets and DataTables to easily work with Excel data.
ExcelLibrary seems to still only work for the older Excel format (.xls files), but may be adding support in the future for newer 2007/2010 formats.
You can also use EPPlus, which works only for Excel 2007/2010 format files (.xlsx files). There's also NPOI which works with both.
There are a few known bugs with each library as noted in the comments. In all, EPPlus seems to be the best choice as time goes on. It seems to be more actively updated and documented as well.
Also, as noted by @АртёмЦарионов below, EPPlus has support for Pivot Tables and ExcelLibrary may have some support (Pivot table issue in ExcelLibrary)
Here are a couple links for quick reference:
ExcelLibrary - GNU Lesser GPL
EPPlus - GNU (LGPL) - No longer maintained
EPPlus 5 - Polyform Noncommercial - Starting May 2020
NPOI - Apache License
Here some example code for ExcelLibrary:
Here is an example taking data from a database and creating a workbook from it. Note that the ExcelLibrary code is the single line at the bottom:
//Create the data set and table
DataSet ds = new DataSet("New_DataSet");
DataTable dt = new DataTable("New_DataTable");
//Set the locale for each
ds.Locale = System.Threading.Thread.CurrentThread.CurrentCulture;
dt.Locale = System.Threading.Thread.CurrentThread.CurrentCulture;
//Open a DB connection (in this example with OleDB)
OleDbConnection con = new OleDbConnection(dbConnectionString);
con.Open();
//Create a query and fill the data table with the data from the DB
string sql = "SELECT Whatever FROM MyDBTable;";
OleDbCommand cmd = new OleDbCommand(sql, con);
OleDbDataAdapter adptr = new OleDbDataAdapter();
adptr.SelectCommand = cmd;
adptr.Fill(dt);
con.Close();
//Add the table to the data set
ds.Tables.Add(dt);
//Here's the easy part. Create the Excel worksheet from the data set
ExcelLibrary.DataSetHelper.CreateWorkbook("MyExcelFile.xls", ds);
Creating the Excel file is as easy as that. You can also manually create Excel files, but the above functionality is what really impressed me.
You probably forgot to set the form's KeyPreview property to True. Overriding the ProcessCmdKey() method is the generic solution:
protected override bool ProcessCmdKey(ref Message msg, Keys keyData) {
if (keyData == (Keys.Control | Keys.F)) {
MessageBox.Show("What the Ctrl+F?");
return true;
}
return base.ProcessCmdKey(ref msg, keyData);
}
Best Answer
In answer to the question of keyboard chords specifically, I do not believe there is a ready-made option available to you at this point.
However, it should be simple enough to model. I would create a single class, perhaps
KeyboardChordProvider. It will need to know about keyboard events at the form level. As stated elsewhere, theForm.KeyPreviewproperty must betrue. It may be enough for this provider to subscribe to theForm.KeyPressevent. You could do all of this in the provider's constructor if you passed in the form.You would need to register the potential keystrokes with the provider.
Internally this instance will track the current state. Whenever a keystroke is observed that represents the first key of the chord, you would update the provider's state and raise an event so that a subscriber could set text: (CTRL+W) was pressed. Waiting for second key of chord...
If the next keystroke matches a potential secondary option, then you have a match and could raise a
ChordPressedevent containing the details of the strokes entered. Alternatively, you might just call a particular callback that was given to the provider at the time the chord was registered (to avoid having a switch statement or some other dispatch in theChordPressedevent handler).If, at any time, a keystroke does not match a potential next option, then you would reset the state of the provider.
Internal to the provider you might model the possible keystrokes using a tree structure. The current state of the provider is just a particular tree node. At the beginning, the root node would be active. If a child matches a keystroke then it becomes the current node in anticipation of the next stroke. If the child was a leaf node, then an entire chord has matched and you would raise
ChordPressedevent (passing the chain of strokes that got you to that point) or invoke the callback stored in the leaf. Whenever no keystroke matches a child, reset back to making the root node active.I think this design would achieve what you want.