OpenTemplot2024

[nickom]

Except that every time Martin makes a change to the master source that change will need to be converted in the open source version.

Yep, it's not going to be easy.

 

[nickom]

The parser is only responsible for converting a stream of tokens into an internal representation of the structure - classes, methods etc. It's the emitter that has to handle to conversion to another language / platform.

In your CharGPT version, for example, converting a byte to a number will probably not work while saving/loading binary box files. The correct conversion is byte > Int8Array.

 

[nickom]

I'm sure you're correct. It was just a quick example of converting basic Pascal types to Javascript types. There are specifics that would need to be catered for.

 

[Martin Wynne]

I'm sure you're correct. It was just a quick example of converting basic Pascal types to Javascript types. There are specifics that would need to be catered for.

@nickom

Hi Nick,

Any particular reason for choosing Javascript?

PHP seems the obvious choice for a web-based application. I find it much easier to write than Javascript, and it might integrate nicely with this forum, and the Companion pages, and the full Search on here.

Martin.

 

[Matt Harris]

@nickom

Hi Nick,

Any particular reason for choosing Javascript?

PHP seems the obvious choice for a web-based application. I find it much easier to write than Javascript, and it might integrate nicely with this forum, and the Companion pages, and the full Search on here.

Martin.

I would suggest that PHP tends to be used for server-side, whereas Javascript is more generally targeted at client-side (although frameworks like Node.js etc. muddy those waters...)

My reading of the rationale behind this idea was to not be reliant on a client-server (i.e. always on), rather that it could still run solely within the local context, much like today.

Matt H

 

[Martin Wynne]

The issue with breakfast is to remember if you had any never mind what it was !

@Rob Manchester

Hi Rob,

It's getting worse! I have just taken the teaspoon into the computer den, instead of the cup of tea.

Martin.

 

[nickom]

It was just an exercise to test converting Pascal code to Javascript. I was intrigued by how we could separate the UI coding within the Pascal files into a Model—view—controller form. I haven't achieved this yet.

As Matt put it, I was thinking of local context using web app technologies. Maybe Tauri or Electron and React. Too many choices.


One thing is for sure: whichever way we do this, it is a mammoth task. It will take many months, if not years, to get an open-source version working anywhere near as good as Templot, and only if we coordinate ourselves well. A group of volunteers will find it extremely difficult to do this.



Regards
Nick

 

[Martin Wynne]

Just to repeat:

This topic is about the internal programming of Templot. If you are interested only in using Templot, this topic can be ignored.

---

Another bugfix upgrade to Lazarus is announced today:

---

The Lazarus team is glad to announce the release of Lazarus 3.4.

This is a bugfix release and was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 3.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/

 

[Martin Wynne]

@nickom @NoIdea @Rusty

I thought it worth seeing what would happen in the Delphi Community Edition. After much commenting-out I have managed to get Templot running in the DCE -- here is some evidence:

The advantage over Lazarus is that it is compatible with legacy BOX files (in both directions), when running on Win32.

It is free, and the executables are permitted to be distributed for non-profit purposes. So in theory I could consider swapping from Delphi5 to DCE for ongoing Templot2 developments. After 25 years using Delphi5 that would be a bit of a wrench. But nothing lasts forever, and there would be an obvious advantage in using the same up-to-date compiler which everyone else can use for OpenTemplot if they wish.

The possible snag is that the licence lasts only for 12 months, after which: "To the extent you want to continue using the Community Edition after the expiration or termination of your Community Edition Term, you must re-install the latest version of the Community Edition and agree with the terms and conditions of the Agreement in force at that time". Which isn't a problem in principle if the terms and conditions don't change significantly. But there is no guarantee that they won't, or even that the DCE would continue to be available. Buying the full version of Delphi12 isn't really an option at £1,140

Decisions, decisions.

Martin.

 

[nickom]

Hi Martin,

Very interesting, as an insurance policy we could run a separate experiment getting either the Delphi 5 project working in VS Code and/ or even the DCE version.

