Templot Club forums powered for Martin Wynne by XenForo :

TEMPLOT 3D PLUG TRACK - To get up to speed with this experimental project click here.   To watch an introductory video click here.   See the User Guide at Bexhill West.

  • The Plug Track functions are experimental and still being developed. Some of the earlier pages of this topic are now out-of-date.

    For an updated overview of this project see this topic.   For some practical modelling aspects of using Plug Track see Building 3D Track.

    The assumption is that you have your own machines on which to experiment, or helpful friends with machines. Please do not send Templot files to commercial laser cutting or 3D printing firms while this project is still experimental, because the results are unpredictable and possibly wasteful.

    Some pages of this and other topics include contributions from members who are creating and posting their own CAD designs for 3D printing and laser-cutting. Do not confuse them with Templot's own exported CAD files. All files derived from Templot are © Martin Wynne.
  • The Plug Track functions are experimental and still being developed.

    For an updated overview of this project see this topic.   For some practical modelling aspects of using Plug Track see Building 3D Track.

    The assumption is that you have your own machines on which to experiment, or helpful friends with machines. Please do not send Templot files to commercial laser cutting or 3D printing firms while this project is still experimental, because the results are unpredictable and possibly wasteful.

    Some pages of this and other topics include contributions from members who are creating and posting their own CAD designs for 3D printing and laser-cutting. Do not confuse them with Templot's own exported CAD files. All files derived from Templot are © Martin Wynne.

OpenTemplot2024

Quick reply >

NoIdea

Member
Location
Nottingham
But when I made Templot (as it then was) open-source in 2018, I did hope that by 5 years later there would be a group of users with as much knowledge of the code as me. Sharing and developing ideas together. Sadly that hasn't happened. There has been occasional short-lived interest from programmers, but no-one who was an actual user of Templot or with much, or any, knowledge of railway track or track-building. Usually the interest has been in computers to get the existing code running on a different platform, rather than extending and developing it further for track planning and building.
Is it still open source, Martin? I've looked over the Templot Club links looking for a source repo link but couldn't find one...
 
_______________
message ref: 9860
Is it still open source, Martin? I've looked over the Templot Club links looking for a source repo link but couldn't find one...
@NoIdea

Hi Martin,

Yes, but bear in mind the original code is from 2018 -- it doesn't include a lot of later developments and plug track:

https://sourceforge.net/projects/opentemplot/

https://github.com/openTemplot/openTemplot

Link:

open_source_link.png


Original topics from 2018:

https://85a.uk/templot/archive/topics/topic_3283.php

Then later:

https://85a.uk/templot/archive/topics/topic_3324.php

https://85a.uk/templot/archive/topics/topic_3454.php

More discussion:

https://85a.uk/templot/club/index.php?forums/templotmec-nuts-and-bolts.5/

But there has been no recent activity. Search "Lazarus" to find all the old topics.

It's time I released some later versions of the files, but it's a massive task to prepare them all. Templot2 includes some licensed components which can't be open-sourced, and need to be cleanly by-passed or worked around.

cheers,

Martin.
 
_______________
message ref: 9861
Hi Martin,

I assume these are 32-bit DLLs? Are they COM components?

Could you identify them and their purpose?

Martin
@NoIdea

Hi Martin,

The non-open-source components are these in red:

t2_code_components.png



They are not DLLs. Sorry, I do not know what a COM component is, although I have heard the term and no doubt I could find out.

For all these I purchased licences (a long time ago now, when Templot was a paid-for product):

DtpDocuments is a desk-top-publishing component. The core engine drives the sketchboard function in Templot. I purchased the Delphi source code and significantly modified it for the sketchboard user interface. Sadly the developer Nils Haeck suffered a brain injury in an accident and was unable to continue supporting his software:

https://torry.net/components/edits-memos/packs/dtpdocuments

TRichView is an enhanced text editor. It drives the formatted text blocks on the sketchboard. I purchased the Delphi source code:

https://www.trichview.com/features/trichview.html

wPDF is a PDF generator which drives Templot's native PDF exports. I purchased it in the form of Delphi DCUs (object files), although there is also a DLL option:

https://www.wpcubed.com/pdf/products/wpdf/

cheers,

Martin.
 
_______________
message ref: 9863
@Phil G @James Walters

Hi Phil,

It's a good question.

At the back of my mind for years now I've been hoping to find a long-term user of Templot with as much Templot knowledge as me so that we could bounce ideas off each other -- and I could be the one asking questions and learning, instead of always the one answering the questions. Often the same ones I've answered many times before.

I realise that's not a realistic expectation now. But when I made Templot (as it then was) open-source in 2018, I did hope that by 5 years later there would be a group of users with as much knowledge of the code as me. Sharing and developing ideas together. Sadly that hasn't happened. There has been occasional short-lived interest from programmers, but no-one who was an actual user of Templot or with much, or any, knowledge of railway track or track-building. Usually the interest has been in computers to get the existing code running on a different platform, rather than extending and developing it further for track planning and building.

