RuntimeError 103 File not open

[CMELIGM]

Hi,

I got this Runtime Error out of nowhere, i can't explain why it is happening. i attached a Screenshot on where it happens.

i am using Lazarus 4.0 with FPC 3.2.2.

It's an I/O Error. I am using DLL's i wrote myself so i guess that could be the problem ? I never got the Error until now and i did not change the DLL.

When i remove the -WG ("http://forum.lazarus.freepascal.org/index.php?topic=14437.0"), then the error is fixed.

Here is the full lpr File

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

1. begin
2.    RequireDerivedFormResource:=True;
3.    SetExePath;
4.    if not InstanceRunning and CheckFiles and InitDatabase then begin
5.       Application.Title:='MyApplication';
6.       Application.Scaled:=True;
7.       Application.Initialize;
8.       //splash screen
9.       frmIntro:= TfrmIntro.create(Application);
10.       frmIntro.show;
11.       frmIntro.Update;
12.       Application.ProcessMessages;
13.       Application.CreateForm(TStartUp, StartUp);
14.       // Create Forms
15.       //destroy splash screen
16.       frmIntro.close;
17.       frmIntro.Release;
18.       Application.Run;
19.    end;
20. end.
21.  

would anyone help me fix this ?

[RayoGlauco]

In the post you linked, they say, "Make sure you don't check the -WG (GUI application) option in the compiler, as this would close standard output. WriteLn (by default) writes to standard output."

Maybe you're trying to write to standard output somewhere in your application.

[CMELIGM]

In the post you linked, they say, "Make sure you don't check the -WG (GUI application) option in the compiler, as this would close standard output. WriteLn (by default) writes to standard output."

Maybe you're trying to write to standard output somewhere in your application.

yes i checked it because i have a GUI Application not a Console Application. The DLL i am using has this Disabled. Enabling it in the DLL did Solve the Error Message, i am currently checking where it is caused. DLL does Read Data and creates a PDF out of it. i used a Save Dialog in the DLL. I should probably call the save dialog in the Main Application and not the DLL.

[paule32]

The Problem with DLL Files are they sharing the Pointers to Objects and Variables.

If you use DLL File then it is not guranteed that the Pointer for an Object is used either in the EXE or in DLL only.

So it can be that you have two Pointers Copies of the Same same one Object - then you get faced with Problems ...

Because the Sense of DLL is to "share" Objects and Members to not waste Memory in the System multiple twice ...

[Thaddy]

103 is one of the errors you can get when stdin/out/err or in real Pascal output/input and erroutput are not set.
On Windows, Lazarus defaults to that in a GUI application. (Why I do not know, it is a windows only issue)
If you add {$apptype console} these handles will be created.
You can subsequently hide the console window in code..

It is a really stupid decision that Lazarus works like that on Windows, but Hey who am I to complain?
The developers are aware of that platform only issue. 
There is no valid reason for it to be not solved after years from a technical point of view.
Btw this non-feature is Delphi compatible....
And the solution is pretty easy:

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

1. program DummyHandles
2.  
3. var
4.   dummy: TextFile;
5.  
6. begin
7.   // Redirect standard output to NUL
8.   Assign(dummy, 'NUL');
9.   Rewrite(dummy);
10.   Output := dummy;
11.  
12.   // Redirect standard input (optional, if used)
13.   Assign(dummy, 'NUL');
14.   Reset(dummy);
15.   Input := dummy;
16.  
17.   // Redirect standard error
18.   Assign(dummy, 'NUL');
19.   Rewrite(dummy);
20.   ErrOutput := dummy;
21.  
22.   // Test output
23.   WriteLn('This will be discarded.');
24.   WriteLn(ErrOutput, 'This error message is also discarded.');
25.  
26.   // Don't forget to close when done
27.   Close(dummy);
28. end.

I did not write that. Copilot did. But I tested it with Lazarus in a gui app.
I did replace the silly assignfile from that query and replaced it with the proper assign, though. And as such I removed sysutils.
Now this only has to be implemented deep in the sources, where file handling is abstracted away from the basics.
In Linux this is already the case: /dev/nul handles for GUI apps.

The effect is that the early 100 errors no longer occur.
Btw. AI help aside, I thought I had provided a similar example to solve it 15 years ago. NUL is a valid windows device handle.

[gues1]

Btw this non-feature is Delphi compatible....

Delphi doesn't have any problems like this; no library of any kind directly writes to the standard output device.
In Delphi, there's a project option that can be enabled or disabled (even by production type) to create a runtime console, or more simply, you can use the WIN32 "AllocConsole" API at runtime. This is what I do, for example, if I need to use a "writeln" for convenience during application runtime (for example, I activate at runtime a console when I need to monitor an event, which will use writeln, and close it when I no longer need it).
With AllocConsole, the console can also be closed later if it's a nuisance.

[Thaddy]

It should be handled as I described. You don't need the console api directly, only three handles.
Delphi behaves the same as Lazarus: if the apptype is GUI there are no handles.

[paule32]

for Windows Console ... it is programmed in C and there are Standard variables in msvcrt.dll: stdin, stdout, and stderr that are exportes by the CLIB.

The win32api Functions GetStdHandle:

STD_INPUT_HANDLE    =>  stdin
STD_OUTPUT_HANDLE  =>  stdout
STD_ERROR_HANDLE    =>  stderr

[gues1]

It should be handled as I described. You don't need the console api directly, only three handles.
Delphi behaves the same as Lazarus: if the apptype is GUI there are no handles.