I have the lazarus version compiling and running in VS code and have the debugger working (but breakpoints don't load at the moment), I only got it working last night so haven't had a chance to test full compatibility , it loads a previous template from a previous session and seemingly saves too. But I'm not experienced enough in Templot to know what works and what doesn't work.

If it turns out that DCE pulls the plug after a year we could have a backup.

Its free, the extension , OmniPascal is open source but not been actively developed recently, so we would need to look into that too.

Apologies for throwing more options in the ring.

Regards
Nick

 

[Rusty]

I thought it worth seeing what would happen in the Delphi Community Edition. After much commenting-out I have managed to get Templot running in the DCE -- here is some evidence:

That's a bit a curate's egg! Interesting to see you managed to get it running in DCE which alleviates many of the problems with converting to Lazarus, all for minimum code translation. It would avoid any problems or need to convert the code to a new language.

I thought I'd give it a try quickly, downloaded it and tried to install it and failed completely to install DCE. I just find it rather ironic that they laud being able to use it to build multi-platform applications easily and yet DCE is a windows only application!! No OSX or *nix versions available.

 

[Rusty]

Time permitting I have just been going through a few things to see what's available. I have cloned a copy of the current OpenTemplot from Github and installed Lazarus on a Windows machine, Linux (Mint) machine and an osX machine (MacBook Air). I have manage to compile and run OpenTemplot on all 3 platforms to varying degrees. The Linux and osX versions run okay but need tweaking. I have had a quick look the Delhi Community edition but not compiled anything as I don't have a full set of the original Delphi files.

My plan this next week was to start collating and logging all the files Martin has been posting recently.

The reason for posting this now was I was just having a read through of the release notes for Lazarus and I thought there were a couple of important updates that may be relevant to this comment posted earlier in the thread.

Obstacles

• We need to convert the pascal code over to Javascript (not 100% sure about this).
  • noidea is working on a code parser to do this

Basically from the Lazarus release notes was this section, my apologies if already known and being used but it was new to me.

Pas2js​

• lazbuild now can compile pas2js projects by passing the environment variable PAS2JS with the path of the pas2js executable.
• Project groups with pas2js projects now can compile without being opened.
• New project type Progressive Web Application
• New project type Electron Web Application
• pas2jsdsgn now uses the SimpleWebServerGUI package, replacing its own http server controller.
• F9, Run now builds, starts a HTTP server and a browser

So it appears that they are building in pascal to javascript transpilers tools into Lazarus including projects to convert to Electron apps which I seem to remember were mentioned earlier.

More info here https://wiki.lazarus.freepascal.org/pas2js

 

[Martin Wynne]

I have manage to compile and run OpenTemplot on all 3 platforms to varying degrees. The Linux and osX versions run okay but need tweaking

@Rusty

Hi Adrian,

Sorry to be a bit dim, but does that mean you have got OpenTemplot running natively on an Apple Mac? (I know nothing about Macs.)

If so, that's great news. The CrossOver/Wine option used to work fine on Macs, but recently there are lots of reported problems, and it has got more expensive.

A while ago, someone else reported a project to port OpenTemplot to a Mac, but sorry I can't remember who it was, or whether they were using Lazarus.

cheers,

Martin.

 

[Rusty]

Sorry to be a bit dim, but does that mean you have got OpenTemplot running natively on an Apple Mac? (I know nothing about Macs.)

Yes - sort of! I compiled OpenTemplot and it is running natively on an Apple Mac (M1 chip which they are using now instead of an Intel chip). I can't claim it works very well at the moment as there seem to be some issues with the sizing of the panels and redrawing of the panel. However the menu's appear to work and pop up various different forms. Not spent a great deal of time on it so numerous teething issues to investigate but it did run.

 

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme @Steve_Cornford @James Walters

I said I wasn't going to do any more with the files -- but here I am tinkering about in Lazarus. If I don't stop this and get back to plug track I can't see us having the K-crossings in time for Scaleforum.

On reflection, I think I should get these files working in Lazarus, as I did before.

It's free without restrictions, and it works. It won't be possible to include the sketchboard or the native PDF output, and maybe some other functions. But it will be possible to do track planning and create plug track. Which will make it easier for others to help maybe with getting more chairs done.

Martin.

 

[Steve_Cornford]

Hi Martin,
But first venture out into the sun and find a pleasant spot to consume the contents of your rucksack

I think you have achieved your aim of at least having a backup of the current state of play.

It might be worth letting the new recruits have a play with a) Lazarus and b) Delphi Community , whilst you solve your 8 sided chair dilemmas?