So it's just me. Templot is my hobby and I enjoy the coding and tinkering with new ideas. But to be honest it's being spoilt for me by the constant need to keep explaining everything. Over and over again. Since the present version of Templot Club started there have been 762 topics and well over 9,000 messages on here -- and here I am typing yet another one. And there are 3,000 topics in the archive from the previous version of Templot Club. And hundreds of messages on other forums. It's difficult to believe there could be much left to say after all that, and I'm getting weary of it all.

So what am I looking for in the Zoom meetings? Someone to come on with a brilliant new idea for Templot with details of how it would integrate into the existing code. Someone telling me things instead of asking me questions. I live in hope.

cheers,

Martin.
Martin,

What language is TEMPLOT written in?

Is it in manageable modules (i.e. Object Oriented Modules) or is it one piece of code that has continuously expanded over the years?

Is the code annotated? (Critical to anybody else understanding it..!)

Do you think it should, and if so, could be updated to reflect standard interface menus/protocols to make it more intuitive?

On constantly having top explain things, its called the RTFM problem - and people rarely do, especially if there is a very accommodating responder..!

Thank you for all your hard work.

Regards,

Patrick
 
_______________
message ref: 9910
Martin,

What language is TEMPLOT written in?

Is it in manageable modules (i.e. Object Oriented Modules) or is it one piece of code that has continuously expanded over the years?

Is the code annotated? (Critical to anybody else understanding it..!)

Do you think it should, and if so, could be updated to reflect standard interface menus/protocols to make it more intuitive?

On constantly having top explain things, its called the RTFM problem - and people rarely do, especially if there is a very accommodating responder..!

Thank you for all your hard work.

Regards,

Patrick
@NFWEM57

Hi Patrick,

Thanks. Welcome to Templot Club. :)

It was good to see you at the Zoom meeting last night.

Templot is written in Delphi5/Pascal. The 2018 open-source version will compile and run in Lazarus (or at least, it did the last time I tried -- quite a long while ago now).

Recent discussion about the open-source version is here (and much more in the old forum archive):

https://85a.uk/templot/club/index.php?threads/open-source-again.839/

Downloads:

https://sourceforge.net/projects/opentemplot/
https://github.com/openTemplot/openTemplot

Sorry, I don't know what you mean by modules. There are about 80 .pas source files and a similar number of .dfm form files.

Yes, it has been continuously expanded over the years -- originally started 45 years ago in 1979. Yes, the code is commented, but in a strange martin-language which few understand. :)

Do you think it should, and if so, could be updated to reflect standard interface menus/protocols to make it more intuitive?

I think that is what Alistair and Graeme are trying to do, but we haven't heard from them for many months. I'm not sure what you mean by "more intuitive". I have tried many times over the years to follow similar suggestions, but always it has required that some functionality be lost, which I am not willing to do. Essentially Templot is my hobby, and developed for my own use as its primary purpose.

Here is the current full list of source files. Some are very long (thousands of lines), some are quite short. I added one more this morning:

