The answer to my "runtime error 6" (invalid filename) ended up being I had too many files open (apparently). I couldn't find anything invalid about the filename (it was a standard DOS 5.3, with no LFN), but in looking for every instance of "runtime error" I could find, I found the "close(filename)" command. I decided that would be good practice, and it fixed the problem once I closed a file I was finished with.

Can you only have 2 files open with FP? As above, I fixed my problem with opening the third file by closing another, and only having 2 open at once. My config.sys has "FILES=20", so it's not a DOS limitation by the look of it (unless my FP program is opening up another 18 related system files behind the scenes. e.g. units or something).

I also wanted to know if there's a colour palette somewhere? Or a list of the text-names that can be used with "textcolor"?

When I run pascal programs (not just FP, but other compilers too), the last text-colour I used stays even after the program is finished. The original default colour only returns after I call something else. e.g. DR-DOS editor.
Also, if I call the program from a batch-file, I still have the default colour when it's finished, so a direct call to the program changes my default text until such time as I call something else.

Not a FP-specific question, but while on the topic - I would actually like to permanently change my default text-colour, but can't find where I can do that (I looked around the BIOS, and couldn't see anything, and the "colour scheme" in DR-DOS only applies to the editor and stuff, not your shell).

All suggestions welcome on any of these issues.

thanks,
DONALD.

E-mail -
BIG DON's Home-page - http://jedi.apana.org.au/~jims_son Pedder Passer Rating - http://jedi.apana.org.au/~jims_son/PPR AusNFL mailing-list - http://jedi.apana.org.au/mailman/listinfo/ausnfl

"What I always wanted is to be accepted, not understood" - MAN RAY

Hi,

Probably another 18 files have already been opened by the OS (device drivers etc) - try setting FILES higher and test again. FPC programs don't allocate any new file resources by default afaik.

I also wanted to know if there's a colour palette somewhere? Or a list of the text-names that can be used with "textcolor"?

Try the constants in crt.pp - you can set the color of a specific cell by setting textattr to the value of "(background-color shl 4) or foreground-color".

E.g. have a look at the output of the following program:

uses
 crt;
var
 i, j : Integer;
begin
 for i := 0 to 15 do begin
  for j := 0 to 15 do begin
   textattr := i shl 4 + j;
   Write('A');
  end;
  WriteLn;
 end;
 readln;
end.

