Description: ------------ When outputting a spreadsheet with many worksheets, supplying a worksheet name to the addWorksheet() method on any worksheet other than the first causes the error: Fatal error: Call to undefined function: write() in <path to PHP script> on line <line number of write() call> This is a large (>200KB) spreadsheet with 25 worksheets. I am using the latest PEAR, Excel_Spreadsheet_Writer and required/dependent classes. Reproduce code: --------------- Using this code works as expected: $workbook = new Spreadsheet_Excel_Writer( "my_file.xls" ); $worksheet =& $workbook->addWorksheet( "My first worksheet" ); for( $i = 0; $i < 300; $i++ ) { $worksheet->write( $row, $column, "My stuff " . $i ); } $worksheet =& $workbook->addWorksheet(); for( $i = 0; $i < 300; $i++ ) { $worksheet->write( $row, $column, "My other stuff " . $i ); } $workbook->close(); This produces the error: $workbook = new Spreadsheet_Excel_Writer( "my_file.xls" ); $worksheet =& $workbook->addWorksheet( "My first worksheet" ); for( $i = 0; $i < 300; $i++ ) { $worksheet->write( $row, $column, "My stuff " . $i ); } $worksheet =& $workbook->addWorksheet( "My second worksheet" ); for( $i = 0; $i < 300; $i++ ) { $worksheet->write( $row, $column, "My other stuff " . $i ); } $workbook->close(); Expected result: ---------------- Expect a spreadsheet to output. Actual result: -------------- Output to browser or stdout: Fatal error: Call to undefined function: write() in <path to PHP script> on line <line number of write() call>

I was experiencing this same error and it turned out to fail with this same error when it tried to create a worksheet with > 31 characters in the name. (We were also not handling the error sent by the module correctly)

The problem with the spreadsheet writer is that the throwError attempts on lines 325 and 333 are failing. The "real" bug is that throwError() is failing and the returned error indicates that the worksheet object is being destroyed silently, thus the "call to undefined function: write()" error. Regardless, throwing an error and exiting is not a graceful way of handling the problems this is trying to handle. The problems can be fixed programatically. Change line 325 to this: $name = substr( $name, 0, 30 ); change line 333 to this: $name = substr( $name, 0, 27 ) . ($index+1); As long as either throwError is failing or calls to it are avoided as outlined above, this is still an active bug in the code.

I should mention that the bug is in Workbook.php

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. fixed the docs, so that it mentions the method may return an Error object. Should be updated on the pear site soon.

Why update the documentation to mention that it may return an Error object rather than change the 2 lines of code as given below to avoid errors altogether? If you want the option to be able to throw an error, at the *very* least, you should give users the choice to throw an error or try to automatically fix the problem (perhaps with an added input parameter that defaults to the automatic fix option). This should be handled more intelligently, and the vast majority of people who are using this code are going to prefer that the problem be fixed automatically rather than being forced to handle it themselves. I would understand the hesitance if this were a big, kludgy change, but it is literally only changing 2 lines of code. Think logically about what you're asking programmers to do - either: a) Force extra checking of everything that could be used for a worksheet name and look for duplicates or too many characters - presumably program a fix for all such cases, or: b) Every time the addWorksheet method is called, check the return value to make sure it isn't an Error object, and if so, handle it (which is probably going to mean figuring out a new name for the worksheet anyway). This could all be avoided by altering 2 lines of code in the base class. Is there some compelling reason why you would not want to implement the easy solution rather than simply updating the documentation, which does not really fix anything?

> Why update the documentation to mention that it may return > an Error object rather than change the 2 lines of code as > given below to avoiderrors altogether? Because it would change current behaviour.