Where is the implementation of WriteLn()

[adem0x]

No space, no tab. They are just printed after each other.

Thank you. Indeed, thank you all.

One more question:

System.Input and System.Output are also used in HeadConv.

I don't quite know their purpose. Is each one a separate one, or are they mapped/redirected to the same file/pipe?

IOW, is System.Input specifically for Read/ReadLn (i.e. read-only) and System.Output for Write/WriteLn (i.e write-only)?

If not, what is the difference?

The reason I am asking is to decide whether I need to use separate streams for each?

[marcov]

System.Input and System.Output are also used in HeadConv.

Input is the default file for read(ln), output is the default file for write(ln)

iow writeln(a,b,c) is the same as writeln(output,a,b,c);

[taazz]

knowing nothing about your application and setup I'll assume that system.input refers to the keyboard and system.output refers to the screen.

[adem0x]

iow writeln(a,b,c) is the same as writeln(output,a,b,c);

What I am trying to understand is, is ReadLn(output,a) supposed to raise an error?

Similarly, is WriteLn(input,a,b,c) wrong?

knowing nothing about your application and setup

I am updating some legacy code that uses these calls a lot.

I'll assume that system.input refers to the keyboard and system.output refers to the screen.

So, writing to input is adding stuff to keyboard buffer?

But, what does reading from output (i.e. the screen) mean?

[taazz]

So, writing to input is adding stuff to keyboard buffer?

But, what does reading from output (i.e. the screen) mean?

depends on the driver for the input/outpu but most likely yes it will raise an error.
Do you really have those use cases in the legacy code? if not why bother with them?

[adem0x]

Do you really have those use cases in the legacy code? if not why bother with them?

First thing I am trying to understand is why the code uses System.Input and System.Output even though it is a GUI app (not a console one).

This is it: http://www.drbob42.com/delphi/headconv.htm

I am using the Jedi version (which is the open sourced one).

Anyway.

The reason I am asking all those stupid questions is basically because the code uses System.TextFile stuff (all 5 of them, including 'input' and 'output') and also because I am nearly completely ignorant about System.TextFile stuff (I have long forgotten what little I might have been familiar with back then, a century ago.)

I am trying to get rid of System.TextFile(s) in favor of TStreams --which is a noble purpose 

But, I am confused about the reason why the author used  System.Input and  System.Output in a GUI application. Should I simply comment them out?

To decide, I need to understand what magic do System.Input and  System.Output serve in a GUI application --if any.

[taazz]

Do you really have those use cases in the legacy code? if not why bother with them?

First thing I am trying to understand is why the code uses System.Input and System.Output even though it is a GUI app (not a console one).

Sorry this can only be answered from the code I have no way to know.

This is it: http://www.drbob42.com/delphi/headconv.htm

What exactly is this? the legacy application you are porting? as far as I know that is a CLI application, that means it is a console application not gui.

I am using the Jedi version (which is the open sourced one).

Anyway.

The reason I am asking all those stupid questions is basically because the code uses System.TextFile stuff (all 5 of them, including 'input' and 'output') and also because I am nearly completely ignorant about System.TextFile stuff (I have long forgotten what little I might have been familiar with back then, a century ago.)

I am trying to get rid of System.TextFile(s) in favor of TStreams --which is a noble purpose 

But, I am confused about the reason why the author used  System.Input and  System.Output in a GUI application. Should I simply comment them out?

To decide, I need to understand what magic do System.Input and  System.Output serve in a GUI application --if any.

Depends on what it is written/read from those files. Based on what I have see this far I would say you have a skewed understanding of what a console application is. In short if you open the legacy dpr file in your editor and it says on top {$APPTYPE CONSOLE} or something along those lines then the application is a console application.
To decide you need to understand what data are written/read from those files and see how it can be replaced.

[rvk]

The JEDI version can be found here:
https://sourceforge.net/projects/jdarth/

For clarification... it has a GUI AND console application.
The GUI uses the same routine as the console application.
Therefore the GUI does an assign on output and the routine can just use writeln the same way as the console version can (so sharing the same code, see common directory).

