Incorrect Proc being called ???

[J-G]

Due to the changing energy prices I'm updating my project which keeps a record of my costs. The first thing I feel is sensible is to change some static arrays to dynamic. Two (out of three) were straightforward but the third is causing me some grief!

The arrays are concerned with energy tariffs  -  Gas, Electric & Solar Panel  - so naturally I have three small procedures to save each array to a (separate) file  -  viz.

Code: Pascal  [Select][+][-]

1. procedure SaveElecRates;
2. Var
3.   i : byte;
4. begin
5.   rewrite(ElecRates);
6.   for i := 1 to MaxERec do
7.       write(ElecRates,ElecList[i]);
8.   close(ElecRates);
9. end;
10. procedure SaveGasRates;
11. Var
12.   i : byte;
13. begin
14.   rewrite(Gas_Rates);
15.   for i := 1 to MaxGRec do
16.       write(Gas_Rates,Gas_List[i]);
17.   close(Gas_Rates);
18. end;
19. procedure SaveFiTRates;
20. Var
21.   i : byte;
22. begin
23.   rewrite(FiT_Rates);
24.   for i := 1 to MaxFRec do
25.       write(Fit_Rates,Fit_List[i]);
26.   close(FiT_Rates);
27. end;

Nothing extraordinary I'm sure you'll agree.

However, I've converted Solar (FiT) & Gas without a hitch but the call to SaveElecRates actually goes to SaveGasRates.   The CallStack shows the line number for the Gas Proc.  ???

I've saved the source, closed Lazarus, reopened and it continues to call Gas not Elec.

Can anyone suggest why this might be ?

Here is the 'calling' code:

Code: Pascal  [Select][+][-]

1.   procedure ReadElec;
2.   Var
3.     i: word;
4.   begin
5.     {$I-} reset(ElecFile); {$I+}
6. [...]
7.         while not eof(ElecRates) do
8.           begin
9. [...]
10.             read(ElecRates,ElecList[i]);
11. [...]
12.                   inc(i);
13.           end;
14.  
15.          close(ElecRates);     //  one off - conversion from Static to Dynamic Array
16.          SaveElecRates;
17.  

[dseligo]