No, Windows GUI doesn't need standard output or others (not console too like correctly you said).
This thread starts because Lazarus / FPC needs them ('cause some libraries use them incorrectly).

I don't think anyone would decide to use a nonexistent "serial" (hardware resource for communication) and complain that it must be NULL and that they have to use it anyway. They simply can't use it.

Why do we keep wanting "things" that don't belong to the system we're working on?
Why would you define a "standard output" to NULL?
You simply MUST NOT USE (and I emphasize MUST NOT USE) standard output.
If someone want things like this, it is simply to achive: if one need a specific resource in an application first he should test that it exists, after he can decide to create it or to generate an error if it doesn't exists.
And in Windows is very simple, more than simple.

EDIT:
You can use this to check the "standard output" assignment:

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

1. var
2.   Stdout: THandle;
3. begin
4.   Stdout := GetStdHandle(Std_Output_Handle);
5.   case StdOut of
6.      0: begin
7.           ShowMessage('This application has no standard output defined.');
8.         end;
9.      INVALID_HANDLE_VALUE: begin
10.           ShowMessage('This application has an invalid standard output defined.');
11.         end;
12.      else
13.         begin
14.           ShowMessage('This application has a standard output defined.');
15.         end;
16.   end;
17. end;
18.  

[Thaddy]

No, this is about preventing the 103 issue: that is not necessary.
My proposal is to solve that in the same way as under UNIX.
I know all the technical details.

[gues1]

No, this is about preventing the 103 issue: that is not necessary.
My proposal is to solve that in the same way as under UNIX.
I know all the technical details.

I have no doubt that you know all the details and are even capable of implementing them, but that's not the point.
On WINDOWS (GUI APPLICATION), there is no default standard output. That's the fact. There's no debate about it.
And Windows is not Linux or Unix.
If someone wants to enhance it, there are a thousand ways, but I don't think it should be the default. It could certainly be an extension.
If I type WRITELN (for example) and want to write something to the standard output, I absolutely don't like it if it defaults to NULL.
It should default to NULL if the user forces it, as is done on the command line, for example, but not if i run the program and it doesn't have a defined standard output.
Error 103 should appear, and it's better if it does.

The default standard output is the screen. And in a GUI environment the "screen" does not have the appropriate characteristics to be defined as standard output.

[paule32]

- DOS Application's are Text Console Application's.
- there are a VGA (Video Graphic Card Array).

This means, that you have a 80 x 25 Char Array wich have 2 Bytes for each Character.
Each Byte of them have the following Task:
1. Byte: Char (A-Z, a-z, 0-9)
2. Byte: Color of the Char at the Array Position

- many DOS Application's use BIOS Interrupts including 0x10 hex for the Video Adapter

Inteerrupts attempt the CPU to STOP till the User (or a Application Programmer coded the Program Logic with Loops or other Things - like TSR (Terminate and Stay Resident) Application's or Driver's.

The CPU will Start after these...

This means:
- Windows or Unix X-Server Application's run in Protected Mode of the CPU
- Protected Mode is differentialed an other Shoe as Real Mode for DOS Application's
- You have more Memory Space where your Application's can serve with - so you can codeing much more in 32-Bit Protected Mode Application's as the limited 16-Bit Real Mode Application's

This means:
- GUI Application's are slower than DOS TUI (Text User Interface) Application's
- because they handled on a HAL - Hardware abstraction Layer

- this HAL is used to save CPU Registers if you wan't call a BIOS Interrupt and doing some other complex Things, too.

- then GUI Application's have to handle (or more: the OS has handle) very much more ...
- e. g. Calculate and Render Pixels and their Color's ...

- we don't speak only of squared 320 x 200 x 256 Pixels (320 X, and 200 Y with 256 of Counts Colors Possibilities)

- we speak of 1900 x 1200 x 16M (16 Million Colors) !

A simple Picture for 320 x 200 counts 64.000 Bytes !
now, calculate your self 1900 x 1200 ...

The thinking on the other Things that the OS do:
- Store Drives Access
- Copy & Paste Memory all the Time the Computer is switched on
- Render Pixels, Colors, Pictures in Fore- and Background Windows.
- Play Music from a File or a Stream like from a Internet URL
- Measure Devices like a plugged-in Weather-Station on the USB-Port
- and so on, and so forth ...

So, to come to the Point:
DOS "blocks" other Memory and / or Application's
GUI "share" other Memory and / or Application's in a same place or on unique place.

This Background knowledge is not need by normal User or normal Hobbiest Programmer's.
You have Frameworks for nearly all your needs.

It is your decision what Framework, Programming Language (DSL) or what ever you decide to make / made - it is your Life - your Time.
You can spend it alone or in a Community ...

But trust us:
To more you give, to more you get back ...

And don't have a Eaer to People that say she/he/him know's all ...
That is a lie !

Nobody is perfect - but you can learn a lot of other Peoples if you hear or read them, to try other new Things ...

With kind regards - so I hope I don't patch into a Honey Pot - what my special field is 

[Thaddy]

I have no doubt that you know all the details and are even capable of implementing them, but that's not the point.
On WINDOWS (GUI APPLICATION), there is no default standard output. That's the fact. There's no debate about it.

That's the whole point: there is no valid reason for that! Can you read?
My suggestion is to solve that omission in Lazarus GUI code.
This is NOT a Windows issue, it is an implementation issue at the Lazarus side...

[gues1]

That's the whole point: there is no valid reason for that! Can you read?

Yes, I read it and tried to explain why it is.

My suggestion is to solve that omission in Lazarus GUI code.
This is NOT a Windows issue, it is an implementation issue at the Lazarus side...

If Lazarus (I mean in Windows environment of course) should complain about Windows, I don't agree with you.
But of course is only my thinking ...

Other think is that we talk enough about this. I stop here.
Bye

[gues1]

- DOS Application's are Text Console Application's.
..................
..................
..................
With kind regards - so I hope I don't patch into a Honey Pot - what my special field is 

I don't understand what you mean, sorry, I'm probably too tired.