Microsoft KB Archive/101880

= How to Increase Free Near Heap to Work Around 'Out of memory' =

Article ID: 101880

Article Last Modified on 8/16/2005

-

APPLIES TO


 * Microsoft Visual Basic for MS-DOS
 * Microsoft BASIC Professional Development System 7.0
 * Microsoft BASIC Professional Development System 7.1
 * Microsoft QuickBasic 4.0
 * Microsoft QuickBASIC 4.0b
 * Microsoft QuickBasic 4.5 for MS-DOS

-



This article was previously published under Q101880



SUMMARY
This article gives suggestions on how to work around the following errors:

Out of memory (code 7)

Stack plus data exceed 64K (L2041)

These suggestions apply to both interpreted and compiled programs.



Diagnosing Near Heap Depletion
The error "Out of memory" happens when you run out of either near heap or far heap space. Usually, you run out of near heap space. Determine which area is depleted by printing out the amount of free space in each area as shown below: ' show number of free bytes far heap: PRINT FRE(-1) ' show number of free bytes near heap: PRINT STACK   ' for VB-DOS and Basic PDS PRINT FRE(0)  ' for QuickBasic If you find that you have the same amount of free hear and far heap space, far heap is depleted. You should print these values as near as possible to the point in your program immediately before the "Out of memory" error occurs.

Increasing Free Near Heap
Add the REM $DYNAMIC (or '$DYNAMIC) statement to the top of each module and form. This statement allows you to change the number of elements in your arrays at run time (by using REDIM). Even more important, the statement causes the arrays to store in far heap rather than near heap. Arrays of variable-length strings are an exception; they are always in the near heap whether or not they are dynamic. DIM a(1000) AS INTEGER ' static array, stored in near heap REM $DYNAMIC DIM b(1000) AS INTEGER ' dynamic array, stored in far heap Convert arrays of variable-length strings into arrays of fixed-length strings to allow REM $DYNAMIC to store this data in far heap. For example: ' example arrays of variable-length strings DIM a$(2000) DIM b(2000) AS STRING ' example array of fixed-length strings, up to length 16 each DIM c(2000) AS STRING * 16 Use the RTRIM$ function to remove trailing spaces from fixed-length strings when you retrieve them from the array. For example a$(1) = "hello" PRINT "<" + a$(1) + ">"         ' prints c(1) = "hello" PRINT "<" + c(1) + ">"          ' prints PRINT "<" + RTRIM$(c(1)) + ">"  ' prints Using fixed-length arrays typically increases the storage required for each string because space is reserved for the maximum possible length. If you require an array larger than 64K, invoke the interpreter or compiler with the /Ah option. Otherwise you receive "Subscript out of range," error 9.

VBDOS /Ah -- Visual Basic for MS-DOS

QBX /Ah -- Basic PDS

QB /Ah -- Microsoft QuickBasic

BC /Ah ... -- compiler for all 3 products

If you require an array larger than 128K, specify the length for each string in the array as a power of 2 (2, 4, 8, 16, 32, and so on). otherwise you receive the error "Subscript out of range." DIM a(8000) AS STRING * 17 ' causes error "Subscript out of range" DIM b(8000) AS STRING * 16 ' okay Create arrays of one element out of large variables that are not already arrays and are not variable-length strings. This causes REM $DYNAMIC to store them in far heap rather than near heap. User defined type variables and fixed-length strings are good candidates. For example, TYPE aType s AS STRING * 1000 a(100) AS LONG END TYPE DIM t1 AS aType             ' stored in near heap t1.s = "hello" PRINT t1.s  DIM t2(0) AS aType           ' stored in far heap t2(0).s = "hello" PRINT t2(0).s

DIM f1 AS STRING * 2000     ' stored in near heap DIM f2(0) AS STRING * 2000  ' stored in far heap After adding REM $DYNAMIC to a support module (a .BAS file other than your start-up file), you may encounter a side effect problem with the symptom of error "Subscript out of range." This happens on arrays defined with DIM SHARED at the module level of a support module. Similarly, after adding REM $DYNAMIC to a form, you may encounter the error "Executable code not allowed in module level of a form." These errors are due to REM $DYNAMIC changing DIM SHARED from a compile-time statement to a run-time statement for arrays.

To work around the "Subscript out of range" side effect problem, define the array at the module level and allocate the array in a SUB or FUNCTION. Use a STATIC variable to keep track of whether the array has been allocated. For example: REM $DYNAMIC DIM SHARED b AS INTEGER

SUB s STATIC is_alloc AS INTEGER IF NOT is_alloc THEN DIM b(1000) AS INTEGER is_alloc = -1 ' true END IF

b(100) = 123 PRINT b(100) END SUB To work around the Visual Basic error "Executable code not allowed in module level of a form," define the array at the module level and use REDIM to allocate the array from the Form_Load event handler.

Additional query words: VBmsdos QuickBas BasicCom B_VBmsdos 1.00 b_basiccom 7.10 b_quickbas 4.50

Keywords: KB101880

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.