One thing I usually do when something strange as this is going on, is to do project 'Clean up and Build' (but I must admit that doesn't help in most cases, because the reason is my error somewhere in the project).

You mention you changed from static to dynamic arrays.
But your code is like this:

Code: Pascal  [Select][+][-]

1. for i := 1 to MaxERec do

Dynamic arrays goes from 0 to array length - 1. Check if you didn't make some error with array indexing.

And I usually use CloseFile instead of Close.

[Arioch]

any array - dynamic, static, open, generic - any - goes as

Code: Pascal  [Select][+][-]

1. var
2.   data: TArray<string>;
3.   index: integer; item: string;
4. begin
5.    
6.   for index := Low(Data) to High(Data) do
7.       xxx(data[index]);
8.  
9.    
10.   for item in Data do
11.       xxx(item);
12.  

Andyou don't need to think about and memorize those constants any more

[MarkMLl]

One thing I usually do when something strange as this is going on, is to do project 'Clean up and Build'

Yes, definitely. There's an issue lurking in the compiler related to multi-unit rebuilds etc. that nobody's been able to duplicate to an adequate extent.

MarkMLl

[wp]

Code: Pascal  [Select][+][-]

1.   procedure ReadElec;
2.   Var
3.     i: word;
4.   begin
5.     {$I-} reset(ElecFile); {$I+}
6. [...]
7.         while not eof(ElecRates) do
8.           begin
9. [...]
10.             read(ElecRates,ElecList[i]);
11. [...]
12.                   inc(i);
13.           end;
14.  
15.          close(ElecRates);     //  one off - conversion from Static to Dynamic Array
16.          SaveElecRates;
17.  

Unless you did this somewhere else, I am missing a call to SetLength() here (as well as initialization of the count variable i). Since you probably do not know how many items will be found in the files you have to do this continually while reading, or in blocks. Here is the block solution:

Code: Pascal  [Select][+][-]

1. const
2.   BLOCK_SIZE = 1000;
3. var
4.   i: Integer;
5. begin
6.   Reset(ElecRates);
7.   i := 0;
8.   while not EoF(ElecRates) do
9.   begin
10.     // When a block is full allocate another one. Each block consists of BLOCK_SIZE elements.
11.     if i mod BLOCK_SIZE = 0 then
12.       SetLength(ElecList, Length(ElecList) + BLOCK_SIZE);
13.     Read(ElecRates, ElecList[i]);  // Using Read rather than ReadLn means that all elements are in a single line. Is this true?
14.     inc(i);
15.   end;
16.   CloseFile(ElecRates);
17.   // Remove the excess-allocated elements. i is the true number of elements.
18.   SetLength(ElecList, i);
19. end;

[J-G]

One thing I usually do when something strange as this is going on, is to do project 'Clean up and Build' (but I must admit that doesn't help in most cases, because the reason is my error somewhere in the project).

You mention you changed from static to dynamic arrays.
But your code is like this:

Code: Pascal  [Select][+][-]

1. for i := 1 to MaxERec do

Dynamic arrays goes from 0 to array length - 1. Check if you didn't make some error with array indexing.

And I usually use CloseFile instead of Close.

I haven't yet tried a 'Clean up and Build'  -  It's taken me all this time to recover from the silly error that you pointed out   @dseligo

I HAD taken account of the fact that dynamic arrays are Zero based EXCEPT when it came to the [Save] section !!  D'oh!   -  I've had to 'knife and fork' my code to recover the data (I did lose a couple of records but I have a separate note of those so can re-enter the info).

It occured to me that the 'shift' in the array addressing might have been responsible for the incorrect calling (possibly due to some memory being over-written)  but now I'm back to the position where the 'Electric' Array needs to be saved I find that it is still calling the 'Gas' save proc.

I've never needed to do anything other than use [F9] to compile & run a project and looking at the options under [Run] I'm still a little unsure about my next test. Should it be [Run][Clean up and Build],  [Ctrl][F9]  or [Shift][F9]  -  that may sound naïve but I'm being ultra cautious 

[wp]

I've never needed to do anything other than use [F9] to compile & run a project and looking at the options under [Run] I'm still a little unsure about my next test. Should it be [Run][Clean up and Build],  [Ctrl][F9]  or [Shift][F9]  -  that may sound naïve but I'm being ultra cautious 

I normally I use [F9]. When I change something and it seems that the compiler did not notice it (for example, when I only change a property in the OI, or when I change an included resource) --> [Shift][F9] (Build)

I rarely use the others (sometimes [Clean up and Build] mainly out of dispair...).

[MarkMLl]

I normally I use [F9]. When I change something and it seems that the compiler did not notice it (for example, when I only change a property in the OI, or when I change an included resource) --> [Shift][F9] (Build)

I rarely use the others (sometimes [Clean up and Build] mainly out of dispair...).

There are definitely poorly-understood situations where one needs to do a File -> Clean Directory... (and accept the defaults) before a Compile or even a Build. When this has been discussed in the past it's been hypothesised to be related to unit names with a relative path.

https://forum.lazarus.freepascal.org/index.php/topic,59512.msg444219.html#msg444219 https://forum.lazarus.freepascal.org/index.php/topic,53028.0.html plus a few other places. Seems to need a "nuke from space" to fix.

MarkMLl

[J-G]

After some further testing - - - -   Still no 'joy' 

I opened the project in Laz 1.6 and again (naturally) walked through the code and it correctly called the SaveElec proc. - rather than continuing with the [save], which would have destroyed the means of testing further, I aborted the run and re-opened in Laz 2.2.  This told me that a change had occured  -  probably due to a time stamp rather than an edit  -  and I allowed a re-open (clutching at straws!)  -  Stepping through again the call from SaveElec still goes to Save Gas 

Next test was    [Shift][F9]  -  [F9]  -  no change

Next     [Run][Clean up and Build]  - [F9]  -  no change

  

Now I can complete the conversion to Dynamic Arrays under Laz 1.6 because this part of the code normally only [Reads] the data (I've added the call to [Save] simply for the conversion) - the [Writing] part is normally there only for a first run, to create the data files -  but naturally I'm somewhat reluctant to trust that there won't be some issue still lurking.

The problem does seem to be connected with something in Laz 2.2 but I cannot hazzard a guess as to where.

[J-G]

Curiouser and Curiouser !!

The section of code which I'm updating is concerned with reading the data but naturally I also need to [Edit] the data as and when rates change. This means that I also have a [Save button] which has an 'Event' attached and this simlpy calls the approriate [Save] proc.

Changing the update code to call this 'Event' does work (though I did have to fathom what TObject needed to be sent  ???  -  Self & Sender failed but Form1 was acceptable,  why ?  I have no idea )  but the call then again goes to SaveGas !!  ???   

If I put the [Save] code directly in the [Save button] 'Event' the ElecFile IS saved!

[dseligo]

I opened the project in Laz 1.6 and again (naturally) walked through the code and it correctly called the SaveElec proc.

So you use Lazarus 1.6 and 2.2 in same directory? Try to copy your entire project to new directory, delete anything you don't need to compile (i.e. all subdirectories) and try to compile and test it *only* with 2.2.
Do you have any units you use outside of project directory?

Try to change name of procedure SaveElecRates (to SaveElecRatesTest e.g.). Try to compile it and after Lazarus complains that SaveElecRates doesn't exists change name in places you call it.

[wp]

So you use Lazarus 1.6 and 2.2 in same directory?

dseligo's idea to copy the project into a new directory so that it is opened only by one Lazarus version is absolutely safe, in particular for unexperienced users. However, any further development becomes extremely complicated now because you must maintain two source versions!

Normally, it is no problem to compile the same sources with different Lazarus versions - I do this very often. The only issue is when the newer Lazarus version introduces new properties that are not available in the older version. In this case the older version cannot open the project any more. If the new property has a default value I load the project in the new version, reset the conflicting properties to their default value so that they are not written to the lfm file and set their needed value in code, usually in the OnCreate event of the form. If the property has no default value I delete the component and create it at runtime.

[dseligo]

So you use Lazarus 1.6 and 2.2 in same directory?

dseligo's idea to copy the project into a new directory so that it is opened only by one Lazarus version is absolutely safe, in particular for unexperienced users. However, any further development becomes extremely complicated now because you must maintain two source versions!

I suggested it only to try to troubleshoot his problem.

[J-G]

I opened the project in Laz 1.6 and again (naturally) walked through the code and it correctly called the SaveElec proc.

So you use Lazarus 1.6 and 2.2 in same directory? Try to copy your entire project to new directory, delete anything you don't need to compile (i.e. all subdirectories) and try to compile and test it *only* with 2.2.

That's probably a good next step -- it will take me some time I suspect.

[Edit]  -  I'm reasured by WP's comments though

Do you have any units you use outside of project directory?

Other than Laz or FPC Units  -  no.

Try to change name of procedure SaveElecRates (to SaveElecRatesTest e.g.). Try to compile it and after Lazarus complains that SaveElecRates doesn't exists change name in places you call it.

I ought to have thought of that 

Re-naming had no effect  BUT

Moving it to a new location - relative to the SaveGas proc.  -  has solved the problem !!

I used to have :

Code: Pascal  [Select][+][-]

1. 709 procedure SaveFiTRates;
2. 722 procedure SaveElecRates;
3. 735 procedure SaveGasRates;
4.  
5. 749 procedure Save_MetSubFile;
6. [...]
7.  

Now I have :

Code: Pascal  [Select][+][-]

1. 709 procedure SaveFiTRates;
2. // 722 procedure SaveElecRates;
3. 735 procedure SaveGasRates;
4.  
5. 749 procedure Save_MetSubFile;
6. [...]
7. 1176 procedure OpenCSVFile(FN : String);
8. 1184 procedure Save_E_Rates;
9.  

... and the call to Save_E_Rates does go there! 

I must learn to 'look ahead' before I concider project modifications

Thanks for the support and feedback - as usual eventually productive   (why don't we have an 'appluse' emoji ?)

ps    in response to posting whilst I was typing ...
@dseligo  -  and your suggestion is greatly appreciated.

[EDIT]
  I may have spoken too soon    

  still working on it . . . . .

[bytebites]

Set break point and see where it goes.