Announcement

**Stuart McLachlan** · 21 Jul 2020, 09:08 PM

Are you using the current version of CC or an earlier version?
Was it previously compiled using a different version?

Do you have
#DEBUG ERROR ON
#DEBUG DISPLAY ON

and error trapping consistently used throughout the application?

Crashing in different iterations depending on imposed delays suggests that the problem may lie elsewhere and it just manifests itself at this point. Since it has happening during array operations, I'd be looking for an earlier out of bounds error. for a start.

**Rodney Hicks** · 21 Jul 2020, 09:26 PM

FWIW, Stuart's suggestion of #DEBUG DISPLAY ON in conjunction with several labels might be quicker as it will show the last label successfully reached. Your error will be after that point.

**Ellen Reddick** · 21 Jul 2020, 09:57 PM

Now I am really confused. Rodney, I put in #DEBUG ERROR ON and the problem went away! Runs on my computer and on client's. Thank you!

**Steve Hutchesson** · 21 Jul 2020, 10:16 PM

I would still be inclined to track it down as adding a delay may hide the issue but its still there. Have a look at using "TRACE ON" in conjunction with labels to narrow down where the problem occurs. I would also look at the data in the event that it has some quirk that triggers a crash and also if the form of that data does not work with the code you have posted.

**Jim Fritts** · 21 Jul 2020, 11:51 PM

What happens when J& = 0?

**Stuart McLachlan** · 22 Jul 2020, 12:21 AM

Originally posted by Jim Fritts View Post

What happens when J& = 0?

Really?

Then XCust$ doesn't get trimmed and Cust(jk&) is filled with spaces.

Actually I don't think it does what the OP intends.
Unless cust(j%) is filled earlier with some value then If j& = 0, cust(Jk&) is always 75 spaces.

I think she needs
cust(jk&) = Left$(XCust$ & String$(75," "),75)
as the last asssignment, not
cust(jk&) = Left$(cust(jk&) & String$(75," "),75)

**Stuart McLachlan** · 22 Jul 2020, 12:31 AM

Originally posted by Ellen Reddick View Post

Now I am really confused. Rodney, I put in #DEBUG ERROR ON and the problem went away! Runs on my computer and on client's. Thank you!

That's just masking the problem, not solving it. You still need to find the cause, otherwise it is likely to affect your application somewhere else!

DEBUG ERROR ON adds additional code to your application so the coding error is likely to have a different effect

Without DEBUG DISPLAY ON, you can still have an error and not know about it.

Try commenting out none, one and both of the debug lines here and see what happens with an out of bounds error:

'

Code:

#COMPILE EXE
#DIM ALL
#DEBUG ERROR ON
'#debug display on

FUNCTION PBMAIN () AS LONG
 DIM s(1 TO 3) AS STRING
  ? s(4)
  ? "Error passed"
END FUNCTION
'

Note: Compile and run several times. On my machine, commenting out both lines and compiling and running sometimes results in an application that crashes and sometimes runs with no apparent problem,!

**Rodney Hicks** · 22 Jul 2020, 03:28 AM

Ellen, I don't know anything about #DEBUG ERROR ON from using it, I've always been successful( or thought I was) using #DEBUG DISPLAY ON as this example shows:

label1:
Xcust$=MID$(customer,540)
FOR JK& = 34 TO 36:
label2:
J& = INSTR(Xcust$, CHR$(124))
label3:
IF J& > 1 THEN cust(jk&) = LEFT$(Xcust$, J& - 1): Xcust$ = MID$(Xcust$, J& + 1)
label4:
IF J& = 1 THEN Xcust$ = MID$(Xcust$, 2):cust(jk&)=""
label%:
IF LEN(Xcust$) <2 THEN
cust(jk&) = STRING$(75," ")
ELSE
cust(jk&) = LEFT$(cust(jk&) & STRING$(75," "),75)
END IF
NEXT

However, I expect that it will return an error somewhere else in your program if it returns one.
From the docs:

The position descriptor word is the first 8 characters of the name of the last (most recent) label, line number, or procedure that was executed.

You might try the TRACE or the TRY/ END TRY error checking tools.

**Stuart McLachlan** · 22 Jul 2020, 03:54 AM

Originally posted by Rodney Hicks View Post

However, I expect that it will return an error somewhere else in your program if it returns one.

There's no need for a lot of labels: Basic debugging technique, use a binary search:

With both DEBUG compiler instructions on, the first time you run it, it should give the name of the function/sub that the error occurs in.
Place a label half way through that function/sub and re-compile and re-run. This time you will either see the function or the label name.

If it's the function name, place a second label halfway between its current position and the function start.
If it's the label name place one halfway between its current position and the function end.
Re-compile and run again.

Keep halving the problem space and you quickly zero in on the problem line. Just add and delete labels as necessary - you never need more than 3 of them at any one time.

