The reason for this is that I'm on the last furlongs of getting QuSheet finished and I haven't wanted anything to distract me.

Things are likely to be a little quiet here for a couple more weeks until I get QuSheet out to my Beta testers.

Just out of interest, after more or less finishing the development work on QuSheet (I've got about a day's worth of bits to clear up), I still had the following to do:

1) Write all the help text.
2) Sort out installation (using ClickOnce)
3) Sort out activation code so that installations are legitimate
4) Sort out icon and logo
5) Script and write tutorials (still doing this - massive job in lieu of writing user manuals (another massive job))
6) Sort out web-site (to-do)
7) Script and write over-view presentation

Then there's beta testing. I'm hoping I'm not going to get a lot of problems thrown up by this, as I've been quite meticulous testing out all my functionality as I wrote my help text and tutorials.

Time ticks on and I'm rapidly running out funds. I'm pretty confident I'll finish before I run out completely, though then it'll be time to either get some work, funding or quick sales.

All the best

Richard

Database tends to mean two things now: the traditional meaning (a collection of data) and the commercial meaning (an application which manages a collection of data). QuSheet has the former, not the latter. Database commercial packages are only necessary when performance is an issue and you want to leverage some specialist company's expertise in managing large amounts of data in a timely manner (and pay massive licence fees to go with it).

The QuSheet database is editted using the tables and forms which QuSheet itself presents to you (and more about that in another post). It is stored in the file that you load and save from QuSheet using an encoding called XML (with the extension .qus.xml) and you can actually view and edit the XML itself if you want to (or not worry that such a thing as XML exists if you don't).

Since in this case QuSheet database is synonimous with QuSheet file, and database has this double meaning, I'll call it the file from now on. QuSheet's output is also a file, of course - an HTML one in this case (basically the thing you view with your browser). In order to avoid confustion with the file/database I'll call the output file simply the output.

At the top level, the file consists of two things: a single workbook and a number of sheets. For example, if you were sending price quotes to customers, you would put all your pricing information in the workbook and each cusomer would have their own sheet detailing what they wanted to buy. Each sheet generates an output. If you wanted to send out new quotes based on new prices, you would change the pricing information, once, in your workbook, and re-generate all the output.

The alternative to this approach is to have each customer have their own file. This would mean, however, that each file would have its own copy of the pricing information within it, and you could get into all sorts of tangles making sure all of them were kept up to date.

The disadvantage with the multiple-sheet approach, however, is that you can end up with a very large file. In the end its up to you to choose whether you go for many files with one sheet each, one file with many sheets, or some compromise between the two.

Richard

Once upon a time you had printed manuals - generally a User's Guide and a Reference Guide - nicely bound, professionally presented and, I suppose, a pain in the neck to produce (and expensive).

About 12 years ago or so we saw the end of them, and everyone moved on to "electronic" manuals instead. Well, not everyone. Games, I note, are always issued with printed manuals on their first run, only going electronic on their cheaper runs later on (as "platinum" games, or whatever).

Soon after manuals (of professional products, anyway) went electronic, some (!) effort was made to produce an integrated help system - i.e. link the manual to the program. It was primitive: the help system was a separate program that you invoked from your main one, via either a "contents" entry point or a "search" one. One decade later that's still pretty much what we have now.

Having two separate programs means you're inevitably clicking between the two, since both generally want to grab your whole screen, and there's no "context sensitivity" - i.e. the help system having some idea what you want to look up by "asking" your main program what you are up to.

With QuSheet, I decided to produce an integrated context sensitive help system as follows:

Help information is presented in a "panel" (or "pane" in windows terminology) which can be made as large or as small as you like by dragging the bar dividing this panel from the rest main of the program up or down (rather like opening or closing a roller-blind).

The information in this panel depends on what you're doing, first by displaying text relevant to the tab-page you're currently on (QuSheet works on a tab-page system, with tabs within tabs as necessary), second by displaying information relevant to the particular table entry or field that you are editting (viewing or editting in the case of a field, because Windows wont tell me (the programmer) when you are "viewing" a particular entry in a table).

I'm sure it's nothing like as sophisticated as these sort of systems could be, but it has to be a step in the right direction.

Richard