|
|
Post by PaulDZ on Jul 24, 2020 20:03:43 GMT -5
I am in the process of creating a conversion program that will take a Visual Basic 6.0 frx file and convert it into a Liberty Basic GUI.
I am creating the output file in this way:
open "OutPut.bas" for output as #2
print #2, ""
print #2, "nomainwin"
print #2, ""
print #2, ""
print #2, "WindowWidth = ";val(ClientWidth$)/15
print #2, "WindowHeight = ";val(ClientHeight$)/15
print #2, "UpperLeftX = int((DisplayWidth-WindowWidth)/2)"
print #2, "UpperLeftY = int((DisplayHeight-WindowHeight)/2)"
print #2, "BackgroundColor$ = ";chr$(34);"buttonface";chr$(34)
This is working great under LB5, but when I load the output file into LB4.5.1 the source is not loading correctly.
After some hex nibbling on the file I fount that the "Print #2, " command is ending the line with a chr$(13) but not the standard chr$(13)+chr$(10)
This causes the editor of LB 4.5.1 to treat the entire file as a single line.
I've run the program on LB4.5.1 with the same result.
Is this normal or am I doing something wrong?
|
|
|
|
Post by Brandon Parker on Jul 25, 2020 14:46:03 GMT -5
I ran this code with LB 4.5.1 which just changes where the file is located and closes it after creation. Loading the created .BAS file with LB 4.5.1 editor went perfectly smoothly with no issues. open "D:/OutPut.bas" for output as #2
print #2, ""
print #2, "nomainwin"
print #2, ""
print #2, ""
print #2, "WindowWidth = ";val(ClientWidth$)/15
print #2, "WindowHeight = ";val(ClientHeight$)/15
print #2, "UpperLeftX = int((DisplayWidth-WindowWidth)/2)"
print #2, "UpperLeftY = int((DisplayHeight-WindowHeight)/2)"
print #2, "BackgroundColor$ = ";chr$(34);"buttonface";chr$(34)
Close #2Looking at the created .BAS file in a hex-editor I see CR+LF in the spots where they should be.  Are you saying that the CR+LF is not being created while using the LB5 IDE? {:0) Brandon Parker |
|
|
|
Post by tenochtitlanuk on Jul 25, 2020 15:33:04 GMT -5
I confirm Paul's results under LB4.5 ( under Linux/Wine) and LB5-351 native in Linux.
But I've got into the habit of checking files I save or download in a hex editor since I still use Windows occasionally and text/data files can use CR, LF, CRLF and LFCR!
|
|
|
|
Post by Gordon Rahman on Jul 25, 2020 17:30:51 GMT -5
It works fine here LB4.5.1
But I have to close #2 before the output file will be created.
Gordon
|
|
|
|
Post by Brandon Parker on Jul 25, 2020 18:15:08 GMT -5
So Paul, are you using Linux and Wine? If so, then we can most likely blame Wine and/or Linux ...  {:0) Brandon Parker |
|
|
|
Post by metro on Jul 25, 2020 21:05:49 GMT -5
So Paul, are you using Linux and Wine? If so, then we can most likely blame Wine and/or Linux ... {:0) Brandon Parker I have to admit I get no end of grief with line endings using Linux/Wine but I am a slow learner.
It took me a while to realise line input gets the data only, cutting off the end of line characters
So I now check for line endings on the whole file, usually after 20 minutes of head scratching and cursing . |
|
|
|
Post by gidiom2 on Jul 26, 2020 2:24:44 GMT -5
PaulDZ's code produces a file which when opened in LB451 lists and runs OK for me, with Linux Wine version 4 and LB451 IDE. So to add to the confusion, I see no problem with Wine. |
|
|
|
Post by PaulDZ on Jul 26, 2020 3:30:14 GMT -5
Are you saying that the CR+LF is not being created while using the LB5 IDE? {:0) Brandon Parker Yes, when run in LB 4.5.1, I get a CR+LF at the end of each line. When run in LB5, it only gives the CR. If you load the "OutPut.bas" file in the LB5 IDE, there's no problem. It loads and runs. But if you then try to load the "OutPut.bas" file in the LB 4.5.1 IDE, it seems to need a CR+LF pair. If you can, test the code you supplied by running it under the LB5 IDE and then try to load the output.bas file in the LB 4.5.1 IDE. It seems to be a problem in LB5. Every other basic I've used (including LB4.5.1) assigns a CR+LF pair at the end of a line written to a file. |
|
|
|
Post by Rod on Jul 26, 2020 3:34:12 GMT -5
Ok, LB5 messes it up for me on Win10 running LB5 351. The file will not load correctly to LB4.5.1
You can take control and explicitly write the file but this should not be necessary. Perhaps Carl will have a better fix.
open "OutPut.bas" for output as #2
print #2, ""
print #2, "nomainwin"
print #2, "";chr$(13);chr$(10);
print #2, "";chr$(13);chr$(10);
print #2, "WindowWidth = ";val(ClientWidth$)/15;chr$(13);chr$(10);
print #2, "WindowHeight = ";val(ClientHeight$)/15;chr$(13);chr$(10);
print #2, "UpperLeftX = int((DisplayWidth-WindowWidth)/2)";chr$(13);chr$(10);
print #2, "UpperLeftY = int((DisplayHeight-WindowHeight)/2)";chr$(13);chr$(10);
print #2, "BackgroundColor$ = ";chr$(34);"buttonface";chr$(34);chr$(13);chr$(10);
close #2
|
|
|
|
Post by Carl Gundel on Jul 26, 2020 11:47:26 GMT -5
There are different platform line endings for Windows and Linux, etc. But I can set up a global variable (or variables) where this can be changed.
For example OSLineEnd$ could be set to CR or CRLF depending on the OS, but then you could set it to whatever you like.
OSLineEnd$ = WindowsLineEnd$ or OSLineEnd$ = CRLFLineEnd$
OSLineEnd$ = LinuxLineEnd$ or OSLineEnd$ = CRLineEnd$
That sort thing. I'm open to ideas.
|
|
|
|
Post by Carl Gundel on Jul 26, 2020 11:49:02 GMT -5
There are different platform line endings for Windows and Linux, etc. But I can set up a global variable (or variables) where this can be changed. For example OSLineEnd$ could be set to CR or CRLF depending on the OS, but then you could set it to whatever you like. OSLineEnd$ = WindowsLineEnd$ or OSLineEnd$ = CRLFLineEnd$
OSLineEnd$ = LinuxLineEnd$ or OSLineEnd$ = CRLineEnd$That sort thing. I'm open to ideas. Then it might get a little more complicated if we want to set it differently for reading vs writing. |
|
|
|
Post by Carl Gundel on Jul 26, 2020 11:51:13 GMT -5
I've changed the subject of this thread to make it more about line delimiters. It's also an LB5 related topic, so I moved it to the LB5 area. |
|
|
|
Post by Rod on Jul 26, 2020 14:51:41 GMT -5
Having a system variable that sets the default line end is good. Consistent. You either write and read files with CRLF or just LF.
But, and it is a big but, or it might not be. Reading a foreign file, how to know what delimiter has been used?
So I am messing about in Windows and happen on a Linux file, or, I am messing about in Linux and happen on a Windows file.
If we open a file can we auto detect what line end combination is used? Can we test it and see if we find CRLF or only LF, can we then switch mode?
Perhaps too complex.
Can we just use the LF which is common to both and ignore the CR if it exists? So we always write CRLF unless the system variable says write LF. Reading files we react to the LF and ignore, or drop the CR if it exists. Reading gets everything up to the LF but drops any preceding CR. Currently we drop the whole CRLF combo and just get the data.
I can't find much on google but relying on the LF and dropping the CR should work for Windows, And so too Linux, react to the LF drop the CR.
but I am sure it is more complex than this.
|
|
|
|
Post by PaulDZ on Jul 27, 2020 0:11:23 GMT -5
There are different platform line endings for Windows and Linux, etc. But I can set up a global variable (or variables) where this can be changed. For example OSLineEnd$ could be set to CR or CRLF depending on the OS, but then you could set it to whatever you like. OSLineEnd$ = WindowsLineEnd$ or OSLineEnd$ = CRLFLineEnd$
OSLineEnd$ = LinuxLineEnd$ or OSLineEnd$ = CRLineEnd$That sort thing. I'm open to ideas. Then it might get a little more complicated if we want to set it differently for reading vs writing. After a quick bit of online research the consensus seems to follow this method: All versions of Microsoft Windows represent line endings as CR followed by LF. UNIX and UNIX-like operating systems (including Mac OS X) represent line endings as LF alone. While a global variable or even a setting within the IDE would be nice, it really should default to the normal usage of the operating system. My personal opinion is that if you are using files from another OS, you need to program for that scenario. Whether it's to/from Windows, UNIX, C, C++, etc. Of course, when using the IDE for each operating system, the IDE should be able to ascertain the file deliminator and load the program in a cross-platform fashion. That way you can test code written in a windows environment on linux and the other way around. Looking forward to any thoughts on this.
|
|
|
|
Post by Rod on Jul 27, 2020 2:33:38 GMT -5
Having slept on it I think I am suggesting an automatic replacement. So when line end files are read by commands that respect line ends the line end characters found should be replaced by the system variable line end.. but we need to hear from Linux users or someone more sensible than I.
I am not saying change the file, but on loading the line end characters should be replaced "internally". If they are written out to file they should take the system variable value, so in that case the file would be changed.
It would mean you could load/read any file without caring how it is line ended. The file itself would remain unchanged unless you chose to overwrite/rewrite it.
|
|
