Array's in Callback functions

[Scott Turchin]

Dumb question, are Arrays STATIC in a callback function or not?

I've seen some weird behvior with an ar ray of mine and just wondering if it's because it's not static.......?

Tried to RTFM but didn't find what i was looking for.

Tx,

[José Roca]

They are if you declare them as static; otherwise don't. As any other variable, BTW.

[Chris Holbrook]

Dumb question, are Arrays STATIC in a callback function or not?

I've seen some weird behvior with an ar ray of mine and just wondering if it's because it's not static.......?

I'm assuming that you declare the array inside the CALLBACK function. Does the weird behaviour stop if you declare it STATIC?

[Rodney Hicks]

Is this a case of not using #DIM ALL?

[Richard Angell]

Is this a case of not using #DIM ALL?

No. #DIM ALL would require an array be dimensioned before use, but in a callback the array must be declared STATIC if you want the values to be persistent while the program is running. This was Scot's problem.

Jose already noted this as well as pointing out that any array declared inside of callback would have to be declared STATIC as well if you wan is value to be persistent during program operation when the callback is active.

However if the array is being passed to the callback, it must be persistent, STATIC, where it is declared and dimensioned. Otherwise it goes out of scope and is erased. Even a GLOBAL array needs not just its declaration but it needs to be dimensioned before use as well.

[Chris Holbrook]

However if the array is being passed to the callback, it must be persistent

meaning GLOBAL, STATIC, or DIM AT, presumably.

[Rodney Hicks]

Thanks Richard,

Got it. I was thinking though that he might have missed some element of the declaration because he didn't have the #DIM ALL and it wasn't being flagged by the compiler as a result. No idea what specifically.

[Richard Angell]

Chris,

DIM ... AT does not guarantee persistence. By persistence, we would mean the memory is allocated and the data valid for the access we are using. The help (DIM) notes this about absolute arrays, note that you can get a GPF if the underlying memory has been deallocated by the procedure that created it:

Care must be exercised when using absolute arrays, since the contents of an absolute array can only be valid for the scope of the memory the array references. If an absolute array references memory that is LOCAL to the procedure, the array contents become invalidated if the target memory block is released. For example, by either explicitly deallocating the memory block, or exiting the procedure itself. Attempting to access absolute array memory that has been deallocated will likely trigger a General Protection Fault (GPF). On this basis, absolute arrays should be LOCAL to the procedure in which they are to be used.

[Bob Zale]

The important point here is a very simple one:

An array in a Callback function is no different than any other array.

An array is an array, regardless of its location. The rules do not change.

Best regards,

Bob Zale
PowerBASIC Inc.

[Scott Turchin]

I just made it a global array...

I'll go back when time permits and test this - basically it was holding a thread handle for a thread, and when it was released that piece in the array could be used, thus limiting 250 connections by limiting how many threads could be opened...

This is a point where a global came in handy, but I'll go back and try.

Dim MyArray(1 to 250) as long

Static MyArray(1 to 250) as long blows up.

I need to RTFM on this standbye..

[Michael Mattias]

S    = STRING$ (250 * 4 ,0)  ' 4 = sizeof(Long)
REDIM L (255) AS LONG AT STRPTR(S) 
L(0)   = 19 
L (12) = 12345
...

' ie, you can pass an array as a string, as long as you 'REDIM AT' before using.

Easiest way:

FUNCTION WinMain

  LOCAL S AS STRING 

  DIALOG NEW.... 

   S = STRING$ (250 * 4, 0)    ' space for 250 LONG elements 
   DIALOG SET USER hDlg, N, VARPTR(S)   ' VARPTR not STRPTR here 


CALLBACK FUNCTION ....
 LOCAL PS AS STRING PTR , L() AS LONG

   ....
       DIALOG GET USER CBHNDL, N TO pS 
       REDIM   L (LEN(@ps)\4 -1) AT STRPTR (@pS) ' redim based on current string length. 
       SHOW FORMAT$(L(12))

MCM

[Scott Turchin]

Dim hThread(1 to BBSDown.MaxThreads) as Static Long


That did the trick, I wrote a debug log during each request from the webserver and hammered it with 20 instant hits, and I saw

lLoop: 1, thread handle 218
lLoop: 2, thread handle 272 (or whatever0

etc through 20.

Thanks, question answered!

[Cliff Nichols]

Actually it brings up a question.
Is "Static" really a global, but kept within the function in its described? kind of thing.

On one hand, static is easier to read within the scope of your function (and especially debugging), on the other Global is accessed from all functions (but can cause trouble if one function changes the value of the variable, when the other function is working on it)

Probably a matter of choice (as its long been debated), but I just wondered the idea of WHY static is better???

[Michael Mattias]

>Is "Static" really a global, but kept within the function in its described?

Yes. The data are stored the same as GLOBAL variables, although at compile time the variable name is recognized only within its defining procedure.