It is possible to get an Out Of Memory error from VB with much memory free. The following is what I have read or deduced while looking into this.
You Are Not Really Out Of Memory
The Out Of Memory error is somewhat of a catch-all to cover different situations. Per Microsoft Knowledge Base Article - 190217, Visual Basic maintains the following five resource heaps, a heap being a portion of memory organized in a particular way: 1. The 16-bit User heap (64K). 2. The 32-bit User window heap (2MB). 3. The 32-bit User menu heap (2MB). 4. The 16-bit GDI heap (64K). 5. The 32-bit GDI heap (2MB). Apparently, if you run out of any of these, you can get the out of memory error. Hence, on a machine with 1 Gig of memory, you can get an out of memory error if you want to store more data in the 64K 16-bit user heap and it is full.
This same knowledge base article says that Windows 2000 (as opposed to Windows 98, for example) handles the memory for these heaps differently and situations where you would get an Out Of Memory error in Windows 98 will not give you one in Windows 2000. So before you try to change your software to lower the memory it requires from the heaps, you might consider moving to Windows 2000 if you haven't already.
If you want to move to Windows 2000, this might mean that your users would have to move as well. In my situation, at least, running the .Exe ran into the same Out Of Memory errors as I found when stepping through the code using the debugger. This means that the memory problem I saw in debug mode in Win 98 would occur with my users running the .Exe in Win 98.
We did go to Windows 2000 eventually and the problem did go away. The following is what I learned before we were able to transition.
If You Still Need To Handle This
My problem was trying to load one form in a project. It was a very large form, but not that much bigger than others that had no memory problems.
Also from the knowledge base article, the following quote: "If your Visual Basic application loads a very large number of certain controls, such as Combo Boxes, you may run out of system resources, which will result in an "out of memory" error (error #7)".
This form had many controls on it, including many combo boxes. In playing with changes to the form and in searching the Internet, I learned the following: > The amount of memory you need for the controls on a form is not linear. VB seems to handle up to 150 controls well, but above that it gets increasingly demanding. For example, 225 controls would require more than one and a half times the memory a form with 150 controls would need. > The amount of memory required to load a form is more than it takes to run it. Specifically I could load large form A and then small forms B and C. However, I could not load B and C and then load A. This only made sense to me if a form took an additional amount of memory to load, the bigger the form the more additional memory the load would take. > What I found on the internet talked about using control arrays to lower memory demands. Instead of having 10 separate controls, use a control array with 10 members. From what I read, I would have thought that a control array takes the same memory as one control. From playing with it, I found that deleting a control array with 18 members made the memory demands of the form much less than deleting a single control not in an array.
My solution was to move controls off of the large form. I was able to remove enough to make the form load when I needed it to load.
Finding Out Where You Are Running Out Of Memory
Per the knowledge base article, there is a 16-bit VB routine called GetFreeSystemResources. This returns a single percentage, that percentage essentially being the amount of free memory in the heap with the least amount free. Presumably, this is the one that you will run out of next, but not necessarily. I do not know of any way to track the amount of free memory in each heap. It would be nice, as it would be much easier to learn how to handle the memory issues here if you could track how each heap changed with the different actions your system performs.