Paging Sherlock Holmes....

[Bern Ertl]

I've split my app up into a main .EXE and two supporting DLLs.

One of the DLLs acts as a reporting module. It's rather large
right now and approaching the 16K line limit of the PB IDE. This
code compiles without error.

However, when executing, I get the dreaded "This program has
performed an illegal operation and will be shut down." error after
the "Setting strings" message box. The following message boxes
are not displayed.

Any ideas?!?!?

         FOR J& = 1 TO UBOUND( Shifts$())
            szTemp = Shifts$( J&)
            SSSetData hSpread&, 1, y&, szTemp
            szTemp = FORMAT$( TPre&( J&) + TTA&( J&) + TPost&( J&))
            SSSetData hSpread&, 2, y&, szTemp
            szTemp = FORMAT$( TotalRevHours&( J&))
            SSSetData hSpread&, 3, y&, szTemp
            szTemp = FORMAT$( LvlCrew&( J&))
            SSSetData hSpread&, 5, y&, szTemp
            szTemp = FORMAT$( Crew&( J&))
            SSSetData hSpread&, 4, y&, szTemp
MSGBOX "setting string"
'I get an error after this MSGBOX
            szTemp = szTemp + "," + FORMAT$( LvlCrew&( J&))
MSGBOX "setting data in spread"
'This MSGBOX is not displayed
            SSSetData hSpread&, 6, y&, szTemp
MSGBOX "no problem"
            IF y& = SSGetMaxRows( hSpread&) THEN SSSetMaxRows hSpread&, y& + %DefaultCPMArraySize
            INCR y&
         NEXT

------------------
Bernard Ertl

[Bern Ertl]

Well, I added the following to the code posted above:

MSGBOX "y&="+STR$( y&)
      IF TotalEst& THEN
         FOR J& = 1 TO UBOUND( Shifts$())
MSGBOX "setting string. J&="+STR$( J&)+", y&="+STR$( y&)

and the first message box confirms y& = 1. The second message box
generates another "This program has performed an illegal operation and
will be shut down." error.

I'm guessing that the string functions (STR$, FORMAT$) are
the source of the error because of some memory issue. Is there
anything I can check to verify this?

I do have a lot of arrays in memory (both local and global).

Help!!!



------------------
Bernard Ertl

[Phil Tippit]

Bern,

Have you checked to make sure all your long array variables are
dimmed probably. put msgbox in to display Str(ubound(LvlCrew&()))
etc.

Phil

------------------
E-Mail: [email protected]

[Bern Ertl]

Hi Phil,

Thanks for the suggestion. I have DIMensioned all the
arrays referenced in the code snippet. You can see in the
original post that I have already assigned FORMAT$( LvlCrew&( J&))
in an earlier statement without error.

This is extremely frustrating. I've double and triple checked
all my array references and the code looks solid.....



------------------
Bernard Ertl

[Bern Ertl]

A little bit more testing has revealed that replacing :

            szTemp = szTemp + "," + FORMAT$( LvlCrew&( J&))

with :

            Temp$ = szTemp
            MyFormat ptrszTemp, LvlCrew&( J&)
            szTemp = szTemp + "," + Temp$

also yields the "illegal operation" error. Perhaps it is not
with the STR$/FORMAT$ but with the string engine in
general (ie. '+')?????

MyFormat is the ASM routine which I have previously posted on
the Forum and works solidly.



------------------
Bernard Ertl

[Sven Blumenstein]

Bern,
try to replace the '+' with the '&' operator.


P.S.:
Or try to use the lstrcat or wsprintf API's


------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected][email protected]</A>

[This message has been edited by Sven Blumenstein (edited June 11, 2001).]

[Tom Hanlin]

The & operator is identical to the + operator here and will make no difference.

It would be useful to check ERR and ERRAPI to see if they offer any information.

Given the size of the module in question, it is conceivable that you've run out
of space for string literals. However, without more detailed detective work,
that's just a wild guess.

------------------
Tom Hanlin
PowerBASIC Staff

[Bern Ertl]

Hi all,

I've been tinkering with my code using an unending procession of
message boxes. I found a loop which was stuffing values into 6
arrays well beyond the array limits (subscript of 50, UBOUND of 23!).
I had assumed app would GPF in that case, but it appears that that
did not happen immediately.

I had several frustrating bugs in my code that were all causing
mysterious behaviors. I think I've identified them all.

BTW, I think there may be a problem with the MAT command. In the
following code, it only sets the value of element indexes 0&1 to
value 1. Elements 2-10 remain zero. I haven't checked the FAQ to
see if it has already been reported yet, but here it is anyway:

'PBDLL 6.0
#COMPILE EXE

FUNCTION PBMAIN() AS LONG

   REDIM ResFlg?( 10)
   MAT ResFlg?() = CON

   FOR J& = 0 TO UBOUND( ResFlg?())
      MSGBOX "J&="+STR$(J&)+", ResFlg?( J&) ="+STR$( ResFlg?( J&))
   NEXT

END FUNCTION

------------------
Bernard Ertl

[Eric Pearson]

Bern --

> I found a loop which was stuffing values into 6
> arrays well beyond the array limits (subscript of
> 50, UBOUND of 23!). I had assumed app would GPF
> in that case, but it appears that that did not
> happen immediately.

Windows will display an Application Error message box that says "write error" (aka a GPF) if your program attempts to write data to a memory location that it does not "own", i.e. outside the memory area that has been allocated to it by Windows. If an array-subscript error causes PB to attempt to write data to an incorrect memory location, but that location happens to be owned by your program (perhaps another array or other data), Windows will not detect the "error". After all, your program owns that memory and can do anything it wants with it.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Tom Hanlin]

REDIM ResFlg?( 10)

Looks to me like the compiler isn't happy with seeing a REDIM here.
I'll take it up with R&D.

------------------
Tom Hanlin
PowerBASIC Staff

[Bern Ertl]

Eric,

That's what I figured (after I found the problem).

Tom,

Same behavior occurs if you change REDIM to DIM.
I just cut & pasted that snippet from my code and didn't
bother to change the REDIM. It appears that the issue
is using a BYTE array....



------------------
Bernard Ertl

[Lance Edmonds]

I'll have to double check (I'm not at my DEV PC right now), but the problem could be the use of a byte array with the MAT statement... I'll research this and post what I can find out.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>