Delphi: Reading, writing text files. For Pachube and other

This has good information, and a search button at the bottom of the page

Please don't dismiss it because it isn't full of graphics, scripts, cookies, etc!

This tutorial comes with downloadable sourcecode

More information about the source and format of these pages is available.

This simple little sketch for an application does work. Important techniques are illustrated. The application is "well made", in that it is easy to read, easy to work with.... and why I claim that is explained. It does NOT have all the frills you might want. For instance, it doesn't remember things from execution to execution. If you want to change how often it does the automatic "thing", you have to make a slight change in the code. But even in these areas, the application was written with "good" answers in mind, and could easily be extended. In fact, if you want something to do what this does, elegantly, get in touch... I am working on a commercial version of the program!

The program was written for my real world needs.

For a long time, I have had a system I call FarWatch working in conjunction with another of my programs, DS025, to collect weather information and make it available on the web. As part of that, my computer prepares a small text file, which is re-written as often as I wish. I think I have it set to update every 5 minutes. T he current temperature always appears in line 19 of that file, always starting at the 13th character, e.g. "21.3 C". (The temperature is sometimes expressed in Fahrenheit degrees.) And the code, at 11 Jan 11 is a bit faulty... it will only correctly read the temperature if it is expressed in 6 characters, including the space before the units specifier.. Oops.

ANYWAY... that's what I had when I first met Pachube. Pachube is a cool "YouTube for data steams". I've done a whole page about for you Pachube elsewhere. What we need to know here is that if you put a page like the following....

<?xml version="1.0" encoding="UTF-8"?>
<eeml xmlns="http://www.eeml.org/xsd/005">
  <environment>
    <data id="0">
      <value>36.2</value>
    </data>
  </environment>
</eeml>

... on a server with PHP handling (that's not as hard as it sounds, and you don't need a static IP address), and a way to continually change the "36.2" in the 5th line, then Pachube can be asked to visit that every 15 minutes, collect your data, and make it available to you or anyone else from any internet terminal. (Or, if you want to pay, you can set up a data library that isn't public.)

Don't get too wrapped up in the Pachube stuff... that's explained on another page. This page is a Delphi tutorial, and we'll get to that soon. I just wanted to set the scene for why I wrote the application from which I think you can learn things. This is probably a good time to download the sourcecode of this project, DD086. A copy of the finished .exe is there, too.

So... to recap. This application periodically reads one file, extracts a number from it, and then writes a new file, using the number. It has noting to do xxx with the creation of the file it reads from. The file it writes, it overwrites again and again.

The application does this periodically by means of a timer. There also a button you can click to make the read/extract/write happen on demand, which is useful when you are testing your progress if you choose to modify the application.

There are four edit boxes on the form for specifying the source and destination files. The path to each file is set in one edit box, and the name of the file in the other.

There are two memos on the form, meSource on the left, to hold the file we are collecting our datum from, meOutput on the right for the file we are going to write again and again, changing the number within it that comes from the first file.

The illustration on the right shows you what things would look like after the "Do It" button had been clicked. The 8.0 on the "value" line in the right hand memo derives from the 46.4 near the bottom of the second column in the left hand memo, 8.0 being the Celsius equivalent of 46.4 F.

Application's development and structure

So. How is the application put together?

Start by looking at the DoIt procedure. I put everything I wanted to happen again and again in the DoIt procedure, so that I could invoke it by clicking the button I made for that purpose and the same code could be invoked each time the timer timed out, for "automatic" updates to the output file.

We put the full name (path+file's name) of where we think our source material is be found in "sTmp", and then ask if there is such a file... if fileexists(sTmp), "fileexists" being a built in Delphi function. We'll look at BuildPathPlusFile, which is not a built in function, in a moment.

If the file exists, we then do the following....

meSource.Lines.LoadFromFile(sTmp);
sTmp:=sFetchData;
FillOutputMemo(sTmp);
WriteMemoToFile;

The LoadFromFile method of the Lines property of the meSource memo just goes to the file specified by sTmp, which we filled a moment ago, and copies everything in the file into the memo.

sFetchData is a function I wrote. We'll discuss it in detail in a moment. Suffice it to say here that it fills sTmp with a string representation of the right bit of the source file.

FillOutputMemo merges our datum with the fixed text common to all versions of the output file.

WriteMemoToFile is again written by me, and again we will go into detail in a moment.

At this stage, I hope you can grasp the overall plan and shape of what we are going to do? The details... quite properly... are "hidden" inside the definitions of the parts we have defined by writing the main body of DoIt as we have. this not only keeps "DoIt" readable, but it simplified making changes to the program. Suppose the format of the source of the data changes? You'll only have to make alterations within sFetchData. But not elsewhere. The good "splitting up" of the parts will be much appreciated by anyone... even you... working with this application in the future.

Details of special routines

The function xxx sBuildPathPlusFile takes two parameters, sPath, sName and merely concatenates them: result:=sPath+sName. However, given that the edit boxes we use as the source of what goes to sBuildPathPlusFile are filled in by humans, it might be an idea to validate the proposed filename. Note that this one function is used near the start of the application to put the full path + name information about the sourcefile into a variable, and then the function is used again when we need the full path + name of he output file.

You can look into the code of sFetchData if you wish, or skip over it. (It should, of course, be called sFetchDatum, in its present incarnation. However it may one day return more than one datum from the source file.) The present code makes a flawed assumption, but as long as the temperature stays between 10.0 and 99.9 Fahrenheit, inclusive, all will be well, so, luckily, I am probably okay. And because of the well structured code, it would be easy enough to go into the code and fix it to handle other temperatures. sFetchData returns the temperature in degrees Celsius, regardless of what units it is supplied in. The program which generates the file DD089 reads from can record the temperatures in either units, hence the "C" or "F" supplied with the datum, and hence some of the complexity within sFetchData. (That unit designator is put in sTmp2 early in the function. sTmp starts out being the whole "46.4 F", but is soon chopped down to just the "46.6")

There isn't much error handling in this application, but there is some in sFetchData. If something goes wrong... unexpected data formatting in the file we get the datum from being the most likely explanation... then sFetchData returns 99.9, which the user is expected to recognize as a rogue value, saying "Something is wrong".

During the execution of sFetchData what it will return is passed to a label on the screen, wrapped in "x"s, so that leading or trailing spaces will be evident.

The FillOutput procedure is pretty self evident, especially as the datum we are inserting has already been converted to a string. The procedure first clears the memo, then writes the lines we want to it.

Even though FillOutput... at the moment... is mind-mumbingly dull, by separating out this part of the overall scheme, we have "parceled it up", so that if, for different requirements, the creation of the text for the output file was complex, it would all be in one place, and more easily managed.

The WriteMemoToFile procedure is likewise very simple, thanks to the built-in SaveToFile procedure.

The timer, which "drives" the automatic creation of the output file, over and over again, is simply being used in a very normal way. Each time it times out, "DoIt" is invoked. Forever and ever... amen.

Well... it is late again. I hope that covers it? Don't hesitate to write, if it doesn't! And have a look at the Pachube introduction, and the FarWatch introduction, if you don't already have an internet accessible server in your home. (It really isn't too hard to set one up, for FarWatch or for Pachube.