Steve

 

[Steve_Cornford]

Hi Martin,
How was your packed lunch?


Just for your information, i dont expect you to do anything about it.
Having replaced Lazarus 2.2.6 with Lazarus 3.4 and attempted the automatic project conversion again I got:-

and as you can see the conversion was aborted.
No option to [comment out] the missing units!
so 1 step backwards I think, as at least with Lazarus 2.2.6 it went through all the .pas files and gave option to comment out the missing units.
Unless I am missing something, you now have to edit the file in error yourself to remove the missing unit, then repeat the process to find the next unit(file) with missing stuff.

So stick with v2.2.6
Steve

 

[Martin Wynne]

But first venture out into the sun and find a pleasant spot to consume the contents of your rucksack

How was your packed lunch?

@Steve_Cornford

Hi Steve,

A pleasant walk in the sunshine through a sea of wild flowers on Bromyard Downs. I didn't eat the entire contents of my rucksack -- I forgot to take any sauce to put on the OS map..

Just for your information, i don't expect you to do anything about it.
Having replaced Lazarus 2.2.6 with Lazarus 3.4 and attempted the automatic project conversion again

@nickom @NoIdea @Rusty @Alistair Ward @graeme @James Walters

I'm tinkering with the files in Lazarus right now, and coming round to the idea of swapping to Lazarus for future development of Templot with plug track. That way it can be a proper open-source project where others can be part of ongoing developments. I'm coming to the conclusion that it's getting too much for me alone, and I can hardly expect much help while I stick to using a 25-year-old compiler which no-one else can get a copy of.

That means that Templot2 would be synced from OpenTemplot, rather than the other way round. That's a lot to think about, and it is largely dependent on finding a simple means of file transfer between them. If that could be fixed, users could easily swap to Templot2 when they need the functions not available in OpenTemplot -- chiefly the sketchboard and native PDF output. So finding a file fix is back at the top of the to-do list. My walk this afternoon did produce a possible idea to try.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

My walk this afternoon did produce a possible idea to try.

Ah but was it the walk or the contents of your rucksack?
Can you do a contolled experiment for us?

Today has started sunny in Brighton so off to stretch my legs with a walk to Hove lagoon where the clubhouse serves a decent cup of coffee!
Steve

 

[Rusty]

That means that Templot2 would be synced from OpenTemplot, rather than the other way round. That's a lot to think about, and it is largely dependent on finding a simple means of file transfer between them. If that could be fixed, users could easily swap to Templot2 when they need the functions not available in OpenTemplot -- chiefly the sketchboard and native PDF output. So finding a file fix is back at the top of the to-do list. My walk this afternoon did produce a possible idea to try.

I appreciate you may not want to hear this given previous experience but this is exactly what Git version control handles very quickly and very efficiently.

The files are all in the same area and under the same version control and then you have 2 branches, one branch for Templot2 and one branch for OpenTemplot. Under the git command you simply checkout the branch you want to work on, with one short command it will set all the files that are different to either the Templot2 version or the OpenTemplot version. If the file is common to both versions i.e each branch then one merge command on that file will apply the changes in one branch to the other branch as well.

Just offering it as one potential solution - perhaps it might help if I set a simple demo repository up first to show how it could work.

 

[Martin Wynne]

Just offering it as one potential solution - perhaps it might help if I set a simple demo repository up first to show how it could work.

@Rusty

Hi Adrian,

Yes please. I'm prepared to have one more go at trying to understand it. But it needs to be under the control of someone other than me -- I will be the one asking the questions on this, not answering them or explaining it.

We haven't heard anything from Graeme or Alistair, so we should probably be thinking of starting again from the beginning.

cheers,

Martin.

 

[Steve_Cornford]

Hi Rusty,
Would it be possible for you to give a Zoom seminar on using the GITHUB, hosted by Martin if he is agreeable?
Steve

 

[Rusty]

Hi Rusty,
Would it be possible for you to give a Zoom seminar on using the GITHUB, hosted by Martin if he is agreeable?
Steve

