Hey there! Thanks for your interest in SpreadsheetLight!
Before we continue, I want to clear something up. SpreadsheetLight is designed with the end developer in mind. Sort of like the end user, but development-wise. It is designed for developers to create/manipulate spreadsheets in the easiest manner possible. So convenience is emphasised over power.
SpreadsheetLight is especially designed for…
The poor sod is in the office. Alone. On a Sunday. At 10:27pm.
A box of half-eaten pizza lies on the table in the cubicle next to him. The coffee in his cup has long gone cold. There was a half-hearted attempt at trying to clean off the coffee stains from his paper documents when he spilled the coffee an hour ago. Or was it 3 hours ago?
He had already unbuttoned the top 3 buttons of his shirt. Due to energy conservation efforts of his company, the air conditioning is turned off during non-working hours. Luckily, he had the foresight to bring a portable electric fan.
Our man is currently bent over with his head on the desk, making small groans. He straightens and sits back on his chair. His eyes are bloodshot. He hadn’t slept properly in 5 days.
He looks to the right of his computer screen, where he placed a photo of him, his wife and their newborn baby daughter. His lower lip trembles just a little bit. His shoulders jerk just a little bit. He just wants to go home, take a hot shower, kiss his wife and hold his daughter.
“It’s a freakin’ Sunday!” he shouts into the empty office. I mean, it’s not like he’s disturbing anyone, right?
He sits back down and stares at the code again. Where’s the bug? How can he solve it? “Why is this happening to me?” he mumbles.
After a few minutes of thinking, “That’s it!” he shouts. He types furiously. He compiles. He runs the program. He tests it.
“It works!” he shouts.
He was doing a happy dance when he remembered that he needed to generate a spreadsheet from that data.
He said something that’s generally considered inappropriate in some social situations.
Our man is not a happy camper right now. He doesn’t want to learn how to use some third party library. He wants to go home. He doesn’t care about “proper” programming practices. He wants to go home. He doesn’t care if you tell him it’s easy to create the spreadsheets.
“It’d better be!” he shouts at you. While showing a gesture that’s generally considered impolite. While telling you to do something that’s anatomically difficult. Oh yeah, and he wants to go home.
And with that in mind, SpreadsheetLight basically takes visually oriented spreadsheet software such as Microsoft Excel and LibreOffice Calc and translates the graphical user interface into programming interface.
So that’s the vision. And with that…
I’m not an egotistical arrogant jerk…
If you want to contribute to the development of SpreadsheetLight, first I want to thank you! Then because of the aforementioned vision, I would rather you not help with the source code development thingie.
The reason is that after working on the code, I’ve found that I need to expose interfaces such as methods and properties in a developer-friendly manner. This means strict control over method signatures, and even naming of methods and properties. There are various other reasons but I’m too lazy to explain them…
This means while SpreadsheetLight is open source, I don’t encourage open collaboration. At least not in the sense that you’re familiar with on websites such as CodePlex or GitHub.
Perhaps you discovered a way of writing the code that’s efficient. At least to you. I might not be able to incorporate your code because it either violates the developer-friendly thing, or that I can come up with a better solution, or that it might even be totally unnecessary.
I still welcome code submissions. But I suggest you not spend too much time and effort on it. Contact me first if you’d like.
This doesn’t sound like something you like? I’m sorry. SpreadsheetLight is open source. You’re welcome to make your own forked version.
So what can you do to contribute?
How you can help
- Feature suggestions. If it isn’t hard and/or you really want to help, you can submit code, but see above.
- Bug fixes. Find a bug? Report it.
- Quality testing. If you find some method or property awkward or confusing to use, let me know.
- Spread the word. Tell a friend, other developers, a stranger on the street.
- Donate if you like.
How to compile the source code
I’ve had emails asking for the Visual Studio .csproj project file. I’ve never really understood why. There are a few reasons why I didn’t include it, and I’m too lazy to explain them here. Ok, maybe I’ll explain it a little bit…
But finally through one particular email, I’ve found that people might have difficulty knowing which references to add. Aaahhhh…
Here’s how. Create your own (Visual Studio?) solution/project and add these references:
- DocumentFormat.OpenXml (from the Open XML SDK)
Then drag and drop everything in the source code folder into your project. Compile. Have tea.
Version 3.4.5 onwards works with Open XML SDK 2.5, which runs on .NET Framework 4.0, so you’ll have to target that.
Also, make sure to target the .NET Framework 3.5. Microsoft introduced the System.Tuple class in .NET Framework 4.0, so compiling the source code for .NET Framework 4.0 (this is getting very long to type) will throw out errors.
“What’s this rubbish? I hate Hungarian notation!”
If you’ve looked at the source code, you might find the internal variable names looking similar to Hungarian notation. It’s not. Or at least I’m not using it as such.
Fire up Visual Studio. Type “i”. You should find a list of possible variable names and method names beginning with “i”. That’s the reason.
It’s a Visual Studio typing aid. I remember my variables by the type, so I just type “i” to access my integral variables (ints and shorts). I have floats and doubles prepended with “f”.
Disgusted with “outdated” programming practices in the source code? Open source, MIT License, make your own fork.
Keep in mind that the source code was never meant to be read. The intended audience of SpreadsheetLight is a developer who needs a spreadsheet software solution and doesn’t have time to learn how to use it (much less read the underlying source code). I write the source code as legibly as possible, but making it easy to read or even keeping up with current programming practices isn’t the priority.
So how do we speed up the learning curve? By transferring knowledge of how to use Microsoft Excel over. Hence the similarity between Excel user interface and the exposed programming interface.
“It’s not object oriented! What’s going on?”
SpreadsheetLight is not meant to be used like an object oriented library/component. It’s meant to be used as if you’re using Excel.
In an object oriented environment, you’d need to know that the cell (if you even know that’s the term) is part of the worksheet, which is part of the workbook. And then you work backwards, doing workbook.worksheet[“Sheet1″].cell(1,1) to do anything.
In contrast, SpreadsheetLight just lets you access the cell like sl.SetCellValue(1,1,”access”).
Because the Excel user doesn’t even think about the workbook-worksheet-cell relation. She just types in the value. Academically speaking she’ll understand the relation, but she doesn’t think like that when she’s doing her work. And neither should you.
And because making spreadsheets typically aren’t because you want to, but because upper management wants to, then it’s best to make the programming interface as familiar as possible.
You really think your manager is going to give you project requirements in terms of workbook.worksheet[“Sheet1”].cell(1,1)?
He’d tell you he wants that profit revenue number in cell A1. You’re supposed to figure out how to do that.
Microsoft spent millions of dollars on user testing and hundreds of developer man hours on Excel. I’m just making use of that so that you have an easy time.