adem0x, what exactly are you trying to rewrite? (because it should already work as is)

[adem0x]

depends on what it is written/read from those files. Based on what I have see this far I would say you have a skewed understanding of what a console application is. In short if you open the dpr file in your editor and it says on top {$APPTYPE CONSOLE} or something along those lines then your application is a console application.

You know what, I could take offense at that remark of yours, but I can see why you think that.

Here, enclosed, is a screenshot of what it looks like.

I am sure you'll agree that we're not talking about a console app.

[adem0x]

adem0x, what exactly are you trying to rewrite? (because it should already work as is)

Well, it uses shortstrings. And, as was the rage at the time, it sets string length by manipulating the zeroth byte. That means, it doesn't compile with recent versions of Delphi.

The other issue is, naturally, since shortstrings can only have 255 chars, input files with longer lines do not work.

Finally, the code as it stands is far too convoluted spaghetti code. I want to make it readable so that it can be improved.

To that end, I want also to get rid of System.Textfile stuff in favor of TSreams.

[taazz]

depends on what it is written/read from those files. Based on what I have see this far I would say you have a skewed understanding of what a console application is. In short if you open the dpr file in your editor and it says on top {$APPTYPE CONSOLE} or something along those lines then your application is a console application.

You know what, I could take offense at that remark of yours, but I can see why you think that.

why? it only shows my ignorance for your code and gives you a chance to prove me wrong.

Here, enclosed, is a screenshot of what it looks like.

I am sure you'll agree that we're not talking about a console app.

I agree, that,  does not look like a console application, but you given me no new information for the use cases in question so it is a mute point. At this point its a waste of your time for me to keep answering.

[rvk]

To that end, I want also to get rid of System.Textfile stuff in favor of TSreams.

Okay, but choosing some function, yet to be written (which it can't) isn't the solution for that. You would have the same downsides.

writeln can write strings larger than 255.

So you have a choice. Use writeln, as it is now, with the redirect to a textfile (which can have large strings) or rewrite all the rewrite lines properly to use streams.

But readln and writeln can just work with large ansistrings (even utf-8) so there is no reason to change it. You DO need to change the shortstrings to normal strings.

[adem0x]

So you have a choice. Use writeln, as it is now, with the redirect to a textfile (which can have large strings) or rewrite all the rewrite lines properly to use streams.

Yes, it is an executive decision. Using TStream is a lot more readable (at least, AFAIC), plus they can do anything Sytem.Texfile does. I have decided to go with TStreams.

But readln and writeln can just work with large ansistrings (even utf-8) so there is no reason to change it.

True. But, as I said earlier, the code as it stands is not easy to read and modify.

I mean, why on earth would an application use 5 (FIVE) System.Texfiles when all it needs is 2 (one for reading in the input file, the other to write out the result of conversion). Maybe, just maybe, another one for an interim/intermediate/temp use; but 5 is definitely definitely not needed.

You DO need to change the shortstrings to normal strings.

That was the easy bit

[adem0x]

I agree, that,  does not look like a console application, but you given me no new information for the use cases in question so it is a mute point.

What use case do you need?

I did give you a URL where what it does is explained in detail.

At this point its a waste of your time for me to keep answering.

What do you expect me to say?

[rvk]

I mean, why on earth would an application use 5 (FIVE) System.Texfiles when all it needs is 2 (one for reading in the input file, the other to write out the result of conversion). Maybe, just maybe, another one for an interim/intermediate/temp use; but 5 is definitely definitely not needed.

Ok, let's see you do it with just 2 (or 3) streams then

As I quickly glance through the code 3 of those 5 text files are used as intermediate files to hold information. Back in the day that couldn't easily be done with a variable or stream.

Most work will be to convert such lines as this:

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

1. writeln(Str,'; external ''',DLL,'.DLL'';')

to this

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

1. Outputline(Str + '; external ''' + DLL + '.DLL'';')

or

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

1. Outputline(Format('%s; external ''%s.DLL'';', [Str, DLL]))