Yes, I'm more than happy to do so. However just a small caveat, it will take me a little time to plan out and setup a demo as I'd like to make it relevant to the Templot code. Work commitments at the moment limit my spare time but I will work on something as soon as I can.

 

[Steve_Cornford]

Hi Martin,
May I suggest that you keep the name Templot2 tin order to avoid extra non-productive work for yourself?
It is after all your hobby, and we don't want to make it your burden!
As for confusion, maybe this is where your disciples can help to dispel any that may arise, by broadcasting and explaining the requirement for the file format change.
I assume that you would first add the new format into the Delphi version & make it the default, just like Microsoft did with .xls and .xlsx file formats.

Am I right in thinking that the new BOX file format is non-binary?
Do we assume that you have now discounted the Delphi Community edition route?

Steve
edited for typos

 

[Steve_Cornford]

ps
Having a common file format between the two versions is a jolly good idea, just a pity that XBOX is already spoken for

 

[Martin Wynne]

Am I right in thinking that the SWAPBOX file format is non-binary?
Do we assume that you have now discounted the Delphi Community edition route?

@Steve_Cornford

Hi Steve,

The new BOX format is still a binary format, but the extended floating-point type used in the program is stored as a double type in the files. Which means it can be read back into 10-byte extended format in Delphi-compiled programs, or 8-byte double format in Lazarus-compiled programs and on platforms other than Win32.

There's rather more to it than that, because over the years the BOX format has got quite tangled, with mixed binary and text-based sections. For example the shove-timber data is repeated in 3 different formats to maintain full backwards compatibility (which was important in the days when Templot was a paid-for program). For the new BOX it is simplified to a single text-based XML section.

Ideally we would start again with a blank sheet of paper, but that would be a lot of work and need a lot of time-consuming testing.

The Delphi Community Edition is a working alternative to Lazarus, but I don't really trust Embarcadero not to withdraw it or change the rules. Whereas Lazarus itself is open-source, so it's very unlikely to disappear.

DCE also has a confusing mix of string types, and it is difficult to be sure which one is guaranteed to match Delphi5 strings in all cases and importantly in the Delphi library functions. I think it would mean changing every default string type in Templot to AnsiString(1252). Here is the full explanation:

https://docwiki.embarcadero.com/RADStudio/Athens/en/String_Types_(Delphi)

There will be a test later.

cheers,

Martin.

 

[Phil O]

Hi Martin,

I don't think that changing the box file format would be a huge issue, so long as there's a period of grace to update old files to the new format. It would need to have wide publicity to ensure that we have the opportunity to do the change. Not a problem for us forum followers but maybe for others.

 

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme @Steve_Cornford @James Walters

Let's keep the .BOX file extension name for all files for both Templot2 and OpenTemplot2024, to keep it simple for users.

The actual content of a saved BOX file will change from the next program update 245a.

Templot2 will happily load BOX files in either the old or the new format (without anyone being aware of the difference), but save only in the new format.

When/if it gets released, OpenTemplot2024 will load BOX files in the new format only.

OpenTemplot2024 will complain if you try to load a file in the old format. If you want to use an old BOX file in OpenTemplot2024, it would be necessary to load it first into Templot2 and then save it again.

We haven't heard from Graeme or Alistair, so I think we should probably forget about any compatibility with the 2018/2019 open-source versions. I doubt there is anyone using them for any actual work.

Martin.

 

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme @Steve_Cornford @James Walters @Phil G

I'm pleased to say that from 245a BOX files will be interchangeable between Templot2 and OpenTemplot.

This means that I have achieved what I have been saying for years is impossible.

When loading older BOX files into Templot2 you will see this:

But not any existing version of OpenTemplot -- I need to update the OpenTemplot2024 files which I released recently.

---

This also means that the way is now clear for me to think of switching future development work on Templot2 to Lazarus instead of Delphi5, and make Templot a fully open-source project in the usual way.

There is quite a lot to think about there, not least freezing the final version from Delphi5 as a conversion utility for users wanting to make use of their existing BOX files.

All this has been an interruption to plug track developments, but hopefully it will mean that as an open-source project it can progress faster in future as others join in.