Code:
  control_room in 'control_room.pas' {control_room_form},
  keep_select in 'keep_select.pas' {keep_form},
  switch_select in 'switch_select.pas' {switch_select_form},
  alert_unit in 'alert_unit.pas' {alert_box},
  help_sheet in 'help_sheet.pas' {help_form},
  math_unit in 'math_unit.pas' {math_form},
  xing_select in 'xing_select.pas' {xing_select_form},
  chat_unit in 'chat_unit.pas' {chat_form},
  pad_unit in 'pad_unit.pas' {pad_form},
  entry_sheet in 'entry_sheet.pas' {data_entry_form},
  info_unit in 'info_unit.pas' {info_form},
  print_unit in 'print_unit.pas' {print_form},
  gauge_unit in 'gauge_unit.pas' {gauge_form},
  metric_unit in 'metric_unit.pas' {metric_form},
  preview_unit in 'preview_unit.pas' {preview_form},
  colour_unit in 'colour_unit.pas' {colour_form},
  calibration_unit in 'calibration_unit.pas' {calibration_form},
  plain_track_unit in 'plain_track_unit.pas' {plain_track_form},
  startup_unit in 'startup_unit.pas' {old_startup_form},
  dxf_unit in 'dxf_unit.pas' {dxf_form},
  bgnd_unit in 'bgnd_unit.pas' {bgnd_form},
  bgkeeps_unit in 'bgkeeps_unit.pas' {bgkeeps_form},
  panning_unit in 'panning_unit.pas' {panning_form},
  grid_unit in 'grid_unit.pas' {grid_form},
  shove_timber in 'shove_timber.pas' {shove_timber_form},
  stay_visible_unit in 'stay_visible_unit.pas' {stay_visible_form},
  action_unit in 'action_unit.pas' {action_form},
  edit_memo_unit in 'edit_memo_unit.pas' {edit_memo_form},
  mint_unit in 'mint_unit.pas' {mint_form},
  wait_message in 'wait_message.pas' {wait_form},
  enter_timber in 'enter_timber.pas' {enter_timber_form},
  jotter_unit in 'jotter_unit.pas' {jotter_form},
  rail_options_unit in 'rail_options_unit.pas' {rail_options_form},
  print_settings_unit in 'print_settings_unit.pas' {print_settings_form},
  pdf_unit in 'pdf_unit.pas' {pdf_form},
  dtp_unit in 'dtp_unit.pas' {dtp_form},
  dtp_settings_unit in 'dtp_settings_unit.pas' {dtp_settings_form},
  sketchboard_unit in 'sketchboard_unit.pas' {sketchboard_form},
  prefs_unit in 'prefs_unit.pas' {prefs_form},
  print_now_box in 'print_now_box.pas' {print_now_form},
  export_unit in 'export_unit.pas' {export_form},
  platform_unit in 'platform_unit.pas' {platform_form},
  data_memo_unit in 'data_memo_unit.pas' {data_child_form},
  math2_unit in 'math2_unit.pas',
  check_diffs_unit in 'check_diffs_unit.pas' {check_diffs_form},
  image_viewer_unit in 'image_viewer_unit.pas' {image_viewer_form},
  dtpGR32 in 'DtpDocuments\Source\Third\Graphics32x\dtpGR32.pas',
  mouse_colour_unit in 'mouse_colour_unit.pas' {mouse_colour_form},
  file_viewer in 'file_viewer.pas' {file_viewer_form},
  sb_rvf_outer_unit in 'sb_rvf_outer_unit.pas' {sb_rvf_outer_form},
  sb_rvf_unit in 'sb_rvf_unit.pas' {sb_rich_form},
  arc_shape_unit in 'arc_shape_unit.pas',
  edit_outline_unit in 'edit_outline_unit.pas' {edit_outline_form},
  web_browser_unit in 'web_browser_unit.pas' {web_browser_form},
  map_loader_unit in 'map_loader_unit.pas' {map_loader_form},
  web_map_help_unit in 'web_map_help_unit.pas' {web_map_help_form},
  trackbed_unit in 'trackbed_unit.pas' {trackbed_form},
  make_slip_unit in 'make_slip_unit.pas' {make_slip_form},
  create_tandem in 'create_tandem.pas' {tandem_form},
  chairs_unit in 'chairs_unit.pas' {chairs_form},
  bitmap_viewer_unit in 'bitmap_viewer_unit.pas' {bitmap_viewer_form},
  shoved_colour_unit in 'shoved_colour_unit.pas' {shoved_colour_form},
  track_spacing_unit in 'track_spacing_unit.pas' {track_spacing_form},
  detail_mode_unit in 'detail_mode_unit.pas' {detail_mode_form},
  gaps_unit in 'gaps_unit.pas' {gaps_form},
  lib_unit in 'lib_unit.pas' {lib_form},
  intersect_unit in 'intersect_unit.pas' {intersect_form},
  getfile_unit in 'getfile_unit.pas' {getfile_form},
  httpsend in 'httpsend.pas',
  create_y_turnout in 'create_y_turnout.pas' {create_y_form},
  resample in 'resample.pas',
  map_clarity_unit in 'map_clarity_unit.pas' {map_clarity_form},
  jigs_unit in 'jigs_unit.pas' {jigs_form},
  dxf_warning_unit in 'dxf_warning_unit.pas' {dxf_experimental_form},
  heave_chairs in 'heave_chairs.pas' {heave_chairs_form},
  search_unit in 'search_unit.pas' {search_form},
  mw_unit in 'mw_unit.pas' {mw_form},
  brick_unit in 'brick_unit.pas' {brick_form},
  chair_frame_unit in 'chair_frame_unit.pas' {chair_frame: TFrame},
  export_preview_unit in 'export_preview_unit.pas' {export_preview_form},
  clips_unit in 'clips_unit.pas' {clips_form},
  heave_customize_unit in 'heave_customize_unit.pas' {heave_customize_form};

cheers,

Martin.
 
_______________
message ref: 9912
NFWEM57 - Patrick, I've downloaded the 2018 open source version and studying the code with an extension to VS Code. I'm not a Pascal developer so I'm going into a learning curve here. Hopefully my c#, typescript, c++ background will flatten the curve a bit.

I also need to learn more about Templot - I'm very much a beginner - and I think, like others, that the UX/UI that Martin has developed over the years, is, um, unusual, which is why IMHO there are repeated questions.

At the moment, I'm trying to figure out how best I can help Martin's endeavours. I respect that this is Martin's code, not an open-source project. I'd much rather Martin was implementing K crossings and flat-bottom rail support in Plug Track instead of implementing new menu structures (Only kidding, Martin) :).

Martin
 
_______________
message ref: 9913
@graeme @Alistair Ward @NoIdea @NFWEM57

It's now nearly a year since there has been any activity (as far as I know) at:

https://github.com/openTemplot/openTemplot

Which makes me wonder where we go from here?

When I've got 244a released with the chair heaving done, I'm minded to start again and release the whole* of Templot2 as open-source in its present state, before going any further.

*apart from the licensed components which I mentioned in my previous post.

There is still a lot of chair designs to be done (not to mention GWR chairs and other prototypes), and having all the present code available might encourage others to have a go at them (and take a bit of pressure off me :) ).

When I say "release as open-source" I mean simply to publish the current Delphi5 files as-is. I'm not getting involved in Git repositories and such like -- I've tried and failed several times to understand that mystery, and wasted many many hours in the process. If others want the files committed/pushed/pulled/merged/forked or whatever it will be up to them to do it.

Likewise getting the files to compile and run in Lazarus will be for someone else to do, if wanted. There have been several updates to Lazarus since the 2018 files were released, which will almost certainly need some changes in the code.

