Lazarus

Free Pascal => Beginners => Topic started by: zz28zz on June 20, 2019, 03:23:07 am

Title: Stopping a program
Post by: zz28zz on June 20, 2019, 03:23:07 am
Hi
Newbe here with a question.  Yes , I'm in waay over my head.

I need to know what to insert in the s/w that will make it stop at a certain point. The s/w was written in BP abt 25 years ago.

The issue I'm having is with s/w that controls a tester. If a oddball module is installed, I get an error during initialization. I know which file is running but not sure at what point in the file that the error occurs.  I need to insert what ever it is (hook?,test point?) so the file stops running at that point. If the s/w stops, before the error occurs I'll know to move the hook(?) further down until the error occurs. Hope this makes sense.
I have the source code and I'm able to compile.

Thx!
Title: Re: Stopping a program
Post by: jamie on June 20, 2019, 03:28:33 am
Yes, you need to load Lazarus and debug your program there.

Compile it with debug info and run the program from the Lazarus IDE.

 You can place a break point on the lines of source code where you may suspect an issue and
when the code gets there, you use F8 to single step each line of code and F7 to step into
a function or procedure. F9 will resume run.

Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 03:45:14 am
What does a break point look like? Is it a single character or a series of characters?

I was planning on editing the source code with a regular text editor then compile with BP which is already installed on the tester.
Will that not work?

Thx!

Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 05:08:18 am
Gave up using BP. Opened file in Lazarus and found the BREAKPOINT option under RUN. I tried adding a breakpoint then saved file, then re-opened it and I don't see any change at the line I added a breakpoint. Should I see something there?

I see 3 different types of breakpoints:
Source Breakpoint
Address Breakpoint
Data/Watch Breakpoint

Which one should I be using?
Title: Re: Stopping a program
Post by: BobS on June 20, 2019, 06:27:55 am
Just press the f5 key on the line where you want the breakpoint (press again to get rid of it).  If you do much debugging it's good to read up on the options (lot's of fun things to do like setting a watch on a variable to trigger when it hits a certain value).  Hover the mouse over variables to see their current values.
Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 07:07:05 am
Used the F5 key. Line turned red and a little balloon appeared. Used "save as" and saved it. When I re-open the file, I don't see the red line or balloon where I set it. Does this mean it isn't there anymore or it's still there but not visible?
Title: Re: Stopping a program
Post by: Thaddy on June 20, 2019, 07:52:03 am
Bookmarks and breakpoints are not saved. Nor should they be saved at all.
Title: Re: Stopping a program
Post by: incendio on June 20, 2019, 07:58:55 am
If not mistaken, breakpoints were saved in Lazarus 2.0.2 for linux.
Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 09:23:51 am
This is what I assumed that I needed to do:
1. Modify pascal source code file init.pas somehow to make it stop at a predetermined point.
2. Copy modified source code file to tester. 
3. Rename the orig init.exe to init.bak
4. Compile modified source code file on tester.. Say it was called init.pas, after being compiled, it would create a file called init.exe
5. Installed init.exe into the proper directory (if not already)
6. Attempt to initialize tester and see if the pop-up error occurs before or after s/w stops running.
7. Move stop point in source code and repeat process to zero in on what's causing error to occur.

What am I missing?
Title: Re: Stopping a program
Post by: Thaddy on June 20, 2019, 09:27:31 am
Under Windows, probably all intel/amd platforms this is quite easy:
Code: Pascal  [Select]
  1. asm int 3 end;
a.k.a. a software breakpoint.
You can decorate it with e.g. {$ifdef debug}

Reason: this can be actually in the sourcecode and is not dependent on any specific configuration or editor.
Flaw: depends on intel/amd instruction set
Title: Re: Stopping a program
Post by: BobS on June 20, 2019, 09:48:07 am
Instead of using a debugger, try just inserting some writeln statements at various points...like: writeln('at line 500');
Title: Re: Stopping a program
Post by: Martin_fr on June 20, 2019, 12:30:30 pm
Hi, first of all ensure your setup is correct: https://wiki.lazarus.freepascal.org/Debugger_Setup
Best results are usually with "dwarf with sets" setting.

What OS? 32/64 bit?

Can you test with a new project (just one or two lines of code) if the breakpoint works?

-----------
You said it might be in an unit's "initialization" section?
This may (maybe) require some extra config.
Tools > Option > DEbugger
There is a property grid, search for the entry "InternalStartBreak" and set it to "gdsbAddZero"

