Command of the Day: STRUCT

[Walt Decker]

STRUCT is a fairly limited concept, or is it?  The elements of a struct are PTR, CHAR[numchrs], DOUBLE, ULONG, LONG, USHORT, and SHORT.

Can someone come up with a way to create a random access file using a struct and not a field?

[pierre]

Yes, this is possible, but it requires some API knowledge.

See the discussion in the DATABASE PROGRAMMING section, thread 'Random Access Structs'.

[Walt Decker]

Jan 8, 2023 12:49:40 GMT -5 pierre said:

Yes, this is possible, but it requires some API knowledge.

See the discussion in the DATABASE PROGRAMMING section, thread 'Random Access Structs'.

It does not require a knowledge of API.  It does require a knowledge of how LB treats all data stored in a file.  LB files are non-standard windows(tm) files, i. e. LB treats all data as ANSI characters.  This eliminates the possibility of sharing files with non-LB applications.  It also requires a knowledge of the maximum characters the various data types can contain.  For example, a SHORT/USHORT is two bytes.  How many characters can be displayed?

If I recall, the data stored by "Personal Vital Signs" in the "Database Programming" thread does not use API to store the data.  It uses LB file protocal and stores the data in a binary file type.

To start, decide on a maximum string length.

Set up a string array and limit the contents to that length.

Decide which elements of the array will be text and which will be numeric.

Populate the array.

The record size will be the number of elements in the array times the maximum string length

Open a binary file type and store each element of the array.

After storing the data and before closing the file get the number of bytes in the file.  It should equal the record size you calculated.

Repopulate the array.

Open the file and SEEK the end of the file.

Store the new data at that point.

You now have a random access file.

 

[tsh73]

Walt,

LB files are non-standard windows(tm) files, i. e. LB treats all data as ANSI characters.

Really, sounds pretty standard to me.
Low level file reading/writing. Reading/writing raw bytes. Just about the same as C language does.
Or do you mean something else?

This eliminates the possibility of sharing files with non-LB applications.

Please explain what you mean here.
Sure you can write text and text is easily shared between applications?

[Walt Decker]

Really, sounds pretty standard to me.
Low level file reading/writing. Reading/writing raw bytes. Just about the same as C language does.
Or do you mean something else?

I think you are a little confused between bytes and ANSI characters. It depends on the C app.
If the C app translates a numeric to ANSI characters, the input will be ANSI otherwise the input will be reduced to the the numeric type. LB treats all data as ANSI when it really is not ANSI.

Please explain what you mean here.
Sure you can write text and text is easily shared between applications?

Again, I think you are a little confused. The discussion is about STRUCT and the LB random access file type, not the sequential file type.

[Walt Decker]

To show the difference between standard windows(tm) files and LB files I whipped up a little C app that outputs a numeric value and the same value translated to an ANSI string.

I did the same thing using LB protocal. The first file is from the C app, the second is the LB app.

DATA 1 FROM C APP
-----------------
, 0
è , 1000
Ð , 2000
¸ , 3000
  , 4000