Just releasing the 160+ Delphi5 files is a big task, each one requiring the copyright and open-source licensing details added, a lot of tidying up, and the licensed components removed. Which is likely to take a month or two to get them all done, with a further delay to my getting back to the chairs. So it's a trade-off as to whether it is worth doing now, or at all.

On the other hand, if not now, when? I'm getting uneasy that folks will soon be relying on Templot plug track for their real-world projects, rather than just experimental tinkering, and hence relying on me alone. It's a lonely place to be.

Martin.
 
_______________
message ref: 10191
Hi Martin,
I can understand your concerns.
In a past life I ran a small software company, and we looked after and developed a Stockbroker package pre Big Bang (that was when the Stock Exchange moved from fortnightly settlement periods to Rolling Settlement. To protect the clients (all 5 of them!) we entered into a Software Escrow Agreement that ensured in the event of our demise they would gain access to the source code.

Would it reduce your concerns if something like that was in place?
Steve
 
_______________
message ref: 10196
Hi Martin,
I can understand your concerns.
In a past life I ran a small software company, and we looked after and developed a Stockbroker package pre Big Bang (that was when the Stock Exchange moved from fortnightly settlement periods to Rolling Settlement. To protect the clients (all 5 of them!) we entered into a Software Escrow Agreement that ensured in the event of our demise they would gain access to the source code.

Would it reduce your concerns if something like that was in place?
Steve
@Steve_Cornford @James Walters

Hi Steve,

I'm not a company, and I don't have paying clients, so the situation is not the same. Open-source files are available to the entire world regardless, so no such agreement is needed.

At present the Templot files to which that applies relate to Templot as it was in 2018. You can download them as a zip file here:

https://sourceforge.net/projects/opentemplot/

But Templot has moved on a lot since then, not least for the 3D chairing, so it's time I released a fresh set of updated files. In practice that is easier said than done, because there are 160+ of them, and each one needs tidying up, with licence details added, and some copyright components removed without breaking the code.

Even when it is done it doesn't get anyone much further forward without some means of compiling the code. As it stands that requires a copy of the Delphi5 compiler from 1998. I can't publish that because it is copyright of Embarcadero, and I don't know where a copy might be obtained.

The solution is to compile the files in the open-source Lazarus compiler instead, set to Delphi mode. That requires some modifications in the code. I did that for the 2018 files, but it took a lot of time and testing, and would need doing again.

If we could get to that stage it would permit others to join in and help with writing code.

Which would be a big help because the truth is that my recent injury has made me realise that I'm getting old and tired, and it is all getting too much for me. I still enjoy writing new code to develop the Templot program forward, but all the rest -- explaining, explaining, explaining, making videos, doing Zoom meetings, running Templot Club and updating the Templot web site is now too much commitment. James is being a big help, but he has a day job and his own model projects.

And here I am writing yet another explanation, this time about the open-source files. Time now to get some lunch and no Templot work done yet today. I need to go out later, so it's not likely much will get done today.

Answers on a postcard.

cheers,

Martin.
 
_______________
message ref: 10203
Well I do have a copy of Turbo Pascal but it is sitting on the original 3.5inch diskettes and I don't have a drive attached to any of the Windows 10 computers. I suppose I could copy them onto a CD/DVD via my special retro PC (don't ask why I have one) or alternatively I might just have a copy of Delphi5 as they were very fond on putting them on PC magazine cover CDs at one time. I shall have to see.Found the diskettes bu no CDs as far as I know. I don't really have the time at the moment to explore the possibilities as am too busy building signals and 3d track (not necessarily printed).
 
_______________
message ref: 10206
Last edited:
I might just have a copy of Delphi5 as they were very fond on putting them on PC magazine cover CDs at one time.

Just to clarify that my copy of Delphi5 is a purchased Professional Edition licensed for commercial use.

Martin.
 
_______________
message ref: 10231
Hi Martin,
One does not need to be a company to enter into an escrow agreement.
Rather than the "open-source" files I was thinking of the Delphi 5 files.

I'm getting uneasy that folks will soon be relying on Templot plug track for their real-world projects, rather than just experimental tinkering, and hence relying on me alone. It's a lonely place to be.

Perhaps an arrangement could be made between yourself and one or more of the societies that promote track building.

But if there is any way any of us can help to reduce the burden, just ask.

Steve
 
_______________
message ref: 10232
Hi Martin,

Having just restarted using templot, I have been taking a look at the code you have made open-source a few years ago. Browsing around and tracing via the debugger to try and get a handle on the program flow reveals a very impressive codebase. I cannot say I understand any of it at the moment, but I'm intrigued how you used the available tools over the years to produce a blazingly fast piece of software.

My understanding so far is:
  • The UI is drawn by building a bitmap. I don't know this for sure, but my thinking is that if the.Box file is logically held in binary format, it makes sense to draw that directly rather than using Canvas or similar. Is this correct?
  • I have yet to find the unit that carries out this bit manipulation , so I'm probably wrong.
From a software architecture point of view, what techniques did you use to squeeze out every last ounce of processing cycles on very constrained hardware.

Apologies if this seems impertinent; I would very much like to understand the inner workings of your code and who knows, if I learn enough, I may be able to contribute in the longer term.

Thanks
Nick
 
_______________
message ref: 11252
Hi Martin,

Having just restarted using templot, I have been taking a look at the code you have made open-source a few years ago. Browsing around and tracing via the debugger to try and get a handle on the program flow reveals a very impressive codebase. I cannot say I understand any of it at the moment, but I'm intrigued how you used the available tools over the years to produce a blazingly fast piece of software.

My understanding so far is:
  • The UI is drawn by building a bitmap. I don't know this for sure, but my thinking is that if the.Box file is logically held in binary format, it makes sense to draw that directly rather than using Canvas or similar. Is this correct?
  • I have yet to find the unit that carries out this bit manipulation , so I'm probably wrong.
From a software architecture point of view, what techniques did you use to squeeze out every last ounce of processing cycles on very constrained hardware.

Apologies if this seems impertinent; I would very much like to understand the inner workings of your code and who knows, if I learn enough, I may be able to contribute in the longer term.

Thanks
Nick
@nickom

Hi Nick,

Welcome to Templot Club. :)