------------
If you have a project, then breakpoints should be saved. Please check the breakpoint window: View > Debug Windows > Breakpoints
If breakpoints are not shown in the source editor, check if there are symlinks (*nux) to the source file (or the folder). And if you open the file sometimes via the symlink and sometimes direct.
THe IDE does not know the symlinks, and this are 2 different files.
Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 06:18:17 pm
The OS on the tester is DOS 6.22..
The adding a writeln would probably do what I need. Just trying to figure out what section of the init file is causing the error to display. When the file runs, it's controlling the tester, by changing the config of relays, power supplies, DMMs, taking measurements looking up stuff from other files, etc. If any values are beyond preset limits it creates an error message. So basically, I don't think the file will run properly by itself in a simulated environment.
Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 08:02:22 pm
Nothing but errors so far while trying to compile.

I add to the file:
Begin
          writeln('line 1078');
End;

Try to compile and it says:
Init.pas(1081) : Error 94: "." expected.
End;
     ^

Do I need a "Begin" and "End;" before and after the writeln command?
Title: Re: Stopping a program
Post by: SymbolicFrank on June 20, 2019, 08:28:21 pm
The last line of your program should be:
Code: Pascal  [Select]
  1. end.
Title: Re: Stopping a program
Post by: BobS on June 20, 2019, 09:59:55 pm
You shouldn't need to add begin/end.  You should be putting the writeln statements into areas that already have those.  Put in several and you should be able to narrow down to the problem area fairly quickly.
Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 11:03:04 pm
It's in the middle of the program/file.
Title: Re: Stopping a program
Post by: BobS on June 20, 2019, 11:11:32 pm
What is?  Your problem?
If you mean where you want to insert the writeln, that's fine, but it needs to be embedded in code that will execute, you can't just stick it, say, at the top of a procedure that already has a begin/end...it needs to be somewhere between the begin and end statements (e.g. just after the begin, writeln('executing proc whatever'); .
Title: Re: Stopping a program
Post by: zz28zz on June 20, 2019, 11:47:45 pm
I was trying to place it between 2 procedures? (not sure of correct terminology) I.E. after an END and before the next BEGIN. That's why I tried adding my own BEGIN and END so it would look like the other procedures, but that didn't work.
Title: Re: Stopping a program
Post by: BobS on June 21, 2019, 12:00:06 am
Do as my previous post explained.  I really think you need to learn a bit about Pascal before you attempt to debug a 25 year old program.  Since you have Lazarus installed try some of the example programs.
Title: Re: Stopping a program
Post by: zz28zz on June 21, 2019, 01:38:19 am
BobS: When I said it's in the middle, I was talking to someone else. Thread changed pages and I missed your first reply. I fully aware I'm over my head. This obviously isn't my area of expertise. It was thrown in my lap and I was given a very short window to resolve the issue (plus a bunch of other issues).
Title: Re: Stopping a program
Post by: zz28zz on June 21, 2019, 08:57:17 pm
I got a modified version of the writeln command to work today and was able to isolate the part of the code where the error is triggered. Thx all.

It appears one of the modules is reporting that it's in an error state and that's what's triggering the onscreen errors. Still trying to find where the error state data is coming from.

Now I need to figure out how to stop the code execution and report module error status at various points during initialization. For this, I'm thinking the only person that can help is the guy that wrote the s/w and so far he's been unwilling help. What a PITA...
Title: Re: Stopping a program
Post by: jamie on June 21, 2019, 10:51:40 pm
Does this program use a Serial port of parallel printer port to talk to the devices?

if so, is it using the PORT[???] function ?
Title: Re: Stopping a program
Post by: lucamar on June 22, 2019, 01:44:14 am
Is the code propietary or under a NDA? We may be able to give better help if we could see the code.

Also, can you connect a monitor/keyboard to the tester? That may allow you to develop directly on it, if it has a 386+ and some kind of disk or disk-like storage media with enough space (about 40 MiB for a basic DOS installation of FPC).
Title: Re: Stopping a program
Post by: zz28zz on June 22, 2019, 03:34:14 am
Modules connect directly to the tester back-plane. There's 8 digital lines shared between all the modules then all 8 digital lines connect to a thru a CIC card plugged into an ISA or PCI slot on the PC motherboard.  All modules also share 8 address lines. Each module has a set of address switches and each module has a different address.
Code is proprietary.   I've signed a NDA.
No way to connect a monitor or keybd directly to tester.
Not sure what FPC is but hard drive space is very limited (i.e. ~10mB free)

A retired circuit design eng was telling me there's a way to install "checkpoints" in the code but I have no idea how that's done and he doesn't remember how. The s/w guy did all that stuff.
Title: Re: Stopping a program
Post by: BobS on June 22, 2019, 05:53:28 am
Sounds like you're working under some pretty unreasonable conditions.  What that guy was probably remembering was Turbo Debugger which was introduced in 1989.  It might even be installed on the system.

Otherwise sounds like you're stuck with the old fashioned way, in which writeln is your main friend.  Given the probable age of this program the basic structure is likely something similar to this--with some procedures and functions to do useful repetitive tasks and a main program body that has the overall logic in it (totally fake and very simplified example don't try to compile or run).
program hasaname;

