Printing to printer - Linux - LPRINT alternative?

[bplus]

Can't you download 32-bit windows version of QB64 and run them on WINE to make EXEs for WINE??

I think I downloaded the 64 bit version and ran in Wine last summer when I lost hard drives on Windows laptop.

@desA Surely Linux has text editors that can print a Text File, welcome to the forum BTW

[desA]

Thanks for the wise advice, and warm welcome, everyone. Very much appreciated. 

@bplus
"@desA Surely Linux has text editors that can print a Text File, welcome to the forum BTW   "

Plenty of Linux editors. 

[desA]

Thus far:

'--------------------------------------------------
Open "capture1.txt" For Output As #1
...
BL$ = "............."
Print #1, "blah blah" using BL$ , var
...

Close #1
'--------------------------------------------------

Noticed that the text is only written to file after 'Close #1' command executes.

Plan:
Write a series of text files then use linux command 'cat' to string these together. then convert text-to-pdf.

[mnrvovrfc]

The assembly into one big text file could be done by the QB64 program you're writing. Just use another filename for the output file.

Code: (Select All)

fout = FREEFILE
OPEN "capture-big.txt" FOR OUTPUT AS fout
PRINT #fout, "START OF REPORT"
FOR i = 1 to 10
if i < 10 then infil$ = "0" else infil$ = ""
infil$ = "capture" + infil$ + ".txt"
fin = FREEFILE
OPEN infil$ FOR INPUT AS fin
DO UNTIL EOF(fin)
LINE INPUT #fin, entry$
PRINT #fout, entry$
LOOP
CLOSE fin
NEXT
PRINT #fout, "END OF REPORT"
CLOSE fout

I thought you knew more about BASIC programming...

If you are able to put a zero for a value below ten to create a two-digit number inside a filename, eg. "capture01.txt" instead of "capture1.txt", it could save you a headache looking at it in a file manager. Although the other way, "capture1.txt" through "capture9.txt" then "capture10.txt" is easier to program.

[desA]

@mnrvovrfc
"I thought you knew more about BASIC programming..."

I'm converting very old code, with its philosophy basis pretty much FORTRAN F77 in structure (I'm an engineer). It is around 75% complex equations - the rest being data input, display and data output (display. printing). Around 2800 lines of code, thus far - more to come.

Learning new things as I go along. Coding philosophy has definitely changed over the years as newer languages have emerged.

I'm learning from giants... 

The software is used to design modular S&T HX
Modular S&T HX

[mnrvovrfc]

I suggest you take a look at this document:

https://qb64phoenix.com/qb64wiki/index.p...statement)

Noticed the "PRINT # USING" statement in the code snippet you provided. A period is only for demarcating the decimal point in a floating-point value. The formatting rules for "PRINT USING" might be different from what you might be used to.

Please note that FORTRAN might have math libraries that offer better floating-point support than QB64. This is important if you need scientific-grade precision in your calculations. You might want to run a few tests like this:

Code: (Select All)

DIM mynum AS DOUBLE
mynum = 1e-9
PRINT USING "-#.##########"; mynum
print mynum
mynum = mynum + 1e-8
PRINT USING "-#.##########"; mynum
print mynum

For a bit more "security" you could use _FLOAT type instead of DOUBLE.

This page is a poor way to describe it:

https://qb64phoenix.com/qb64wiki/index.p...able_Types

Factorials could get large very quickly, so for DOUBLE it goes up to 18 digits without scientific notation, for _UNSIGNED _INTEGER64 and maybe for _FLOAT it could go to 22 without one wrapping around (which is really bad) and the other without scientific notation. If you only need to make calculations with integers you have to be careful about wrap-around because it could really screw things up.

If the precision you require is no more than four digits after decimal point, as it's often the case with financial computations, then it could be faked with _INTEGER64, having positive and negative amounts and having at least 13 digits of precision "on the integer side." That's at least one trillion dollars! Then it's how it's displayed that matters there (ie. where to place the decimal point).

[desA]

Thank you very much. 

[bplus]

@mnrvovrfc
"I thought you knew more about BASIC programming..."

I'm converting very old code, with its philosophy basis pretty much FORTRAN F77 in structure (I'm an engineer). It is around 75% complex equations - the rest being data input, display and data output (display. printing). Around 2800 lines of code, thus far - more to come.

Learning new things as I go along. Coding philosophy has definitely changed over the years as newer languages have emerged.

I'm learning from giants... 

The software is used to design modular S&T HX
Modular S&T HX

If the stuff is so old that you have GoSubs or worse all GoTo's as opposed to genuine modular subs and functions, I would say it is well worth your time to convert the code to more portable (copy and paste) Subs and Functions so you could build a Toolbox and not have reinvent the wheel (or at least retype it) for each new app. I don't know, has FORTRAN come as far as QB64pe in modernization? maybe, but as easy to use?

[desA]

@mnrvovrfc
"I thought you knew more about BASIC programming..."

I'm converting very old code, with its philosophy basis pretty much FORTRAN F77 in structure (I'm an engineer). It is around 75% complex equations - the rest being data input, display and data output (display. printing). Around 2800 lines of code, thus far - more to come.

Learning new things as I go along. Coding philosophy has definitely changed over the years as newer languages have emerged.

I'm learning from giants... 

The software is used to design modular S&T HX
Modular S&T HX

If the stuff is so old that you have GoSubs or worse all GoTo's as opposed to genuine modular subs and functions, I would say it is well worth your time to convert the code to more portable (copy and paste) Subs and Functions so you could build a Toolbox and not have reinvent the wheel (or at least retype it) for each new app. I don't know, has FORTRAN come as far as QB64pe in modernization? maybe, but as easy to use?

Yes - the code is THAT ancient - full of line #s, gosubs and gotos.

I have systematically inserted modern labels, select case. to make the flow a bit more logical. A planned later development is to create headless subroutines that can receive file input / output. Thereafter to develop a more modern GUI.

Coding practice has come a long way since those early days. 

[desA]

Making solid progress - based off the very helpful info provided by forum members. 

Thus far (working well):
1.  Capture text in lumps - per major print subroutine (8 off them) - write to txt. Some display/print depending on menu choices in the design.
2.  SHELL - rm old files. SHELL cat file1.txt file2.txt >> file_summary.txt etc

To follow:
3.  SHELL linux convert txt->ps
4.  SHELL linux convert ps->pdf
5.  Optional: Launch pdf readers

To follow in future:
6.  Convert main number-crunching subroutines to headless subroutines.
7.  Write: Input GUI -> headless subroutines -> output GUI
8.  Launch multiple runs through headless subroutines -> the rank multiple outcomes based on equipment capital cost.

---
Folks can follow progress on my Patreon site - it will be updated regularly
https://www.patreon.com/posts/modular-s-t-hx-82934523