Many thanks for your kind words. And not impertinent at all -- Templot coding is my hobby and I'm happy to share it with anyone interested.

But I'm a retired oily-fingered toolmaker (no relation to Keir Starmer :) ). I'm not a software professional and have never had any formal training in the subject, so I often find it difficult to understand questions from professionals. Usually such professionals ask me why Templot doesn't follow some accepted software standard or other. But since I don't know what those standards are, and definitely didn't know anything about such things 25+ years ago when most of the core code in Templot was written, it's not surprising that the code doesn't follow any expected norms.

In all that time you are the first I can recall writing in such positive terms about my code -- it is news to me that I have produced a "blazingly fast piece of software", or that I have "squeezed out every last ounce of processing cycles on very constrained hardware". So thank you for that, but I'm not too sure how I did it. :unsure:

I'm still using the Delphi5 compiler from 1998, which probably means that the executable doesn't contain much of the later Windows bells and whistles, but one constant mystery to me has been why the Templot executable file is so much smaller (8MB) than any comparable software. But my guiding principle is always "if it ain't broke don't fix it", so I'm happy to leave it at that.

Yes the BOX file is in binary format, but I'm not sure that is relevant to the user interface. The contents are copied into memory and used to draw a background bitmap, containing the grid and the background templates . This is copied to the screen bitmap and then the control template is drawn over it. To update the screen bitmap as the control template is modified, the background bitmap is re-copied to the screen bitmap without needing to be re-created, and the new control template is drawn over it.

Yes, drawing on the bitmaps is mostly done using the Delphi TCanvas control, although I'm not sure that's what you mean by Canvas?

As to where all this is done, have a look in grid_unit.pas :

Code:
  procedure draw_background_templates(canv:TCanvas; group_code:integer; highlight_index:integer; highlight_on:boolean; highlight_colour:TColor);  //  all the background templates.

  procedure do_background(mode:integer);                  //  draw the complete background.
  procedure copy_draw_to_pad;                             //  copy the draw-bitmap to the pad.
  procedure wipe_draw_bmp(add_sketchboard_items:boolean); //  wipe the draw-bitmap.
  procedure wipe_pad;                                     //  wipe the actual pad form.

  procedure draw_bg_shapes(canv:TCanvas;index,colour:integer);        // draw any background shapes.
  procedure draw_notch(canv:TCanvas);                                 // draw the pegging notch. (might get redrawn by the control template).
  procedure draw_rings(canv:TCanvas; copies,dummy_vehicle:boolean);   //206b  draw the spacing-ring or copies.

  procedure draw_dummy_vehicle_copies(on_canvas:TCanvas);    // 0.98.a



  procedure copy_drop_to_canvas(canv:TCanvas);forward;  // copy the drop-bitmap to the specified canvas.
  procedure wipe_fill_drop;forward;                     // draw as much as will remain fixed on the backdrop.
  procedure draw_all_on_canvas(canv:TCanvas);forward;   // normal draw, use the specified canvas for everything.
  procedure finish_on_canvas(canv:TCanvas);forward;     // draw any items not on the backdrop on the specified canvas.

Much of the actual drawing work for the control template is done in math_unit.pas, see for example:

Code:
function show_a_line(on_canvas:TCanvas; aq, pen_width:integer; erasing:boolean):boolean;     //  draw a rail-line on the screen.

Many of the .pas files have grown over the years to become unwieldy, and would ideally be broken down into more manageable chunks with more meaningful names. But that's a lot of work which doesn't advance the functionality one inch, which means it looks to me more like work than hobby, and gets left as it is. :)

The above applies to the original files as uploaded by me in 2018/2019. I think Graeme and Alistair may have re-arranged some of it, but making sense of the Github stuff is beyond me.

Ask me again if you need more. All the code you can see is now over 5 years old. Templot today has moved on a long way, not least with the 3D exports for 3D printing. I'm intending to upload the current version of everything soon, but preparing all the files for open-source is a lot of work.

p.s. see also this recent topic:

https://85a.uk/templot/club/index.php?threads/open-source-again.839/

cheers,

Martin.
 