function myfunc(abyte: byte): string;
   begin
     writeln('starting myfunc');
     (*executable code here*)
    (*does something really important stuff here!*)
   end;
procedure dosomething (parameter1: string; parameter2: integer);
var
  avariable, x :byte;
  ava2: string;
  y: integer;
begin
  y:=0; (*initialize y...if your luck code is well commented*)
  (*this is where the executable code is*)
  for x:=1 to 10
    do begin
      writeln('inside loop in dosomething',x);
      ava2:=myfunc(x);
     y:=y+1
   end;

var
   string1: string;
   myint: integer;
begin
  writeln('at start of main program');
  string1:='really vital string';
  myint:=103;
  (*This is the main body of the program*)
  (*Probably a bunch of executable code here*)
  writeln('About to run dosomething.  string1 =',string1,' myint=',myint);
  dosomething(string1, myint);
end.
     
So notice that the writeln debug statements are all inside of the begin/end statements either in the main program or in one of the procedures or functions.  Comments are between (* *) pairs. 

See how the writeln can be used to output the value of variables in various places...that's how it was done before debuggers.
Title: Re: Stopping a program
Post by: zz28zz on June 22, 2019, 07:39:49 am
Unreasonable is a good word for it. Some bosses (non-technical background) seem to believe if you're a hardware guy, then your automatically a s/w guy too.  %)


I believe I have the general idea with writeln. However, I found it was modified a bit so I went with the examples already there. (BIWritelnStr). Seems to work OK.

I've modified the code a bit, but the main parts are still there.

Here's where the error occurs:

If BI_Result(False)>0 Then                                                   <---------- This is what triggers the abort. BI_Result is above 0
         Begin
           BIWritelnStr('line 1274');                                           <---------- I added this
           BIWritelnStr('FAILURE : Abort ramping voltage');      <---------- Displayed error msg.
           Failure:=True;
         End;


