[Therion] Invalid length reading error reported due to (valid) scrap definition

[Benedikt Hallinger]

Hm, I'm not sure this will not trigger alot of false positives in some 
of my projects, where structure is heavily divided into smaller files 
which are inputted to form a whole complete.

But I want to second you: the error message shown is very not-intuitive 
to find the root cause.
So maybe we should add some syntax sanity checks to the overall 
strcture. When an encenterline is missing somewhere, this is some sort 
of unbalanced braces problem like in a C compiler; so mabye therion 
should output at the end that there is unbalanced 
centerline/endcenterline numbers (or all other such structures, in this 
regard) in the input data.


Am 2023-08-07 7:38, schrieb Bruce Mutton:
> OK, found it.  It was as I suspected a missing endcentreline in the
> file called by an input statement immediately preceding the statement
> 'input 11-DeerPlan.th2'.
> 
> So my mistake, I did not check as well as I thought I had.
> 
> I wonder if Therion could check for endcentreline statements (where
> they might normally be expected) and if not found by the end of a
> file, then issue a warning "missing endcentreline in file xxx.th".
> 
> Thanks
> 
> Bruce
> 
> From: Therion <therion-bounces at speleo.sk> On Behalf Of Bruce Mutton
> Sent: Monday, 7 August 2023 15:36
> To: 'List for Therion users' <therion at speleo.sk>
> Subject: [Therion] Invalid length reading error reported due to
> (valid) scrap definition
> 
> Hello
> 
> I have a perplexing error, this time around after a complicated git
> merge, and I have had similar on one occasion a while back.
> 
> I think I resolved by omitting the file, which is not really a
> resolution.  This time I need a better solution!
> 
> On compiling a thconfig I get an error:
> 
> C:\Program Files (x86)\Therion\therion.exe: error -- 11-DeerPlan.th2
> [8] -- invalid length reading -- -projection
> 
> The start of file 11-DeerPlan.th2 is like this:
> 
> encoding  utf-8
> 
> ##XTHERION## xth_me_area_adjust -160.83 -127.28 965.01 763.65
> 
> ##XTHERION## xth_me_area_zoom_to 200
> 
> ##XTHERION## xth_me_image_insert {502.386220472 1 1.0} {626.342677165
> 11.8} ptopoDeer/11-Deer_p.xvi 0 {}
> 
> scrap 11-DeerPlan-s1 -projection plan -station-names []@11 -author
> 2023.02.26 "B Mutton" -copyright 2023 NZSS -scale [0 0 787.4 787.4 0 0
> 10 10 m]
> 
> point 10.25 711.5 label -text "Deer Pot" -align l -scale xl
> 
> point 186.25 712.5 anchor -align r
> 
> This is a well established scrap in a well established file in a well
> established project and both of the parent branches compiled without
> issue through many editing and versioning iterations.  Comparison with
> both of the parent git branches do not suggest any changes that should
> trigger such an error - at least I have not found it yet.
> 
> I have checked this file and all calling it for closed blocks (scrap
> endscrap, map endmap, centreline endcentreline, survey end survey etc)
> because long ago Therion used to complain in a similar manner if such
> blocks were not closed (reporting survey data type error due to a
> drawing file error - illogical).
> 
> Since this is the second time in a month I've experienced this type of
> 'illogical' error after nothing like it for years, I'm wondering if
> anyone else has, or has a clue as to what might be happening?
> 
> Bruce
> 
> Using:
> 
> therion 6.1.8 (2023-06-14)
> 
> Windows 10 Home 22H2
> 
> GitHub desktop 3.2.7 (x64)
> 
> TortoiseGit 2.14.0
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> https://mailman.speleo.sk/listinfo/therion