_______________
message ref: 11253
I thought I'd report in on progress after a few months of effort, bearing in mind my first (and so far, only) requirement is to ensure Martin is not disturbed.

In order to study (and attempt to build) Templot I have installed Lazarus v3.2, Delphi 11 Community Edition and Pascal and Omni Pascal extensions to Visual Studio Code.

So far, my biggest issues is the lack of time I've been able to devote to this, along with my complete ignorance of Pascal, the application itself and additional 'stuff' needed to compile the application.

First, Lazarus. The build instructions for v2.0.10 don't translate to v3.2 - HTMLViewer is missing, for example.

Delphi 11's IDE is much easier to use, albeit throwing errors with //{$MODE Delphi} directives, amongst other things.

VS Code extensions help reveal other issues as it validates syntax without the need to compile the code.

Here are two examples:

shove_timber.pas line 188 contains a string const that is truncated, missing the terminating semi-colon
I cannot find a definition for LCLType. I assume it's defined in one of the other packages.

Martin, sorry to bother you, but I'd appreciate your thoughts on my continuing to work on what is a six-year old codebase, and discuss options, whether through this forum and/or on a zoom call.
 
_______________
message ref: 11258
@NoIdea @nickom

Hi Martin,

Thanks for continuing to look at this. Don't worry too much about disturbing me, I'm not always bad-tempered. :)

LCLType appears to be a Lazarus unit, which isn't any part of Templot or Delphi. I don't have any memory of adding it to the interface uses sections, but I obviously did so to get it running in Lazarus. But I have found this comment:

{Important: Be sure to list LclType after SysUtils and Classes in order to use LclType's THandle declaration (32 or 64 bits)
rather than THandle in SysUtils and Classes (=System.THandle, which apparently is always 32 bits).}


I've looked at shove_timber.pas in the original upload (attached below).

At line 182, the terminating semi-colon is on line 323:

Code:
const
    shovetimb_help_str:string='green_panel_begintree.gif These help notes are longer than most -- you may prefer to print them out. Click the `0PRINT`1 button above.green_panel_end'

  +'|      `0Shoving  Timbers  and  Sleepers`9'

  +'||Templot0 normally draws templates with the timbers of the correct sizes and in positions based on full-size railway practice, or in accordance with your size and spacing settings.'
  +'||The SHOVE functions permit you to change the position, alignment and size of individual timbers and sleepers within the control template, or to omit them from the template.'

  +'||"Timbers" are normally used for pointwork (switches, crossings and turnouts). The standard timber size for British standard-gauge railways is 12 inches wide by 6 inches thick. In Templot0 their numbers are prefixed S, T or X.'
  +'||"Sleepers" are normally used for plain track. The standard sleeper size for British standard-gauge railways is 10 inches wide by 5 inches thick. In Templot0 their numbers are prefixed A, B, E, J, N or R.'
  +'||The length of timbers varies as required to support the rails. Sleepers are normally of a standard fixed length,'
  +' typically 9ft in the pre-grouping era and 8ft 6ins later. Sleepers can be shortened, but it is not usual for them to be longer than this; a timber would be used instead.'
  +' For more information, see the help notes for the REAL > TIMBERING > TIMBERING DATA... menu item.'

  +'||You can shove or omit as many sleepers and timbers as you wish, or add additional "bonus timbers" to a template.'
  +'||Some of the reasons you might want to do this are these:'
  +'||Timbers may be shoved along the track to increase the space for point-rodding runs, etc.'
  +'||Timbers may be shoved along and/or twisted slightly to avoid conflicts where tracks come together in crossovers, junctions, etc.'
  +'||A minimum timber spacing of 2ft (centre-to-centre) is needed for rail joints and fishplates.'
  +'||Lengthened timbers can be used to support hand point-lever boxes, ground signals and detection devices, etc.'
  +'||Wider than standard timbers are sometimes used when this is necessary to accommodate chairs or baseplates which are offset or set at an angle.'
  +'||In the pre-grouping era, some railways used 12 inch wide timbers in place of standard sleepers adjacent to the rail joints in plain track.'


... lines removed to fit forum post size limit ...


  +'||Using the mouse actions for shoving will also enable the FULL MOUSE DRAW screen refresh option so that you can see the timbers being shoved.'
  +' You may want to revert to the skeleton draw option when you have finished shoving timbers. To do this select the ACTION > MOUSE ACTION OPTIONS > SKELETON MOUSE DRAW menu item or SHIFT+CTRL-F12, or just press the ; (semi-colon) key.'

  +'||Bonus timbers are not affected by any blanking of turnout templates and unlike ordinary timbers they can be shoved into the blanked area.'
  +'||Bonus timbers and plain track sleepers can be shoved out beyond the CTRL-0 template datum end position if necessary.'
  +'||To shove an ordinary turnout timber out beyond the CTRL-0 datum end of a turnout template, it is first necessary to apply sufficient negative blanking to accommodate the shove.'
  +' This can be done by moving the fixing peg out as far as needed (CTRL-F8 mouse action), and then clicking the DO > BLANK UP TO PEG menu item.';

Martin, sorry to bother you, but I'd appreciate your thoughts on my continuing to work on what is a six-year old codebase, and discuss options, whether through this forum and/or on a zoom call.