When I grep for "BI_Result" I found the Function below. (still trying to make sense of what it's doing) See comments.


(*________________________________________________________
| FUNCTION  : BI_Result
| VERSION   : X.XX
| DATE      : XXXXX XX, XXXX
|.........................................................
| DEFINITION/NOTES:
|     Returns last error number from abort.
|     Reset -  True =  Set BI_ResultVal to 0, plus abort
|                      vars.
|              False = Do not reset BI_ResultVal
|________________________________________________________*)
Function BI_Result(Reset : Boolean) : Word;

Begin
  (* Override abort, forcing powerdown of instruments *)
  If (Insidepwrdwn=True) Or (InsideHVpwrDwn=True)     <---------If in one of the pwr dwn modes, it resets BI_Result to 0
   Then BI_Result:=0
   Else BI_Result := BI_ResultVal;   <-------------If not in a pwr dwn mode, it leaves the BI_ResultVal unchanged
  If Reset=True Then                       <------------What determines if Reset is true or false?????? Seems like if true, error would clear??
  Begin
    BI_ResultVal:=0;                      (* Resets to indicate no error *)      <-------------This comment is orig
    xProcedure:=yUnknown;                            (* Reset xProcedure *)   <-------------This comment is orig
    xSubProc:=yUnknown;                                                                       <---- not sure what's going on from here down
    xBin:=0;
    zBin:=0;
    xNode:=0;
    zNode:=0;
    xPin:=0;
    zPin:=0;
    xUnit:=0;
    zUnit:=0;
    xValue:=1E37;
    zValue:=1E37;
    xDevice:=UFI;                                            (* Uncommon *)
    zDevice:=UFI;
    xHV_Addr:=$FF;
    xHV_OrgData:=$FF;
    xHV_NewData:=$FF;
    zHV_Addr:=$FF;
    zHV_OrgData:=$FF;
    zHV_NewData:=$FF;
    xHV_Value:=0;
    zDataStr:='';
    xDataStr:='';
    GlbAboNodePinValue:=0;
  End;
End; (* Function RI_Result *)
Title: Re: Stopping a program
Post by: BobS on June 22, 2019, 08:24:15 am
It helps when posting code to put it in code tags like this:
Code: Pascal  [Select]
  1. (*________________________________________________________
  2. | FUNCTION  : BI_Result
  3. | VERSION   : X.XX
  4. | DATE      : XXXXX XX, XXXX
  5. |.........................................................
  6. | DEFINITION/NOTES:
  7. |     Returns last error number from abort.
  8. |     Reset -  True =  Set BI_ResultVal to 0, plus abort
  9. |                      vars.
  10. |              False = Do not reset BI_ResultVal
  11. |________________________________________________________*)
  12. Function BI_Result(Reset : Boolean) : Word;
  13.  
  14. Begin
  15.   (* Override abort, forcing powerdown of instruments *)
  16.   If (Insidepwrdwn=True) Or (InsideHVpwrDwn=True) //    <---------If in one of the pwr dwn modes, it resets BI_Result to 0
  17.    Then BI_Result:=0
  18.    Else BI_Result := BI_ResultVal;  // <-------------If not in a pwr dwn mode, it leaves the BI_ResultVal unchanged
  19.   If Reset=True Then                  //     <------------What determines if Reset is true or false?????? Seems like if true, error would clear??
  20.   Begin
  21.     BI_ResultVal:=0;                      (* Resets to indicate no error *)//      <-------------This comment is orig
  22.     xProcedure:=yUnknown;                            (* Reset xProcedure *)//   <-------------This comment is orig
  23.     xSubProc:=yUnknown;                                                      //                 <---- not sure what's going on from here down
  24.     xBin:=0;
  25.     zBin:=0;
  26.     xNode:=0;
  27.     zNode:=0;
  28.     xPin:=0;
  29.     zPin:=0;
  30.     xUnit:=0;
  31.     zUnit:=0;
  32.     xValue:=1E37;
  33.     zValue:=1E37;
  34.     xDevice:=UFI;                                            (* Uncommon *)
  35.     zDevice:=UFI;
  36.     xHV_Addr:=$FF;
  37.     xHV_OrgData:=$FF;
  38.     xHV_NewData:=$FF;
  39.     zHV_Addr:=$FF;
  40.     zHV_OrgData:=$FF;
  41.     zHV_NewData:=$FF;
  42.     xHV_Value:=0;
  43.     zDataStr:='';
  44.     xDataStr:='';
  45.     GlbAboNodePinValue:=0;
  46.   End;
  47. End; (* Function RI_Result *)
  48.  

Anyway this looks like it is called after the error occurs and resets a bunch of global variables to their defaults.  Without knowing what's happening, I'd guess you need to find out where the actual error occurs...where this function is getting called from.
Title: Re: Stopping a program
Post by: trev on June 22, 2019, 12:27:43 pm
Quote
If Reset=True Then       <------------What determines if Reset is true or false??????

Answer:

Code: Pascal  [Select]
  1.   Function BI_Result(Reset : Boolean) : Word;

where Reset is a boolean value passed in as BI_Result(True) or BI_Result(False) in the code where the error occurs.
Title: Re: Stopping a program
Post by: jamie on June 22, 2019, 06:53:19 pm
I understand the code clearly...

It is reporting the current state of the machine and if you decide you want to clear the current
state you need to call that function with TRUE in it..

BI_RESULT(True);

Will Reset it.

However, I think you need to be in a true DOS environment with Dos debugging tools because
I suspect the code is using Port or ASM to read/ write to the cards and unless you have some
port drivers installed the debugging using Laz in windows isn't going to work out to well because
you can't access any of those devices so the error will always be there.

 Do you have port drivers for those cards that allows you to run that code in a non true DOS
environment?

Title: Re: Stopping a program
Post by: zz28zz on June 22, 2019, 09:18:17 pm
Tags?? Is that the line numbers?

Can I change this If BI_Result(False)>0 Then  to read If BI_Result(True)>0 Then ,, Save it, compile it and run?

OR Is the true/false entered by code that has been run already?





Title: Re: Stopping a program
Post by: zz28zz on June 22, 2019, 09:46:44 pm

However, I think you need to be in a true DOS environment with Dos debugging tools because
I suspect the code is using Port or ASM to read/ write to the cards and unless you have some
port drivers installed the debugging using Laz in windows isn't going to work out to well because
you can't access any of those devices so the error will always be there.

 Do you have port drivers for those cards that allows you to run that code in a non true DOS
environment?

I'm doing the code editing, compiling and testing on the DOS computer that runs the tester.
Title: Re: Stopping a program
Post by: jamie on June 22, 2019, 10:43:01 pm
obviously there is a problem brewing and I suspect you are trying to keep the app form terminating
if there is one device that isn't working properly...

 The section where the error message is generated can be altered to ether write to a log file and
move on or have some sort of scrolling window ..

  If you are getting errors on all devices then I suspect that you have some sort of interface
issue, for example a port driver being used to talk to the cards.
Title: Re: Stopping a program
Post by: zz28zz on June 23, 2019, 02:09:13 am
Tester is fine until I add the oddball module. Setup screen has to be modified so the s/w knows to look for the oddball module during init. The s/w appears to think the oddball module is in an error state and with the Boolean set to false it isn't trying to clear the error state. The s/w will continue if you hit ENTER on the error message screen and completes initialization but pops up a window saying the oddball module did not init properly and may need repair.
 
I'm thinking I need to figure out what is placing it in a error state to begin with. This is what the old eng was saying abt modifying the code so the s/w would pause at predetermined points during initialization and report module error state status.

When you say the section where the error message can be altered to generate a log file, what info is gathered for the log file? How is the code altered?

BTW, I looked and found Turbo Debugger installed on the tester PC. I loaded the init.exe file and ran it but it just says "Terminated. Exit code 0". Not sure what that's supposed to tell me.

Title: Re: Stopping a program
Post by: jamie on June 23, 2019, 02:21:58 am
It means the app didn't exit abnormally.

EXIT code 0... Normal Exit.

The app isn't crashing, its the debugging test functions it has in there..

 You need to dig backwards in the program to see where the values are set.,.

Not knowing what you are using I guess to say they are IO cards in PCI slots where you
can read/write Bits data for output or input signals and maybe even do Analog in/out.
Title: Re: Stopping a program
Post by: trev on June 23, 2019, 06:49:06 am
You keep referring to the "oddball module" as the cause of the issue. Perhaps you need to debug that rather than the rest of the tester program. (Assuming I understand what you describe.)
Title: Re: Stopping a program
Post by: Noodly on June 23, 2019, 08:54:48 am
Turbo debugger is the best answer if you can get that going. It's a very long time since I used it but the basic steps are to compile the BP program with debugging on and then step through the code. You will have to experiment a bit with where you put your breakpoints, especially if interrupts are being used.

I would guess that either the original programmer didn't test the oddball module or it's faulty. If you need to modify the program to deal with the oddball module properly I would uninstall it and debug one two standard modules to get a feel for the original programmer's approach.
Title: Re: Stopping a program
Post by: lucamar on June 23, 2019, 03:47:15 pm
Turbo debugger is the best answer if you can get that going.

TD is worse than useless unless the program was compiled with debug info for it. Since the OP is trying to modify/debug a BP program one may infer that there is a copy of Turbo/Borland Pascal installed in the machine? If so, it's much easier to debug in the IDE than with TD.

I'm (was?) a big fan of Turbo Debugger ... but in its proper place. Of course, if all you have is a hammer ... :)
Title: Re: Stopping a program
Post by: Noodly on June 23, 2019, 08:01:01 pm
Turbo debugger is the best answer if you can get that going.

TD is worse than useless unless the program was compiled with debug info for it. Since the OP is trying to modify/debug a BP program one may infer that there is a copy of Turbo/Borland Pascal installed in the machine? If so, it's much easier to debug in the IDE than with TD.

I'm (was?) a big fan of Turbo Debugger ... but in its proper place. Of course, if all you have is a hammer ... :)

The opening poster states that both BP and TD are installed on the test machine. Back in the day I found TD a better tool for debugging programs that interface with external hardware.
Title: Re: Stopping a program
Post by: jamie on June 23, 2019, 08:21:57 pm
if you use BP IDE the debugger works in it.

or you can use the TD directly and single step the code in ASM land.

But the problem is that you need to know what you are looking at for this operation.
Title: Re: Stopping a program
Post by: lucamar on June 23, 2019, 08:44:44 pm
or you can use the TD directly and single step the code in ASM land.

TD was one of the few debuggers with which you could do source-level debugging (if the program was compiled for it), so no need for the (frequently futile) "step-into-asm-land" games.

But then, you could already do that (and better) with the integrated debugger, so Turbo Debugger was--for me--a kind of "last resource weapon". And a very good one, in fact, to debug long assembler programs :)

