File Access Problem

[Idas]

Hi everyone,

I got a simulation program (it is a console application) written in Pascal. I would like to change some of the parameters during the simulation.
The simulation process is a while-loop which runs from t to tmax.
So my plan was to have a txt-file which is read at first in the while-loop:

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

1. {$I-}
2.  Assign(IUpdate, 'InputUpdate.txt');
3.  reset(IUpdate);
4. {$I+}
5.  Filfejl := IOresult;
6.  if Filfejl <> 0 then
7.  begin
8.     Write('Error with InputUpdate.txt', LF);
9.     halt;
10.  end;
11. doInputUpdate(IUpdate);
12. Close(IUpdate);
13.  

doInputUpdate:

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

1.   procedure doInputUpdate(var F: Text);
2.   begin
3.       //Header
4.       readln(F);
5.       readln(F);
6.       //RotNac
7.       readln(F, IXNAV, IYNAV, IZNAV);
8.       readln(F, KGAX, KGAY, KTORS);
9.       readln(F, IGEN, Ngear);
10.       readln(F, IXKAB, IYKAB, IZKAB);
11.       readln(F, KTX, KKY);
12.   end;
13.  

Parallel I wanted open the txt-file in my editor, change something and safe the changes. But when I try to safe my changes the simulation crashes and I get "Error with InputUpdate.txt".

Is it possible to do what I want and if yes, anybody got an idea how? Thank you all!

[Handoko]

If the changed data does not alter how the simulator works for example the lines count and tMax then I think the simulator should load all the data at once into memory and close it immediately before start doing the loop. You can use a TStringList or maybe array of string to store the data. And the doInputUpdate needs to open the file, go the the line number (that provided by the simulator), read the data and close it immediately on each loop cycle.

Alternatively, you can consider to use a database that support multi read and write on the same time.

[Bart]

If you open the text file in another program at the same time, the file may get locked by that other process.
In your error line, you could write down the IOResult, so you can see what the problem is.
And you can set the exitcode to your program to the same result.

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

1.  if Filfejl <> 0 then
2.  begin
3.     Write('Error with InputUpdate.txt: ErrorCode=',Filfejl);
4.     halt(Filfejl);
5.  end;

Bart

[Idas]

Thank you for the help so far.

My IOResult is 5. That means "Access denied". So the Editor with which I open the txt-file locks it and the simulation program can not read from that file anymore.
Did I get that right?

[winni]

Hi!

Yes, that is true.


Read you file into a Memo.

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

1. Memo.Lines.LoadFromFile ('MyFile');

Edit the parameters as you like.

Read the parameters for DoInputUpdate from the Memo.

Finally save your parameters with

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

1. Memo.lines.saveToFile (MyNewFile);

Winni

[Idas]

Thank you for the idea, Winni.
I tried to implement it for the past week. I am fairly new to Lazarus and it is my first time using the libraries tform and tmemo.


To use tmemo I build a very simple GUI for the console application I would like to modify. The GUI consits of a tmemo field and a button. When you click the button the original console application starts. That works fine. But my problem is that during the time the console application is executed the GUI is not responding.


A friend of mine suggested to execute the console app in a new thread. Is he right or is there another way?

[MarkMLl]

A friend of mine suggested to execute the console app in a new thread. Is he right or is there another way?

Use TProcess if you really do want both running at the same time. A thread is really intended for situations where you want to separate activities to be going on in the same program.

An old trick for having a program reload its configuration is for it to execute a new (child) copy of itself with the parent then terminating. However you really do need to give some consideration to what bits you want running sequentially and what bits simultaneously, to whether you want to embed the console app in a window of the graphical one and so on. And some details- for example how to tell a program to terminate itself- will differ depending on what OS you're using (which is a hint that you should have included that info with your initial question).

MarkMLl

[Idas]

Thank you for your feedback, I try to be more precise.

I work with windows 10.

I try to modify an old simulation programm which is an console application. It roughly looks like this.

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

1. Program SimForce;
2.  
3. {$APPTYPE CONSOLE}
4.  
5. uses
6.   ...
7. const
8.   ...
9. var
10.   ...
11.  
12. begin // SimForce main
13.  
14. Initalize;
15.  
16. repeat
17.  
18.     Calculation;
19.  
20. until T >= TMAX;
21.  
22. end.
23.  
24.  

To use TMemo I changed it to have a very simple GUI

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

1. unit SimForce;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   ...
9. const
10.   ...
11.  
12. type
13.  
14.   { SimForce_GUI }
15.  
16.   SimForce_GUI = class(TForm)
17.     Button1: TButton;
18.     Button2: TButton;
19.     InUpMemo: TMemo;
20.     procedure Button1Click(Sender: TObject);
21.     procedure Button2Click(Sender: TObject);
22.   private
23.     { private declarations }
24.   public
25.     { public declarations }
26.   end;
27.  
28. var
29.   ...
30.  
31. implementation
32.  
33. {$R *.lfm}
34.  
35.  // SimForce main
36. procedure SimForceMain;
37. begin
38.  
39. //To use console
40. AllocConsole;    
41. IsConsole := True;
42. SysInitStdIO;      
43.  
44. Initalize;
45.  
46. repeat
47.  
48.     Calculation;
49.  
50. until T >= TMAX;
51.  
52. end;
53.  
54. { SimForce_GUI }
55.  
56. procedure SimForce_GUI_GUI.Button1Click(Sender: TObject);
57. begin
58.    SimForce_GUI.InUpMemo.Lines.LoadFromFile('InputUpdate.txt');
59.    SimForceMain;
60. end;
61.  
62. procedure TInUp_GUI.Button2Click(Sender: TObject);
63. begin
64.   submit := true;
65. end
66.  
67. end.
68.  

My problem is when i press Button1 the simulation starts but the GUI is not responding anymore until the simulation is finished.

I don't know where the problem is. Thank you in advance for your help!

I attached a picture of the GUI as it is not responding.

[MarkMLl]

Put an Application.ProcessMessages in your main loop, so that it's called something like 10 times a second- more often than that is unneccessary and inefficient.

MarkMLl

[Idas]

Thank you! It worked 

[Paolo]

If you use Application.ProcessMessages do not forget to disable the button you have pressed until the long run is ended.

[MarkMLl]

If you use Application.ProcessMessages do not forget to disable the button you have pressed until the long run is ended.

Yes, I agree. There's also useful variants of that philosophy like EXPLICITLY disabling timers while the handler is running... having APM go recursive can be nasty.

MarkMLl