I'm happy to discuss this here, you are not bothering me. But I'm wondering if it might be better to wait until I have released the current code as open-source, which I intend to do shortly. Rather than looking at the old code which includes modifications for Lazarus as it then was, and may no longer apply.

I know the HTMLViewer package is a thorny issue, I remember battling with it back then. The problem is that I originally obtained it from David Baldwin before he made it open-source, and before it was integrated natively into both Delphi and Lazarus. Which means the Templot integration still works fine, but doesn't necessarily translate into current Lazarus or Delphi11.

If you are trying to get Templot to run in Delphi11, a significant problem is that its default strings are 16-bit unicode. Templot has strings of 8-bit ASCII, which in places are treated as byte arrays. Lazarus defaults to compatible 8-bit unicode, so that works ok.

cheers,

Martin.
 

Attachments

  • templot_mec_292a_10_12_2019.zip
    3.2 MB · Views: 4
_______________
message ref: 11260
But I'm wondering if it might be better to wait until I have released the current code as open-source, which I intend to do shortly.

Aha! That makes sense. Will the open-source version still require external closed-source dependencies due to licensing issues?
 
_______________
message ref: 11261
Aha! That makes sense. Will the open-source version still require external closed-source dependencies due to licensing issues?
@NoIdea

Hi Martin,

I'm not too clear what "external closed-source dependencies" are, but before releasing the files I shall simply remove the 3rd party stuff which I'm not free to publish, and replace it with comments. I'm in two minds about releasing the sketchboard stuff. I will try to get in touch with Nils and see what his current situation is.

This time I'm not intending to release a working version which will compile and run in Lazarus, it is too much work. I shall simply post the existing Delphi5 files as-is. Just doing that is a lot of work -- 160 files requiring tidying up and updated copyright notices.

cheers,

Martin.
 
_______________
message ref: 11262
Thanks Martin,

I'm not certain that the version I'm working on is the original you 1st posted, I would prefer to work on your master version considering that all future versions you may release will roll back all the changes made by Graham and Alistair anyway.

Its going to take me a long time to get my head around this, but its very interesting.

I've downloaded the Delphi community edition, do you think this would be compatible with future versions you may release to the opensource community. It has a 1 year timer bearing down on me which is a bit annoying but if it works it could be a better option as it would save you the hassle of converting from Delphi to Lazarus each time you released a version.

Regards
Nick
 
_______________
message ref: 11266
Thanks Martin,

I'm not certain that the version I'm working on is the original you 1st posted, I would prefer to work on your master version considering that all future versions you may release will roll back all the changes made by Graham and Alistair anyway.

Its going to take me a long time to get my head around this, but its very interesting.

I've downloaded the Delphi community edition, do you think this would be compatible with future versions you may release to the opensource community. It has a 1 year timer bearing down on me which is a bit annoying but if it works it could be a better option as it would save you the hassle of converting from Delphi to Lazarus each time you released a version.

Regards
Nick
@nickom

Hi Nick,

If you are trying to get Templot to run in the Delphi Community Edition, a significant problem is that modern Delphi defaults strings to 16-bit unicode. At least, I think it still does that. Templot has strings of 8-bit ASCII, which in places are treated as byte arrays, which will fail. Lazarus defaults to compatible 8-bit unicode, so that works ok.

There might be compiler directives to treat the default string type as 8-bit, but I'm not sure.

If using the Delphi Community Edition bear in mind that Embarcadero can be quite aggressive in protecting the licence terms -- I had a stroppy email all but accusing me of using it commercially, even though I had done no more with it than download it and have a look at it. So I deleted it and haven't looked at it since. If you make any code that you wish to keep, bear in mind that there is no guarantee that they will renew the licence after 12 months.

I'm going to merge this topic shortly with the other one which has come alive today:

https://85a.uk/templot/club/index.php?threads/open-source-again.839/

as both you and Martin are covering mostly the same ground.

Attached below is the old code as I last released it. At that time I ensured that it could be compiled and run in Lazarus, following the instructions in the old links. But Lazarus has been upgraded since then, so I'm not sure of the present situation. Going forward I shall be releasing the Delphi5 code exactly as-is -- I'm too old and tired now to repeat all the work of creating two versions, and I need to spend my time on the unfinished 3D chairing stuff.

cheers,

Martin.
 

Attachments

  • templot_mec_292a_10_12_2019.zip
    3.2 MB · Views: 1
_______________
message ref: 11267
Hi Martin, @NoIdea All

What is the view on taking this forward? What do we want to achieve out of this?
My tuppence worth is:
  1. Find ways to ease the support burden Martin is constantly under.
  2. Out of respect to Martin, both technical and frankly just respect for the huge effort put into this over decades
    1. We need to preserve the original technical and UI workings of Templot, I assume a fairly large group of users rely on it?
    2. This will aid in merging future features into the open-source version.
  3. In the longer term, find a way to retain the above but make it accessible to people who are more used to Windows UI's, although I think this is a shrinking group of people since the emergence of icon-based apps on tablets and phones.
    1. Do we need to even consider this? Should we stick with what works and has worked perfectly well for decades?
  4. Slowly introduce modern coding techniques where they are deemed necessary to aid in the wider developer-volunteer community
  5. To keep this free, we need to consider the toolchain.
    1. Lazarus with free Pascal is an obvious IDE, but it is an obstacle to introducing new features from the primary codebase.
    2. Delphi would is a good option (assuming the 8-bit ASCII to 16-bit unicode hurdle can be handled, plus other incompatibilities)
      1. it is prohibitively expensive; this will only hinder the wider involvement of volunteers
    3. Very slowly, port over to another language.
      1. I am not sure if this is possible, and I will still have difficulties converting from Delphi 5 to whatever; I guess, eventually, we will be merging new features and upgrades, so the effort could reduce.