Initially there will still need to be two versions of Templot -- one which only I can compile using the non-open-source components (sketchboard, PDF output); and one which anyone can compile, without them. When/if we can find open-source replacements for those functions we would then need only one version.

The first such release of a Templot2 version from Lazarus will need a lot of testing to find all the quirks which need fixing. There is likely to be a lot of them, so I'm going to take my time before I make the change.

---

The open-source files which I released recently were from Delphi5 as-is. These links describe the changes needed for Lazarus:

https://wiki.freepascal.org/Lazarus_For_Delphi_Users

https://wiki.freepascal.org/Code_Conversion_Guide

Martin.

 

[Phil O]

Well done Martin! All of this is well beyond my pay grade and expertise, but if it helps others to help you, it's a great leap forward.

 

[NoIdea]

I agree with Phil -- it's a great leap forward!

I'm looking forward to 245a to examine the new format files.

I don't know if this helps but I thought I'd outline a roadmap of sorts:

1. Complete the K crossings for Scale Forum.
2. Switch to Lazarus
3. Think about open sourcing and syncing the closed and open sourced versions

Is that broadly what you had in mind?

 

[Martin Wynne]

I agree with Phil -- it's a great leap forward!

I'm looking forward to 245a to examine the new format files.

I don't know if this helps but I thought I'd outline a roadmap of sorts:

1. Complete the K crossings for Scale Forum.
2. Switch to Lazarus
3. Think about open sourcing and syncing the closed and open sourced versions

Is that broadly what you had in mind?

@NoIdea @James Walters

Hi Martin,

I'm now reluctant to commit to having the proper K-crossings done in time for Scaleforum. I don't work well to deadlines, and if the weather improves I want to spend this summer in the hills with my camera. I did too much Templot while the sun was shining last year.

But we can have some acceptable K-crossings at Scaleforum (and right now) using the improvised method:

https://85a.uk/templot/club/index.php?posts/10762

so maybe there isn't too much urgency for the proper ones.

It might make sense to get your 2. and 3. out of the way, and then treat the K-crossings as a first task to be developed in Lazarus. One thing I do know is that within 5 minutes of doing them, someone will be asking about chairs for slips.

As regards 3. I'm thinking now in terms of providing the sketchboard and native PDF functions as linked helper executables created in Delphi5. This would be a temporary solution which I can do now without any issues about getting them to compile in Lazarus. Long term we can then look for open-source equivalents to replace them. This would make 2. easier to achieve, possibly quite soon. It would mean that everything in Lazarus could be open-source from the start.

cheers,

Martin.

 

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme @Steve_Cornford @James Walters @Phil G

I'm thinking now in terms of providing the sketchboard and native PDF functions as linked helper executables created in Delphi5.

This is now working for PDF:

There will be a choice in 245a -- click the usual create PDF... button to use the existing integrated PDF generator. This can't be open-sourced.

The temporary experimental exp button will achieve the same result by sending EMF metafiles to an external PDF helper executable. This function can be open-sourced and working in Lazarus (on Windows and CrossOver/Wine), and will be the new button for OpenTemplot.

I'm intending to do something similar for the sketchboard, but that's rather more complex and will take time. There is also some work needed on the file viewer to replace the original 30-year-old Windows 16-bit drive-access controls (which work better for the purpose than anything later I have been able to find -- Graeme did some work on this, but lost some essential functionality).

But having got a common file format and the essential native PDF output usable in OpenTemplot, I can now think in terms of moving over to Lazarus for all future work on Templot2 and plug track -- and all open-source for anyone who wishes to take part in future developments.

Which is a round-about way of saying that I'm going to pause work on plug track until that's done. It will take a while to get everything going in Lazarus -- especially if the sun starts shining. When done I will post a new Zip file with everything ready to compile straight off in Lazarus, as I did originally in 2018. So that anyone can if they wish easily create their own personal copy of Templot 246a.

Hopefully that is -- assuming I don't run into any road blocks!

Users needing the sketchboard, or with existing BOX files to convert, will be able to stick with 245a for the time being. Or use both, side-by-side.

Martin.

 

[Phil G]