Returning to the thread's subject ... here is how you set a breakpoint in your code (attached image):

For run-testing, you can add a Write or WriteLn before that same line, or after, or both.

The real problem, as jamie said, is to guess just where you want to look.

When looking for an external error, you should find where in the code that error is being generated. Pausing (or logging) on  lines that deal with it much later is of little use.

In your case, there is probably some place where something is being sent/queried to/from each module. There is where you should concentrate your debugg¡ng efforts: Try to see exactly what is being sent and received and compare it with what the hardware specs say should be. Maybe you're forgetting to set/reset some bit? Skipping some step that must be done? Sending the wrong command or in the wrong order?

That's where I would start. YMMV, of course :-\
Title: Re: Stopping a program
Post by: zz28zz on June 25, 2019, 05:08:14 am
Back to digging thru the source code I found a procedure called STATUS.

I'd like to try inserting it in the init.pas code.

This is what I found:

Code: Pascal  [Select]
  1.  
  2. (*_________________________________________________________
  3. | PROCEDURE : Status
  4. | VERSION   : x.xx
  5. | DATE      : xxxxxxxx xx, xxxx
  6. |..........................................................
  7. | DEFINITION/NOTES:
  8. |   Graphically displays Device and connection status.
  9. |   Status removes any function key handler.  The calling
  10. |   program must restore its function key handler upon
  11. |   returning from Status.
  12. |
  13. |   DisplayAction Values :
  14. |    Status_NoRestore = 0 : xxxxxxx0 - do not restore
  15. |                           previous screen upon exit.
  16. |    Status_Restore   = 1 : xxxxxxx1 - restore previous
  17. |                           screen upon exit.
  18. |    Status_Screen    = 2 : xxxxxx1x - display status on
  19. |                           on screen.
  20. |    Status_NB        = 4 : xxxxx1xx - don't wait for
  21. |                           keycodes to exit
  22. |    Status_Hookup    = 8 : xxxx1xxx - called from hookup
  23. |                           so display even if HVP.
  24. |_________________________________________________________*)
  25.  
  26.  

