EPPlus-Create advanced Excel spreadsheets on the serverhttp://epplus.codeplex.com/project/feeds/rssEPPlus is a .net library that reads and writes Excel files using the Open Office Xml format (xlsx). Created Unassigned: Calculated Fields in PIVOT [15076]http://epplus.codeplex.com/workitem/15076Hi, we use some versions of your library, 4.0 for fast large plain reports, 3.2 for complex pivots and reports,<br />and for pivot library has very large set of functions, but has no Calculated Fields,<br />another solutions is not so good.<br />I really hope for a speedy addition of this feature, all deadlines is closed to finish.<br />DenisPastukhovMon, 20 Oct 2014 19:57:10 GMTCreated Unassigned: Calculated Fields in PIVOT [15076] 20141020075710PNew Post: Prroblem copying worksheet containing checkboxeshttps://epplus.codeplex.com/discussions/570247<div style="line-height: normal;">Hi,
<br />
I have a problem copying one worksheet to another. The problem is related to my checkbox controls in my worksheet.
<br />
This is what I am trying to do and it works fine when I remove my checkboxes from the excel worksheet.<br />
<pre><code> FileInfo file = new FileInfo(@"C:\File1.xlsx");
FileInfo file2 = new FileInfo(@"C:\File2.xlsx");
ExcelPackage p = new ExcelPackage(file);
ExcelPackage p2 = new ExcelPackage(file2);
p.Workbook.Worksheets.Add("newWorkSheet",p2.Workbook.Worksheets[1]);
Stream s = File.Create(@"C:\File3.xlsx");
p.SaveAs(s);
</code></pre>
This is the error I get when I keep my checkboxes:
<br />
OjbectDisposedException was unhandled, It is not possible to reach a closed data stream.
<br />
<br />
Is it possible to copy a worksheet with these type of controls?<br />
</div>ChrilleeMon, 20 Oct 2014 12:38:29 GMTNew Post: Prroblem copying worksheet containing checkboxes 20141020123829PSource code checked in, #4ac0c465edd5http://epplus.codeplex.com/SourceControl/changeset/4ac0c465edd5Added support for ranges in Hour, Minute and Second functions.swmalMon, 20 Oct 2014 05:20:44 GMTSource code checked in, #4ac0c465edd5 20141020052044ASource code checked in, #fd9e011c0d9fhttp://epplus.codeplex.com/SourceControl/changeset/fd9e011c0d9fFixed issue 15064. Fixed some errors with string parsing for date/time.swmalSun, 19 Oct 2014 22:10:05 GMTSource code checked in, #fd9e011c0d9f 20141019101005PClosed Unassigned: String Concatenation Formula Error [15064]http://epplus.codeplex.com/workitem/15064Using the version 4 Beta, I'm getting incorrect results when using the Calculate method on my worksheet. Below is my example Unit Test code to show the issue. This is the unit test error message, "Assert.AreEqual failed. Expected:<Doe, John>. Actual:<OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo, John>. " It's interesting how it handles John just fine but not Doe. I'd assume it's due to the order of the expression compilation.<br /><br />I greatly appreciate the work put into this library. I wish I could figure this bug out myself but when stepping through the debugger I couldn't get my head around all that was going on. Thanks.<br /><br />```<br />[TestMethod]<br />public void Calculation5()<br />{<br />	var pck = new ExcelPackage();<br />	var ws = pck.Workbook.Worksheets.Add("Calc1");<br />	ws.Cells["A1"].Value = "John";<br />	ws.Cells["B1"].Value = "Doe";<br />	ws.Cells["C1"].Formula = "B1&\", \"&A1";<br />	ws.Calculate();<br />	Assert.AreEqual("Doe, John", ws.Cells["C1"].Value);<br />}<br />```<br /><br />Well, turns out I was able to figure out what the issue was. If the formula started with an ExcelAddressExpression it was immediately converted to a StringExpression in the StringConcatStrategy.Compile method which shouldn't happen for an ExcelAddressExpression as the value it will return is OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo. The fix was just to change the line in the StringConcatStrategy.Compile method from<br />```<br />var newExp = ExpressionConverter.Instance.ToStringExpression(_expression);<br />```<br /><br />to<br />```<br />var newExp = _expression is ExcelAddressExpression ? _expression : ExpressionConverter.Instance.ToStringExpression(_expression);<br />```<br />Comments: Thank you very much! Really appreciated when failing tests are provided with an issue! /MAswmalSun, 19 Oct 2014 22:04:45 GMTClosed Unassigned: String Concatenation Formula Error [15064] 20141019100445PEdited Unassigned: String Concatenation Formula Error [15064]http://epplus.codeplex.com/workitem/15064Using the version 4 Beta, I'm getting incorrect results when using the Calculate method on my worksheet. Below is my example Unit Test code to show the issue. This is the unit test error message, "Assert.AreEqual failed. Expected:<Doe, John>. Actual:<OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo, John>. " It's interesting how it handles John just fine but not Doe. I'd assume it's due to the order of the expression compilation.<br /><br />I greatly appreciate the work put into this library. I wish I could figure this bug out myself but when stepping through the debugger I couldn't get my head around all that was going on. Thanks.<br /><br />```<br />[TestMethod]<br />public void Calculation5()<br />{<br />	var pck = new ExcelPackage();<br />	var ws = pck.Workbook.Worksheets.Add("Calc1");<br />	ws.Cells["A1"].Value = "John";<br />	ws.Cells["B1"].Value = "Doe";<br />	ws.Cells["C1"].Formula = "B1&\", \"&A1";<br />	ws.Calculate();<br />	Assert.AreEqual("Doe, John", ws.Cells["C1"].Value);<br />}<br />```<br /><br />Well, turns out I was able to figure out what the issue was. If the formula started with an ExcelAddressExpression it was immediately converted to a StringExpression in the StringConcatStrategy.Compile method which shouldn't happen for an ExcelAddressExpression as the value it will return is OfficeOpenXml.FormulaParsing.EpplusExcelDataProvider+RangeInfo. The fix was just to change the line in the StringConcatStrategy.Compile method from<br />```<br />var newExp = ExpressionConverter.Instance.ToStringExpression(_expression);<br />```<br /><br />to<br />```<br />var newExp = _expression is ExcelAddressExpression ? _expression : ExpressionConverter.Instance.ToStringExpression(_expression);<br />```<br />swmalSun, 19 Oct 2014 21:35:25 GMTEdited Unassigned: String Concatenation Formula Error [15064] 20141019093525PClosed Issue: Calculation Error With ExcelAddressExpression [15067]http://epplus.codeplex.com/workitem/15067Given the following unit test the calculation results in an incorrect value.<br /><br />```<br />[TestMethod]<br />public void Calculation7()<br />{<br />	var pck = new ExcelPackage();<br />	var ws = pck.Workbook.Worksheets.Add("Calc1");<br />	ws.Cells["A1"].Value = "Y";<br />	ws.Cells["B1"].Formula = "IF(A1=\"Y\",\"1\",\"2\")";<br />	ws.Cells["B1"].Calculate();<br />	Assert.AreEqual("1", ws.Cells["B1"].Value);<br />}<br />```<br /><br />I tracked the issue down to the Operator method Compare(CompileResult l, CompileResult r) at the end of the function the CompareString line should be changed from.<br /><br />```<br />return CompareString(l.Result, r.Result);<br />```<br /><br />to<br />```<br />return CompareString(left, right);<br />```<br />Comments: Closed/MAswmalSun, 19 Oct 2014 21:33:58 GMTClosed Issue: Calculation Error With ExcelAddressExpression [15067] 20141019093358PSource code checked in, #92877a1e5774http://epplus.codeplex.com/SourceControl/changeset/92877a1e5774Fixed issue 15072: error when handling excel addresses in some date functions.swmalSun, 19 Oct 2014 21:33:32 GMTSource code checked in, #92877a1e5774 20141019093332PClosed Issue: Calculation Error With Excel Address [15072]http://epplus.codeplex.com/workitem/15072When trying to calculate a formula as simple as "YEAR(A1)" where A1 is filled with a date time, the calculation fails.<br />Comments: Thanks. /MAswmalSun, 19 Oct 2014 21:28:29 GMTClosed Issue: Calculation Error With Excel Address [15072] 20141019092829PEdited Issue: Calculation Error With Excel Address [15072]http://epplus.codeplex.com/workitem/15072When trying to calculate a formula as simple as "YEAR(A1)" where A1 is filled with a date time, the calculation fails.<br />swmalSun, 19 Oct 2014 21:28:04 GMTEdited Issue: Calculation Error With Excel Address [15072] 20141019092804PSource code checked in, #387d096e9f99http://epplus.codeplex.com/SourceControl/changeset/387d096e9f99Bugfix related to issue 15073: Dates on CompileResult now counts as numeric values.swmalSun, 19 Oct 2014 21:08:24 GMTSource code checked in, #387d096e9f99 20141019090824PClosed Unassigned: In Beta 4, formulas containing the "<>" operator are not parsed correctly [15073]http://epplus.codeplex.com/workitem/15073My Excel spreadsheet contains a Date in column A and the following formula in column B.<br />```<br />=IF([@IssueDate]<>"",TODAY()-[@IssueDate],"")<br /><br />```<br />When the 'Compute' method is called, the result '#VALUE!' is assigned to column B rather than the proper value. <br /><br />The error appears to be occurring because the not equal operator "<>" is not recognized by the parser. The problem appears to be in method 'Init' at line 49 in file 'TokenSeparatorProvider.cs'. It does not include token "<>" in the '_tokens' dictionary. In addition, method 'IsPossibleLastPartOfMultipleCharOperator' may need to be updated to say "return (part == "=" || part == ">");".<br /><br />There is a second issue regarding Date values in arithmetic expressions that prevents the expression from begin evaluated correctly. I will submit that issue in a separate bug report.<br /><br />I have attached a simple spread sheet that reproduces this problem.<br />Comments: Closed /MAswmalSun, 19 Oct 2014 21:08:02 GMTClosed Unassigned: In Beta 4, formulas containing the "<>" operator are not parsed correctly [15073] 20141019090802PClosed Issue: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074]http://epplus.codeplex.com/workitem/15074My Excel spreadsheet contains a Date in column A and the following formula in column B.<br /><br />```<br />=IF([@IssueDate]<>"",TODAY()-[@IssueDate],"")<br />```<br /><br />When the 'Compute' method is called, the result '#VALUE!' is assigned to column B rather than the proper value.<br /><br />I was able to circumvent the problem by updating the arithmetic operator methods in file "Operator.cs" to support "DataType.Date'. I also updated "ExpressionConverter.cs" to handle "DataType.Date". Finally, I updated "DateExpression.cs". I have no confidence I made these changes correctly; I only mention this in the remote chance it might be helpful.<br /><br />There is a second issue regarding Date values in arithmetic expressions that prevents the "<>" operator from begin parsed correctly. I submitted that issue in bug report 15073.<br /><br />I have attached a simple spread sheet that reproduces this problem.<br /><br /><br />Comments: closed /MAswmalSun, 19 Oct 2014 21:07:30 GMTClosed Issue: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074] 20141019090730PCommented Issue: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074]http://epplus.codeplex.com/workitem/15074My Excel spreadsheet contains a Date in column A and the following formula in column B.<br /><br />```<br />=IF([@IssueDate]<>"",TODAY()-[@IssueDate],"")<br />```<br /><br />When the 'Compute' method is called, the result '#VALUE!' is assigned to column B rather than the proper value.<br /><br />I was able to circumvent the problem by updating the arithmetic operator methods in file "Operator.cs" to support "DataType.Date'. I also updated "ExpressionConverter.cs" to handle "DataType.Date". Finally, I updated "DateExpression.cs". I have no confidence I made these changes correctly; I only mention this in the remote chance it might be helpful.<br /><br />There is a second issue regarding Date values in arithmetic expressions that prevents the "<>" operator from begin parsed correctly. I submitted that issue in bug report 15073.<br /><br />I have attached a simple spread sheet that reproduces this problem.<br /><br /><br />Comments: Hi Philip, thank you for a good description of the error and for taking the time to provide sample data. I have fixed the issues you have added by implementing the <> operator and changed the CompileResult class so that dates counts as numeric values. Cheers, MatsswmalSun, 19 Oct 2014 21:07:04 GMTCommented Issue: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074] 20141019090704PEdited Issue: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074]http://epplus.codeplex.com/workitem/15074My Excel spreadsheet contains a Date in column A and the following formula in column B.<br /><br />```<br />=IF([@IssueDate]<>"",TODAY()-[@IssueDate],"")<br />```<br /><br />When the 'Compute' method is called, the result '#VALUE!' is assigned to column B rather than the proper value.<br /><br />I was able to circumvent the problem by updating the arithmetic operator methods in file "Operator.cs" to support "DataType.Date'. I also updated "ExpressionConverter.cs" to handle "DataType.Date". Finally, I updated "DateExpression.cs". I have no confidence I made these changes correctly; I only mention this in the remote chance it might be helpful.<br /><br />There is a second issue regarding Date values in arithmetic expressions that prevents the "<>" operator from begin parsed correctly. I submitted that issue in bug report 15073.<br /><br />I have attached a simple spread sheet that reproduces this problem.<br /><br /><br />swmalSun, 19 Oct 2014 21:07:04 GMTEdited Issue: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074] 20141019090704PSource code checked in, #dfe9953baa28http://epplus.codeplex.com/SourceControl/changeset/dfe9953baa28Fixed broken tests by making Reset() on ExcelDataProvider public instead of internal. Fixed issue 15073 (Operator <> missing).swmalSun, 19 Oct 2014 20:26:29 GMTSource code checked in, #dfe9953baa28 20141019082629PCreated Unassigned: Autofit columns doesn't work with columns whit format [15075]http://epplus.codeplex.com/workitem/15075Hi.<br /><br />I use this code to fit the columns:<br /><br />```<br />ws.Cells(ws.Dimension.Address).Worksheet.DefaultColWidth = 1<br />ws.Cells(ws.Dimension.Address).AutoFitColumns()<br />```<br /><br />If I don't use DefaultColWidth the columns are TOO big.<br />If I use it, the columns are too small for the columns with cells with format Number.<br /><br />You can see the problem in the attached samples.<br />RumpelstinskSat, 18 Oct 2014 09:17:25 GMTCreated Unassigned: Autofit columns doesn't work with columns whit format [15075] 20141018091725ACreated Unassigned: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074]http://epplus.codeplex.com/workitem/15074My Excel spreadsheet contains a Date in column A and the following formula in column B.<br /><br />```<br />=IF([@IssueDate]<>"",TODAY()-[@IssueDate],"")<br />```<br /><br />When the 'Compute' method is called, the result '#VALUE!' is assigned to column B rather than the proper value.<br /><br />I was able to circumvent the problem by updating the arithmetic operator methods in file "Operator.cs" to support "DataType.Date'. I also updated "ExpressionConverter.cs" to handle "DataType.Date". Finally, I updated "DateExpression.cs". I have no confidence I made these changes correctly; I only mention this in the remote chance it might be helpful.<br /><br />There is a second issue regarding Date values in arithmetic expressions that prevents the "<>" operator from begin parsed correctly. I submitted that issue in bug report 15073.<br /><br />I have attached a simple spread sheet that reproduces this problem.<br /><br /><br />PhilipLGarrettThu, 16 Oct 2014 06:15:25 GMTCreated Unassigned: In Beta 4, formulas including Dates may return "#VALUE!" rather than the proper value. [15074] 20141016061525ACreated Unassigned: In Beta 4, formulas containing the "<>" operator are not parsed correctly [15073]http://epplus.codeplex.com/workitem/15073My Excel spreadsheet contains a Date in column A and the following formula in column B.<br />```<br />=IF([@IssueDate]<>"",TODAY()-[@IssueDate],"")<br /><br />```<br />When the 'Compute' method is called, the result '#VALUE!' is assigned to column B rather than the proper value. <br /><br />The error appears to be occurring because the not equal operator "<>" is not recognized by the parser. The problem appears to be in method 'Init' at line 49 in file 'TokenSeparatorProvider.cs'. It does not include token "<>" in the '_tokens' dictionary. In addition, method 'IsPossibleLastPartOfMultipleCharOperator' may need to be updated to say "return (part == "=" || part == ">");".<br /><br />There is a second issue regarding Date values in arithmetic expressions that prevents the expression from begin evaluated correctly. I will submit that issue in a separate bug report.<br /><br />I have attached a simple spread sheet that reproduces this problem.<br />PhilipLGarrettThu, 16 Oct 2014 05:55:04 GMTCreated Unassigned: In Beta 4, formulas containing the "<>" operator are not parsed correctly [15073] 20141016055504ACreated Unassigned: Calculation Error With Excel Address [15072]http://epplus.codeplex.com/workitem/15072When trying to calculate a formula as simple as "YEAR(A1)" where A1 is filled with a date time, the calculation fails.<br />Tydude4ChristWed, 15 Oct 2014 20:51:35 GMTCreated Unassigned: Calculation Error With Excel Address [15072] 20141015085135P