Sanity checks

So, since i have (currently) 5 working and 1 WIP DLL for the backup system, and since four of these share the exact same interface,, i thought it would be a proverbial Good Idea (tm) to force compliance - force the signature of all exported functions to conform to a predefined type.

Let me explain. I can have a function called MyFunc, it looks like this: function MyFunc(inP: Integer) : String;

so it takes an integer and returns a string. Why not.

What I wanted to do was define a type : type TMyFunc = function(inP: Integer) : String;

then define the real functions in each DLL as conforming to the type TMyFunc. That way if I change the definition of TMyFunc, the compiler will let me know because the functions are no longer defined correctly.

Well, to cut a long story short, you can't. You cannot define a function according to a type. Which is a bit of a pain really. Wouldn't be useful to very many people I suppose, but in my case, it would have been great.

So to work around this, I did it another way. In the initialization section of the DLL, I now have a little but of code:

var lMyFunc : TMyFunc;
begin
{$HINTS OFF}
  lMyFunc := MyFunc;
end;

(I turn off the hints so that the compiler won't tell me i have a variable to which I assign a value and then never use it).

So I have a variable of type TMyFunc - a variable which is a function. And I assign a real function (MyFunc) to that variable.

Works perfectly, and if I change the definition of TMyFunc (which is in a shared unit), the compiler will complain that "parameter lists differ". I have to do this manually for all exported functions from my DLL, but it is better than nothing!

Now to continue implementing the stuff. Doing this added quite a few items to my TODO list...and doing this wasn't even ON the TODO list! But having a caller fail because the DLL was compiled with an old version of the interface is not really "cool". I prefer to have the compiler tell me, rather than users...

Progress (20190110)

Quick update. Translations for the following modules are done into French (including of course the modifications in the modules to use the translations):

  • Restore (even though this module is not 'finished'
  • ABLocal (save to a local directory)
  • ABS3 (save to amazon S3)
  • ABFTP (save to an ftp site)

I want to make changes to the translation system to have this handled by configdll, right now each module will have its own copy of all the translation texts, which is not ideal. It won't make any difference to the API interface from the caller, though, which is great.

I've also updated the copyright texts in all modules' build configuration to 2019, fixed a couple of cosmetic bugs I found in those (this is stuff I haven't really looked at for ages). Also made a post-build tool file. And discovered that the service module doesn't have a build file, and the trayicon module needs some work.

I now have a fairly good idea of exactly what is in an unfinished state, as well as the functionalities I need to implement. Since this is a glorified TODO list, I'm working through it slowly, but real progress is being made.

Finally

Translation & Restore

In the time the site was offline, I did quite a bit of work on the restore module.

So now, you can choose which files to restore, either the whole of a directory and its subdirectories, or individual files, or a mixture of both. There's a ice Windows Explorer-like display, which also had an icon next to each directory and filename, showing if this particular item is selected for restore. I'm quite happy with how things are turning out, and especially with the performance of the functions - there's quite a lot of work going on in the background for file selection, so it was important that these functions work quickly.

I've also implemented (for the second time...) a translation system. I didn't like any of the "solutions" I could find on the net, nor the inbuilt translation facilities of Delphi, so I devised my own. Translations are held in a simple ini-style file, and one call will load the file for the current system language, and try to translate a whole form. If the current system language is English, then nothing is done, as all texts are natively in English. Additionally, if no translation is available for a language, then the fallback is English. If not, then the system loads the file and tries to translate everything. Of course this means that translations can be added on the fly, and will just be used if available, with no code changes necessary. It also means that the only tool needed to translate the whole of the system is a simple text editor.

And we're back!

Sorry about the absence. The NAS (and hence the site) was in a box in storage for a little longer than originally planned....

in the meantime, however, I've done a LOT of work on AltexaBackup, especially the restore function, which now allows you to properly select files and/or directories for restore, as well as properly updating icons on the screen to let you see what has been selected, or not, or partially (in the case of directory contents).

FDOW work is progressing too, though I've now switched to using DAAD to do this. The learning curve is mostly flat, I just have to work out how the process tables now work differently to PAW.

Gilsoft's PAW

I've been toying with the idea of writing a new text adventure or (Interactive fiction) game for the Spectrum.

With the Spectrum Next about to be released, and the renewed interest in the retro computing scene, plus the discussions I've had with Tim Gilberts (of Gilsoft fame), this is something I think I'd enjoy doing.

So I have an idea for a game, and I think I'll do it as a 128k-only (I recall the jumping-through-hoops I had to do back in the day to get everything to fit in 48k!).

At one point the character will be in an area with lots of buildings which all look the same. I want to be able to generate these "different" locations using only one location, and a couple of flags.

So, here's what I've done so far.

The location

(don't you just love the old Spectrum font)

Some system messages (they are all system messages so that PAW won't print a newline after them - and since they will be stringed together, I don't want the newlines):

A couple of flags: 100 to dictate which letter (A to F) and 101 for the number (0 to 9)

An entry in the response table

An entry in process 1 (so it will happen every turn)

And a whole process table - process 3 - to handle the different 'locations'

And when you run the adventure (Note: i've only implemented 'north' here, and only done the messages for rooms A and B, so after a while it doesn't print out the letter, and doesn't print the numbers at all, but you can see the principle)

Keep going north a few times, and eventually (here you can see PAW's diagnostics, showing the value of flag 100)

Looks promising to me! Even in a 128k adventure, space it at its premium, so you have to be frugal. In this way, you can have a nice matrix of 6 * 9 rooms, all for the cost of one location text, 16 system messages, two flags, and a handful of process and response table entries. Of course, I'll be spicing things up a bit, but in the ten minutes it took to put together that POC (especially after 25 years!), I'm happy with it for now.