Status_Restore is the option I want but not sure how to insert it in the init.pas file.

I tried inserting the following inside an existing procedure. It didn't like that.

Status_Restore;
Status_Restore=1;
Status _Restore = 1;

Then I tried making my own Procedure like this:

Procedure Status
begin
Status_Restore
end;


It errors during compile: "Error 113 Error in statement" and points to "Status_Restore" line.




Title: Re: Stopping a program
Post by: lucamar on June 25, 2019, 05:34:06 am
What is the Status declaration?

If, as seems probable, is something like:

Code: Pascal  [Select]
  1. procedure Status(DisplayAction: Byte);

then all you need to do is call it like:
Code: Pascal  [Select]
  1.   {... some code ...}
  2.   Status(1);
  3.  {or maybe: Status(Status_Restore);}
  4.   {... some more code ...}

But take good notice of the warning about "function key handler"!

By the way, please surround the posted code with [code] tags to make your posts more readable. See here:Forum - Use code tags (https://wiki.freepascal.org/Forum#Use_code_tags)
Title: Re: Stopping a program
Post by: zz28zz on June 25, 2019, 06:19:47 am
Thx for telling me what the tags thing is. I edited my prev post so it now has tags.

Not sure what a Status declaration is but there's a line that looks exactly like what you typed just below where I copied the prev info from. ( I didn't include it).

I inserted "Status(1);" in a previously existing procedure that displays an on-screen warning message abt high voltage before starting init. It compiled OK.
Thought I might need to type in  "procedure Status(DisplayAction: Byte);" somewhere but maybe not..

Won't know if it works until I get back in front of the tester. thx!