Hi Martin,
Given there is now an acceptable workaround for the K crossing.
I fully agree with you, time spent on an open source version of Templot, will ultimately be the better option. As it also opens the door for more contribution from others, and thus in the long run much less stress on yourself. Maybe it will be possible with several contributors to move quickly from K crossing to slips once open Templot is fully active!
Well done in getting this as an open source project.
Cheers
Phil

 

[Martin Wynne]

I fully agree with you, time spent on an open source version of Templot, will ultimately be the better option. As it also opens the door for more contribution from others, and thus in the long run much less stress on yourself.

@Phil G

Hi Phil,

I hope so, because I no longer think I can do it all myself.

On the other hand I have to be realistic -- Templot has been open-source for 6 years now, and so far not a single line of code from others has made it into a program release. Graeme and Alistair had been active until about 18 months ago, but they were a long way from releasing a usable version. Others have come and gone over the years. I know a large part of the problem is that the program is such a tangled web of code after 40+ years of hotch-potch development. Ideally we would start again with a blank sheet, but that would be a massive task.

A likely disincentive to get involved has been the fact that I have been separately progressing a closed-source version of Templot2, leaving the original open-sourced code a long way behind. That has changed now that I have released the current code in recent days.

If I can now get all the ongoing development of Templot into open-source others might be more interested in getting involved. As soon as I have got it all into Lazarus we can perhaps have a Zoom meeting to see where we go next. While I can still remember how it works.

cheers,

Martin.

 

[NoIdea]

Martin,

If I can now get all the ongoing development of Templot into open-source others might be more interested in getting involved

Definitely.

Phil - the intersection in the Venn diagram between railway modellers, pascal developers and subject matter experts is very small, but the move to Lazarus by Martin will make this more possible.

My ongoing attempt to convert the 2018 code was to try and address some of the above without disturbing Martin but although Martin has been side-tracked this is a far better outcome than I'd hoped for.

[I don't know if you're interested but my converter now handles derived classes and events. Next up is constructors and destructors.]

I'm really looking forward to that Zoom meeting, Martin.

 

[Stephen Freeman]

It is about 25 years since I had anything to do with Pascal (I think I still have a copy of Turbo Pascal on a set of diskettes) even then at a very basic level, however if I ever get the time to spare I will try to join in but don't hold your breathe. One problem using the Pascal I have would be that it is a set of diskettes - no diskette drive on current PC, though I do have a Windows 95/98 machine as well (there is a reason but don't ask) which I could use to hopefully transfer them onto CDR when I have the time.

 

[Martin Wynne]

.
If you are wondering why I regard the native PDF output from Templot as important, see:

https://85a.uk/templot/club/index.php?posts/5490

Here is a PDF of a single page 6 metres long by 1 metre wide:

This PDF file could be sent or taken to a local copy shop for printing on wide-format roll paper. It is easily created in Templot just by setting the page size in the PDF output. Doing this in almost any other PDF program would be tricky or impossible.

p.s. Some here may recognise this as the work of the late Gordon Stolliday for his multi-level Eastwood Town project. He was a good friend of Templot.

Martin.

 

[Martin Wynne]

@nickom @NoIdea @Rusty @Alistair Ward @graeme @Steve_Cornford @James Walters @Phil G

It's been a battle of wits, but I have now got Templot version 555a running in Lazarus:

To get this far required great swathes of code to be temporarily commented out -- mainly for the metafiles, picture shapes and maps. But having got it to compile and run, I can now go back and remove the sticking plasters one by one to fix the issues. As you can see there is also some cosmetic stuff relating to font sizes and group panels to be dealt with.

But it's progress, and hopefully before long it will be in a fit state to be released as an oven-ready project for Lazarus. For which I will need to try yet again to make sense of Git.

cheers,

Martin.

 

[NoIdea]

Marvellous

Could I suggest that we don't worry about Git for now and share ideas about the code structure first. Or rather, what the code structure could look like in a single codebase.

The code you have commented out Martin could be wrapped in {$IFDEF CLOSED} directives?

Then, to update the contents of open_templot_2024.zip a batch file could copy the relevant files to another directory ready for creating an updated zip file? Something like:

COPY action_unit.* c:\ZIP
COPY alert_unit.* c:\ZIP
.
.

Post the zip file to the OpenTemplot2024 -- files ex-Delphi5 topic and others can update a Git repository.

Does that make sense?

Martin