I have no idea how we do this at this stage, but I'm willing to have a go.

Martin, As the Chief Architect and, of course, owner of Templot, what / how would you like to see it progress?
 
_______________
message ref: 11270
Hi Martin, @NoIdea All

What is the view on taking this forward? What do we want to achieve out of this?
My tuppence worth is:
  1. Find ways to ease the support burden Martin is constantly under.
  2. Out of respect to Martin, both technical and frankly just respect for the huge effort put into this over decades
    1. We need to preserve the original technical and UI workings of Templot, I assume a fairly large group of users rely on it?
    2. This will aid in merging future features into the open-source version.
  3. In the longer term, find a way to retain the above but make it accessible to people who are more used to Windows UI's, although I think this is a shrinking group of people since the emergence of icon-based apps on tablets and phones.
    1. Do we need to even consider this? Should we stick with what works and has worked perfectly well for decades?
  4. Slowly introduce modern coding techniques where they are deemed necessary to aid in the wider developer-volunteer community
  5. To keep this free, we need to consider the toolchain.
    1. Lazarus with free Pascal is an obvious IDE, but it is an obstacle to introducing new features from the primary codebase.
    2. Delphi would is a good option (assuming the 8-bit ASCII to 16-bit unicode hurdle can be handled, plus other incompatibilities)
      1. it is prohibitively expensive; this will only hinder the wider involvement of volunteers
    3. Very slowly, port over to another language.
      1. I am not sure if this is possible, and I will still have difficulties converting from Delphi 5 to whatever; I guess, eventually, we will be merging new features and upgrades, so the effort could reduce.
I have no idea how we do this at this stage, but I'm willing to have a go.

Martin, As the Chief Architect and, of course, owner of Templot, what / how would you like to see it progress?
@nickom @NoIdea @James Walters

Hi Nick,

Thanks for that. I like the idea of being called Chief Architect. :) But it suggests there is some grand design here, which is definitely not the case. Chief Cobbler-together would be nearer the mark!

My main concerns are:

1. Many folks are relying on Templot, sometimes for lifetime projects. I would like to know that it will continue to be available (and preferably developed further) if anything happens to me. I don't just mean the dreaded bus -- recently I fell and smashed my shoulder badly, I could easily have hit my head at the same time. The grey cells are dying off fast enough, without having chunks knocked out of them.

2. There is still a long way to go with Templot. The 3D plug track looks like becoming a popular feature but there is still much to do, and folks are waiting for the next steps. Some help with it would be very welcome, and has been kindly offered. But an STL file for a chair isn't much help without some lines of code showing how I would integrate it into Templot, and modify it when required to match changing crossing angles and flangeway gaps, etc. It needs chair creation code written similarly to the existing chairs, and it's going to be a long time coming if I have to do it all myself.

For a long time I assumed that eventually a young software engineer would turn up -- an experienced Templot user with a good knowledge of railway track -- and create a complete replacement for Templot starting with a blank sheet of paper and doing everything properly from the start. But I've been told several times that it just isn't going to happen.

Meanwhile we plod on, using a program tied together with string, still using some code and methodology which started life on a programmable calculator in 1979.

3. I still enjoy writing code, even though I'm much slower now than I used to be. But the task of endlessly explaining it does become exhausting. More than once recently I have left out function options which might occasionally be useful, because I just can't face the task of explaining them.



How all that feeds in to your thoughts for the open source version is far from clear. At first sight an obvious move would be to switch the entire thing, including Templot2, from Delphi5 to Lazarus.

But there are problems:

Several of the 3rd party components were written for Delphi and are unlikely to work in Lazarus. I know Graeme was trying to find replacements, but I don't think he got very far.

The Windows EMF metafile format is integral to much of Templot, especially the sketchboard, and Lazarus doesn't include the relevant Delphi-style wrappers for the Windows API. I managed to get it working in Lazarus by calling the API functions directly, but whether that still works in the latest versions I'm not sure. I know there is nothing comparable on the Apple platform, so it's likely to fall by the wayside on most other platforms in favour of the SVG format.

The BOX file format is a binary format, and most floats in Templot use the Win-32 Extended 10-byte floating-point format. This isn't supported in Lazarus (or Win-64), which means hundreds of users' legacy BOX files would become unusable. Graeme was working on a conversion utility, and for a while Templot2 included an XML-based alternative file-saving format. But maintaining it was too much work, users found it confusing, and I just couldn't face continually explaining it.

For now I think we should update the name to say OpenTemplot2024 to make a fresh start after all the previous ins and outs. I will make a start in posting the current Delphi5 files in the next few days.

Thanks again,

Martin.
 
_______________
message ref: 11272
Back
Top