ˆ , 5000
p , 6000
X , 7000
@ , 8000
(# , 9000
' , 10000

DATA 2 FROM LB APP
------------------
0, 0
1000, 1000
2000, 2000
3000, 3000
4000, 4000
5000, 5000
6000, 6000
7000, 7000
8000, 8000
9000, 9000
10000, 10000

THE LB APP
----------
'
F$ = "NUMBERS_2.ADT"
CR$ = CHR$(13) + CHR$(10)
OPEN F$ FOR BINARY AS #1
FOR I = 0 TO 10
 A = I * 10^3
 PRINT A
 PRINT #1, A
 PRINT #1, ", " + STR$(A) + CR$
NEXT I
CLOSE #1
END
'

[pierre]

Jan 8, 2023 21:48:56 GMT 1 Walt Decker said:

It does not require a knowledge of API. It does require a knowledge of how LB treats all data stored in a file.

I was rather referring to the specific 'kernel32.dll' functions used in your examples.

I looked up the section 'Windows API Things you don't wan to know' for a tutorial, but found nothing about file handling.

[Walt Decker]

I was rather referring to the specific 'kernel32.dll' functions used in your examples.

I looked up the section 'Windows API Things you don't wan to know' for a tutorial, but found nothing about file handling.

I knew you were referring to kernel32.dll, Pierre, but it can be done without using API. It is tricky and the result will be in ANSI, but that is of no consequence.

When I wrote the "Things you don't want to know" series I asked if anyone was interested in file handling. I received no response so skipped that. Perhaps, if there is interest, I could go back and include a file section.

[gaslouk]

Ηι

I believe I downloaded the entire series but haven't gotten around to reading it. I tried to translate it from the internet by opening the .RTF file but the pointers didn't follow. In my attempt to fix this with the little programming I know I was unsuccessful. And through the API_WIN application No registration right. (Copy, translate google, Paste and after save it).

09/01/2023 16:45 <DIR> .
07/01/2023 13:05 <DIR> ..
09/01/2023 16:45 0 a.txt
07/01/2023 12:54 40.875 ADDENDUM_1.RTF
07/01/2023 12:52 15.689 ADDENDUM_2.RTF
07/01/2023 12:54 49.252 ADDENDUM_3.rtf
07/01/2023 12:54 21.629 ADDENDUM_4.RTF
07/01/2023 13:00 39.712 ADDENDUM_5_DEVICES.RTF
07/01/2023 13:01 110.267 ADDENDUM_6_GFX_101.RTF
07/01/2023 13:01 38.629 ADDENDUM_7_GFX_201.RTF
07/01/2023 12:58 91.106 ADDENDUM_8_GFX_JAZZ.RTF
07/01/2023 12:58 238.320 ADDENDUM_9_GFX_3O1.RTF
07/01/2023 16:18 9.162 API_WIN_.CFG
24/03/2022 10:05 122.368 API_WIN_.EXE
07/01/2023 12:55 1.033 API_WIN_APPENDIX_1.RTF
07/01/2023 16:05 27.900 API_WIN_IDX.DIZ
07/01/2023 13:00 5.427 APPENDIX_01.RTF
07/01/2023 13:00 2.192 APPENDIX_02_DEVICES.RTF
06/01/2023 10:35 4.515 APPENDIX_03_GRAFX_101.RTF
07/01/2023 12:58 11.720 APPENDIX_4_ROP_CODES.RTF
06/01/2023 10:34 22.554 atom1.bmp
06/01/2023 10:34 4.654 Checked.bmp
07/01/2023 13:01 60.838 GRAFIX_1O1.RTF
07/01/2023 13:01 24.884 GRAFIX_2O1.RTF
07/01/2023 13:01 62.689 GRAFIX_2O2.RTF
06/01/2023 10:35 23.671 GRAFIX_2O3.RTF
07/01/2023 12:58 59.659 GRAFIX_3O1.RTF
07/01/2023 12:58 23.764 GRAFIX_3O2.RTF
06/01/2023 10:35 15.872 NUMBERMANDLL.DLL
06/01/2023 10:34 54.784 Render.dll
06/01/2023 10:32 4.971 RENDER.DLL_DOCS.TXT
07/01/2023 13:02 63.856 THE_MENU.rtf
06/01/2023 10:34 4.654 Unchecked.bmp
06/01/2023 10:34 57.174 web.bmp
07/01/2023 12:53 25.121 WINDOWS_API_1.rtf
07/01/2023 12:55 46.978 WINDOWS_API_10.rtf
07/01/2023 12:53 13.905 WINDOWS_API_2.rtf
07/01/2023 12:56 27.744 WINDOWS_API_3.rtf
07/01/2023 12:53 12.692 WINDOWS_API_4.rtf
07/01/2023 12:53 36.204 WINDOWS_API_5.rtf
07/01/2023 12:56 78.867 WINDOWS_API_6.rtf
07/01/2023 12:55 43.106 WINDOWS_API_7.rtf
07/01/2023 12:56 17.645 WINDOWS_API_8.rtf
07/01/2023 12:54 46.636 WINDOWS_API_9.rtf
07/01/2023 16:16 177.532 WINDOWS_API_gr1.rtf
07/01/2023 12:55 42.589 WINDOW_PROPERTIES.rtf
07/01/2023 13:00 65.233 WIN_DEVICES.RTF
45 File(s) 1.948.072 bytes
2 Dir(s) 34.274.807.808 bytes free

Gaslouk

[Walt Decker]

Are you asking if those are all the files? I think so.

Are you asking if the files are translated to Greek will they be readable by the exe? No. The exe is not set up to work with unicode.

The addendum files contain LB source code, so if you block translate them to Greek with Google the code will not execute in LB. You will have to translate portions of those yourself.

API_WIN_.CFG and API_WIN_IDX.DIZ are files used by the reader so they are of no value to you.

If you want to translate the others, do so, but you will have to read them individually or write an app so you can read them as a group. I can help you with a app, if you decide to go that route.

[gaslouk]

Jan 9, 2023 11:41:14 GMT -5 Walt Decker said:

Are you asking if those are all the files? I think so.

Are you asking if the files are translated to Greek will they be readable by the exe? No. The exe is not set up to work with unicode.

The addendum files contain LB source code, so if you block translate them to Greek with Google the code will not execute in LB. You will have to translate portions of those yourself.

API_WIN_.CFG and API_WIN_IDX.DIZ are files used by the reader so they are of no value to you.

If you want to translate the others, do so, but you will have to read them individually or write an app so you can read them as a group. I can help you with a app, if you decide to go that route.

I am asking if it is all the files or some of them are missing. From where I downloaded them there were files with the same name but with a different size. So I kept the bigger ones with the same name.

I translated the first of them. In API_WIN.exe it was named PART1, I read it in Greek but the sections did not work. Specifically, you clicked with your mouse to go to the WINDOW BASE STYLES section and it was not responding.

Gaslouk.

I FIX IT. NOW WORKING WELL

I should not have translated the headers.

Attachments:

[pierre]

Jan 9, 2023 8:58:26 GMT -5 Walt Decker said:

When I wrote the "Things you don't want to know" series I asked if anyone was interested in file handling. I received no response so skipped that. Perhaps, if there is interest, I could go back and include a file section.

Oops. I must have missed that one.....bad luck

Yes, of course I would be interested, and perhaps gaslouk also, and/or some other forum members ?

I believe that kernel32.dll has more than a thousand functions, so not easy to find one's way in that labyrinth.

[Walt Decker]

Gaslouk.

I FIX IT. NOW WORKING WELL

I should not have translated the headers.

Good, I thought that the app would not find the links. The rich text control itself is set up for unicode, and it appears that Goggle did a fair job of translation.

Pierre, I will include a section on basic file handling. It will be sometime after I finish the form designed, a project with which I am far behind.

[pierre]

Pierre, I will include a section on basic file handling. It will be sometime after I finish the form designed, a project with which I am far behind.

Thank you Walt !   No problem for the delay.

Of course it should not interfere with any work you have in progress