Iirc in DOS the character cell blinks if the high bit of textattr is set (meaning that you're basically stuck with the first 7 background colors). You can disable blinking by calling int 10h with ax=$1003 and bl=$1 (enable again with bl=$0)

When I run pascal programs (not just FP, but other compilers too), the last text-colour I used stays even after the program is finished. The original default colour only returns after I call something else. e.g. DR-DOS editor.

FPC doesn't use the BIOS functions for drawing text characters in DOS - so the original text attributes should be preserved after exiting for new text. It leaves the current contents as they are by default though, this is normal.

Regards,
Thomas

Donald, I've never used FP on DOS. There is a museum section of the Borland.com site where you can (legally) download an old version of Turbo Pascal for hobbiest purposes. As I recall, Turbo Pascal exhibited the behavior you describe and the solution was to save the state of the text when the program starts and restore it (or restore it to what you like as a default) right before clsoing. I think there was also a DOS command to reset to the default. Sorry I don't recall specifics, that was a *long* time ago.

Also, as I recall, 20 file handles wasn't a lot. Each buffer only costs ~2k, IIRC, so I would bump it up and see if your problem disappears. I definitely opened more than 2 files at once using turbo pascal and DOS. I think we had to set FILES=50 or =99 to run WordPerfect 4.x and 5.x under DOS.

-Alan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

Probably another 18 files have already been opened by the OS (device drivers etc)

I guess that's what's happenning, as when I increased the files it worked. It seemed so extravagent that another 18 files would be open to run a simple pascal program I didn't even think it worth checking! I wonder what all the open files are?

FPC doesn't use the BIOS functions for drawing text characters in DOS - so the original text attributes should be preserved after exiting for new text.

Well, it's not, so I don't know what's going on there. I have some other computers and other compilers - I might try some mixing and matching to see if it's a problem with a specific computer/compiler (when I can find some time for this that is! :-( ).

thanks,
dp.

When I try to re-direct my program output it's not working. I have tried both ">file" and "|more", yet the program continues to display on screen as normal. Is there a known bug with this?

In another compiler, I used to have such problems when I was calling the program from a batch file, but not when called directly (so I would have to manually execute what the batch file did, then call the program in order for re-direction to work). With FPC though, I can't get re-direction to I said in the other E-mail, when I play around with other computers/compilers, I'll see what differences I can find, but in the mean-time any suggestions would be welcome.

thanks,
dp.

DONALD PEDDER wrote

When I try to re-direct my program output it's not working. I have tried both ">file" and "|more", yet the program continues to display on screen as normal. Is there a known bug with this?

Redirection will not work if you use the crt unit. The reason is that the crt unit has to use several tricks (on all platforms) to do its thing. The tricks are different on all supported platforms, but they all have the same effect: redirection does not work (properly) anymore.

Jonas

DONALD PEDDER wrote

When I try to re-direct my program output it's not working. I have tried both ">file" and "|more", yet the program continues to display on screen as normal. Is there a known bug with this?

If you use the CRT unit, this is normal behaviour. The CRT unit and rediction are NOT compatible.

Michael.

If you use CRT, remove it, and all will work normally.

Ah, okay. I am writing a budget program, so I was using green and red text-colours. It's the first time I've used coloured text. I guess I'll have to create a black and white version in order to save the output.

thanks,
dp.

From: DONALD PEDDER
To:
Subject: Re: [fpc-pascal]several questions Send reply to:

Date sent: Tue, 16 Sep 2003 22:44:36 +1000 (EST)

There are tools to find all the open files under DOS and what opened them (device drivers, TSRs, etc.); you could probably try to start something like that before running your Pascal program, and possibly to run it from a test program written in FPC using Dos.Exec to find out what exactly gets open by the extender and DPMI server. If you need such a tool, I can send it to you (the tool I have is called mapfiles.exe, but there are others probably).

The reason of your problem is very simple, IMHO. BIOS always uses the character attributes of the last character on the row when scrolling the screen above to add a new row. If you don't change these attributes before ending your program, DOS keeps them.

Tomas

Hi -

Just wondering if anyone else had has problems with the "heaptrace" option on 1.0.10?
(This only applies to Win32, and for me, only appears on WinME and not WinXP...)

I have created a 60-line example program that illustrates the problem: http://www.paradicesoftware.com/exceptz.pas

(the program above doesn't actually do much, I chopped it down to the minimum that gave the error)

With heaptrace disabled, the program executes normally (just pops up "Program End" window).
But if I switch heaptrace on, an "Access Violation" exception is triggered inside "CreateWindowEx".

By playing around I discovered that it it is caused by the GetMem inside window_proc.
Obviously heaptrace catches this and does something extra with it, but Windows ME doesn't like it!

If you comment out GetMem/Freemem, it works fine. Compiled for Go32, or without heaptrace, or on WinXP, and it all works ok. Moving GetMem/Freemem to somewhere else in the program, works fine.

Has anyone else experienced anything with heaptrace doing stuff like this?

Cheers,
Lawrence.

I have. See
http://www.nl.freepascal.org/lists/fpc-devel/2003-September/003057.html and the rest of the thread.

Peter fixed it in the 1.1 rtl, but not in the 1.0.10 rtl. You could do it yourself and recompile the rtl.

HTH,
Vincent Snijders.

Hi,

Did you succeed in solving your heaptrace problems?

Regards,
Vincent.

Yes - thank you very much, your indicated solution (I went in and added the "oldbp" variable) solved the problem perfectly.