|
Post by Walt Decker on Sept 28, 2022 9:57:00 GMT -5
Liberty BASIC 4.5.1 and LB PRO have some differences. Hopefully, with your help, I can find the problem. In FUNCTION AddLvData() delete the lines I had you add. PRINT "UPDLINE = "; UpdLine PRINT "LVHNDL = "; LvHndl EXIT FUNCTION In FUNCTION PvWinSetUp() comment this line: CALLBACK Ptr2Code, FN.MedMenuCB(ULONG, ULONG, LONG, LONG), LONG That will disable the menu bar and allow program tracing. At the top, just below label [END.GLOBALS] comment these lines: CALLDLL #LBCB, "FN_InitMenu", _ WinHndl AS ULONG, _ '<--- handle of window with menu MNU.PRINT AS LONG, _ '<--- lowest menu id number MNU.BACKUP AS LONG, _ '<--- highest menu id number CodePtr AS ULONG, _ '<--- code address of LB callback function RetVal AS LONG '<--- RETURN: Non-zero on success
In SUB ENTER.SUBMIT just above RetVal = FN.AddLvData(UpdFlag) add: TRACE 2 so the code looks like: TRACE 2 RetVal = FN.AddLvData(UpdFlag) Then run in debug mode. When it stops at RetVal = FN.AddLvData() step through the code.
If it fails, a message in the debugger status bar should indicate the cause.
|
|
|
Post by pierre on Sept 28, 2022 11:17:58 GMT -5
Thank you.
Here are my findings after running in debug mode:
The app stops in the function FN.addLvData(UpdLine)
at line:
CALLDLL #LV, "FN_LvLineCount", LvHndl as ULONG, NumLines AS LONG
the text in the status bar says : 'Program halted Dynamic Link Library call error'
I have the dll in the default directory:
LvCtrl.dll - last modified June 11, 2022 07:06, 53 Ko.
Is this the correct version ?
pierre
|
|
|
Post by Walt Decker on Sept 28, 2022 13:43:23 GMT -5
Thank you for your persistence, Pierre. The date on the version should have been 9-25-2022. How the June version got in there, I have no idea unless I had one of those senior moments when I loaded the .zip. I replaced LvCtrl.dll in MED_V2F.zip; the app should work now. The date on LvCtrl.dll should be 9-29-2022. I recompiled it this morning just to make sure there are no compile-time errors.
EDIT: Since the app is finding the dlls and creating the list view control with no problem, the location of the dlls appears to be fine. I assume that LB uses the Windoz standard search sequence for locating supporting dlls.
Thank you.
|
|
|
Post by pierre on Sept 28, 2022 15:34:08 GMT -5
Thank you so much ! The app is now working without any problem.
I'll try to study your code more thoroughly..... Very interesting, but not easy to follow.... I am far from being an expert.
pierre
|
|
|
Post by Walt Decker on Sept 28, 2022 16:22:59 GMT -5
A good portion is just interface setup code. If you think event, the code is not difficult to follow. The login window has checkbox and radio button events (which are ignored), and one controller event. The controller event is in FUNCTION FN.CreateLogIn() at [LOGIN.TBN]. This section of code gathers the information from the edit controls, the checkboxes and the radio buttons and creates the directories and/or files necessary and updates them. When it finishes it returns to the line of code immediately following the code that called it. That is when all the other windows are created. FUNCTION FN.Sleeper() acts as a timer and an interrupt to allow other events to occur.
FUNCTION FN.MedMenuCB() monitors the menu bar. Menu events are trapped there and the appropriate action is taken based on which menu item was selected.
SUB ENTER.SUBMIT () handles the entry of data in the ENTER tab. It determines whether to add a new line to the list view or insert revised data in a list view line.
If you need more specific help, do not hesitate to ask.
|
|
|
Post by pierre on Sept 28, 2022 16:49:51 GMT -5
OK. With all these details, I will be able to make a good start. Thank you !
|
|
|
Post by Walt Decker on Sept 29, 2022 18:32:24 GMT -5
If anyone is interested in studying the code in MED_V2F._BAS I have cleaned the code up and commented each function. If you want the commented code, send me a private message with you e-mail address. I will send you a .zip file copy.
|
|
|
Post by pierre on Sept 30, 2022 5:22:08 GMT -5
I discovered one thing more, apparently related to your recent discussion with Brandon about double precision numeric values in structs.
In answer to Brandon's suggestion, you wrote : << I could do basically the same thing with NUMBERMAN.DLL but since I only needed 5 digits,I just redefined the element as char[6] >>
So, this was all about the 'Weight' item of the 'personal vital signs', wasn't it ? I suppose that you needed a value with one decimal place, which means double precision in LB. Something like 150.2 lbs, which are just 5 digits. Creating a 6 digits ASCIIZ string 'char(6)' would have been the solution, and that was exactly what you did.
So far, no problem. The values are correctly stored as '150.2' in the LST data file and printed out in the same way in the RPT report file.
But what happens if one enters just 150 or 150.0 ? In both cases and in spite of the decimal point, LB will consider these values as 'Integer' and the app will store and print them as : '00150'. Well, nothing catastrophic of course, but it creates some inconsistency in a printed report.
I found a solution:
In the function 'WriteMedRecord', replace the line 'PRINT #Tag$, tMedV2.Weight.struct' with the following line: PRINT #Tag$, USING("###.#", VAL(tMedV2.Weight.struct))
If NUMBERMAN.DLL could handle this in the future, that would be fine. In the meantime, one could use the workaround.
pierre
|
|
|
Post by Walt Decker on Sept 30, 2022 10:27:50 GMT -5
Pierre, thank you for your solution. It is much more eligant than mine.
You are correct. NUMBERMANDLL.DLL has functions in it to take any number and create a 2, 4, or 8 byte ANSI representation of that number and translate it back. The problem is Liberty does not adhere to the accepted standard for storing data in a file. It regards all data stored in a file as character data. Since I elected to use Liberty's file protocal instead of API functions I had to translate all numerics to ANSI on file write and then back on file read. If I used API the entire structure record could be written and read with one statement.
You appear to be much more conversant with programming than you profess, Pierre. Most here have never heard of an ASCIIZ string. And you have had no problem following the logic and flow of the program. Thank you for taking an interest.
In what part of France do you live?
|
|
|
Post by pierre on Sept 30, 2022 11:12:32 GMT -5
North of France, nearby the Belgian border.
|
|