**Stuart McLachlan** · 22 Jul 2020, 04:05 AM

Originally posted by Rodney Hicks View Post

Ellen, I don't know anything about #DEBUG ERROR ON from using it, I've always been successful( or thought I was) using #DEBUG DISPLAY ON

Without DEBUG ERROR ON, array out of bound or null pointer errors are not tested. DEBUG DISPLAY ON won't tell you about those types of bugs unless you have DEBUG ERROR ON as well - you are still likely to get unidentified GPFs.

**Rodney Hicks** · 22 Jul 2020, 04:32 AM

There's no need for a lot of labels:

I know that, but I figured it better for a user to figure that out on their own. (Saved me a lot of typing too!)

Without DEBUG ERROR ON, array out of bound or null pointer errors are not tested.

I don't know about the null pointers, since I rarely use pointers in my own code, but I've used DEBUG DISPLAY ON and your 'binary' approach to find many an 'out of bounds' error, it's my most common type. That being said, DEBUG ERROR ON might find my errors more quickly.

**Dave Biggs** · 22 Jul 2020, 05:00 AM

Without DEBUG ERROR ON, array out of bound or null pointer errors are not tested.

But ..

**Jim Fritts** · 22 Jul 2020, 09:47 AM

Actually I don't think it does what the OP intends.

That is why I asked.

**Ellen Reddick** · 22 Jul 2020, 02:38 PM

Stuart, I am using PBCC 4.04 which apparently doesn't recognize #DEBUG DISPLAY ON. I am a free lance programmer and have been operating under the mantra of "if it ain't broke, don't fix it." This program began in 1985 written in QB for a friend--it was an easy slide into PBCC and has been humming along problem free for many years. The code in question does what it should--anytime each record is saved (in a different SUB) each of these last three memo items are trimmed and chr$(124) is added. Hence, if no memos are filled in, the record ends with three chr$(124)s, so j& is never zero.

It looks like I may have to face changing to a more modern language. How involved will it be to step up to PBCC 5 OR 6? Will my old Tsunami data files continue to work? Or, will I need to embark on mySQL? What about FreeBasic? Most of the programming I have done in the last few years has been MSAccess/vba. I am about to turn 80 and wish to take the path of least resistance! My first job was at Duke after graduation writing in Autocoder -- I am hoping for some sympathy and advice here!

**Rodney Hicks** · 22 Jul 2020, 03:34 PM

You're quickest move would be to PBCC 6. There might be issues, but very few and you're learning curve is essentially joy at finding how easy it was.

**Albert Richheimer** · 22 Jul 2020, 03:35 PM

Originally posted by Ellen Reddick View Post

It looks like I may have to face changing to a more modern language. How involved will it be to step up to PBCC 5 OR 6? Will my old Tsunami data files continue to work? Or, will I need to embark on mySQL?

As a database software, such as Tsunami, is running in a DLL, it is independent from the language you are calling it from. So it doesn't matter which language you are using to translate your code, as long as the calling conventions are followed.

BTW, I am still using Tsunami (with PBCC 6.04 and PBWin 10.04) and its Internet-based counterpart, ttds. The latter is a neat package created by Don Dickinson. As long you are willing leave the Btrieve-oriented systems (Tsunami) you might want to have a look at a relational database, e.g. SQLite and its Internet counterpart SQLitening.

And yes, I can recommend upgrading to a recent PowerBASIC version.

Albert

**Ellen Reddick** · 22 Jul 2020, 04:40 PM

Thank you all for your helpful comments. I am sure I will be back with more problems after I get into PBCC 6.

**Stuart McLachlan** · 22 Jul 2020, 06:49 PM

I agree with previous comments. Step up to CC6. You'll be glad you did.

Actually, going to PBWIN should require very little change to your actual data handling and DDT will give you a far superior user interface at the cost of a little learning.

**Ellen Reddick** · 23 Jul 2020, 08:22 PM

Stuart, I may try PBWIN after I get through PBCC 6. I have installed it and am working through debugging. Almost no problems so far ... until this: I print a lovely double line box with dividers that contain invoice data in PBCC4.

Code:

DATA 2 , 33 , "BROWSE DATAFILE"

DATA 4 , 1 , " Co# Item Style Part Pt # Price"
DATA 5 , 1 , "ÉÍÍÍÍÑÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍ»"
DATA 6 , 1 , "º ³ ³ ³ ³ ³ º"
DATA 7 , 1 , "ÈÍÍÍÍÏÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍ¼"
DATA  9 , 4  , "CFR Price? Y/N            Construction Code:            Ref.Date:"

In PBCC6 the same lines print the characters as shown rather than the lines. How do I get my lines back?

Announcement

erratic behavior--Help!

erratic behavior--Help!

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment