Out of memory

Code:

---

Option Explicit
Dim LStr(3000) As String  'L & R for separating
Dim RStr(3000) As String
Dim Pool(3000) As String

Dim Lines As Integer
Dim Every As Integer
Dim Start As Integer
Dim SepText As String

Dim Spl() As String
Dim Dest As Integer      'toggles, pointing to new txtT(0 or 1) --- (1 - Dest) = current
Dim StrDepth As Integer  'how many lines
Dim Changed As Boolean
Dim Temp As String
Dim v, w, x, y, z As Integer

---

this shouldn't be enough to give an out of memory error, should it?

The error pops up on W2K Pro but not WinME. What the heck!

Don't get a out of memory error on my winXP pro, 640mb of ram...
Anything else that could cause the error?

VB Code:

Dim LStr(3000) As String   'L & R for separating
Dim RStr(3000) As String
Dim Pool(3000) As String

why do you need 3000?

I do need 3000 because it's a text editor that should be able to handle files up to 3000 lines long. Unfortunately the program's crashing before you can even enter or load a line. Having three strings dimensioned to 3000 shouldn't even make a dent on a machine with 32MB. I think it has to be a compatibility issue with w2k.

The information I'm supplying here is pretty scant, but I'm hoping maybe someone's encountered something like this when trying to distribute an app across all platforms of Windows.

The form pictured in the original post is actually unloading and is supposed to be loading up the next form, which is an editor for the test quiz files. It loads perfectly on my winme system, but on the w2k pro, it crashes before you get a glimpse of the next form.

The form I'm trying to load has two RTB's and a very small second form that gathers more information after certain command buttons have been clicked.

Does anyone know more about out of memory popping up in relatively small applications?

Hi
I think ur problem is that u are fixing the size of the string arrays. Try to use a dynamic array and set the dimensions in say the form load or something..

Dim LStr() as String

Form Load
Redim Lstr(3000)

Also, do u realise that ur last line of Dim v, w, x, y, z As Integer creates all Variants except for the z. Variants use far more memory than Integers
Regards
Stuart

Also, u said that the editor needs to be able to handle files of 3000 lines... ok, first i dont understand why u would use arrays for this but more importantly, why cant u set the dimensions of the array based on the number of actual lines... they arent all gonna be 3000? so why create wasted space?

Look into Redim Preserve

Regards
Stuart

WOW ! ! !

Okay, I forgot about using ReDim Preserve (just thinking I had to have megs and megs to spare), and the dim with all the variants is another source of waste!

Thanks, I'll get to work on this and tell you if it solves it, but still, doesn't it seem like that shouldn't even make a dent?

I looked up Out of Memory in the VB help (not listed) and in the forums here, but I haven't got any info on how much you can use in VB and what kind of code can crash the system with this error.

Hi again
I remember reading an old VB3 book and the author went on for a whole chapter about memory issues to do with declaring arrays to a fixed size in comparison to dynamic arrays... i got the point after the first page but he went on and on and on... :D

Also, u can get memory problems when variables are declared locally within a sub (as against at module level) becos of the way that VB references the stack.

Regards
Stuart

According to your jpg, it seems it errs out AFTER the form load.
Is this True?
-Lou

Is it erring when you're actually loading the info from your files during initialization?

If so, could you post that code?

I really don't think its the Dimming in the Gen Dec area thats crashing it.

-Lou

The jpg shows the frmQuiz from which the quiz editor has been selected. Before the quiz can unload and the editor becomes visible it mems out.

I figured since it should be able to handle 3000 lines I might as well just reserve that many anyways, but I have since taken your advice and now it's all ReDims and ReDim Preserves.

Quote:

---

Also, u can get memory problems when variables are declared locally within a sub (as against at module level) becos of the way that VB references the stack.

---

Okay, I use option explicit on every form, and most forms have about 5 temporary integers for loops and the like. I'm not 100% clear on what you're saying in the above quote, but I'm gathering that you're saying it's a better idea to make those public instead of dimensioning them with every form (which is what I have been doing)?

Quote:

---

Originally posted by mikeycorn
Before the quiz can unload and the editor becomes visible it mems out...................
most forms...........

---

Well, if you've made those changes that you just mentioned, if everything is now working fine, then ignore this post.

But, If your Arrays are dimmed in the "quiz" form, and you use them in the editor form, but you unload the quiz form as your loading the editor, I wonder if your arrays are then usable at all?

But, of course you're not unloading the form where they're dimmed if they're needed on another form. :D

There are 27 variables declared in public statements in the module, and each form has somewhere in the neighborhood of ten variables specific to that form declared in dim statements.

Most forms also have about the same five integers used for loops and temporary values declared in the general declarations:

Code:

---

Option Explicit
Dim v As Integer
Dim w As Integer
Dim x As Integer
Dim y As Integer
Dim z As Integer

---

I'm going to give it a whirl and check memory usage with system monitor to see if there's a difference if they're declared publicly in the module instead of in the individual forms.

Okay, it was a very rudimentary experiment, but here's what I found:

There were only five integers that I moved from being dimmed in each individual form to being publicly declared in the module, so I didn't expect to see a large difference, but there was no measurable difference at all. I know, I know, no surprise there. What was interesting, however, was that both versions of the program (each tested five times and running each time on a fresh reboot and loading the same quiz) . . . both ended up using either 5.1 megs or 5.6 megs of unused physical memory in system monitor. The interesting thing was it was either 5.1 or 5.5 or 5.6 with nothing inbetween.

With my program using only around 5 megs though, it gets me back to wondering what's causing that out of memory error. I mean, c'mon, there are some really huge apps out there written entirely in VB and you can see them loading their MSVBVM's on install and you know they're using way more than 5 megs and they never seem to get the error . . .

That is so f***in' typical of Microsoft! If the program crashes, hey just call it out of memory and make it look like it's a problem with the hardware and system configuration!

It reminds me a just bit of one of the things that came out in the anti-trust lawsuit. One of the tactics they used to sabotague competition when DOS was still king and Dr. Dos was the upstart competitor was to program in fake compatibility warnings and errors when Word detected Dr. Dos.

Anyway, thanks for the tip. I'll have to broaden the search for the problem.

A thing you should note...

Sometimes when a function is called improperly it returns the error out-of-memory instead of anything of substance.

For example:

rixhtextbox1.text = chr$(Val("&h0001"))

thats my point digital ms has some weird ways of dealing with things rather than give a more descriptive error or acurate

Mickeycorn does this generate the same error in the ide or after compiled?
would this work for an experiment place try this in the sub that causes the error

on error goto errhandler:


exit sub
errhandler:

if err.number = 7 then resume next
end sub
if you place that in the function or sub that gives the error will it continue or try resume next just to see if it's a real error as i have used it in the past to get by an error I couldn't figure out

my motto you can hide some dirt under the rug without anyone knowing ;)

You know, this morning I awoke in a great mood, with many new features implemented in the past few days and a confidence that the latest version was running rock solid on many different machines. Then I received the dreaded email from one of my beta testers and for the rest of the day, I bounced back and forth between anger and depression as I tried to figure out how this message was popping up on his configuration.

Well get this: I just got off the phone with him and he tells me that the machine he's been working on has seen all sorts of different installs and networks from Novell to Linux co-existing with Windows and now he thinks that it's probably a problem with his OS and not my program.

AAAARRRRRGGGGHHH!


Some of the suggestions here have helped me to make the code tighter though, so at the end of the day I guess it's all good.

Quote:

---

Originally posted by mikeycorn
I'm not 100% clear on what you're saying in the above quote, but I'm gathering that you're saying it's a better idea to make those public instead of dimensioning them with every form (which is what I have been doing)?

---

Sorry Mikey if i didnt make myself clear. By local i was referring to variables dimensioned within a subroutine eg

VB Code:

Private Sub DoSomething
    Dim localVariable as String
 
    .... etc
End Sub

The usual error for that is Out of Stack Space anyhow but was just trying some things to fix ur problem.

So, u can leave ur variables as form level which will reduce memory and resource usage if u are unloading and loading the form as required.

Regards
Stuart

Okay, I know this is getting really nitty gritty, but if most of the forms use three to five temporary integers for loops and what not, and you go from one form to another loading and unloading each individually, you think it's a better use of resources to dim them in the individual forms as opposed to public in the module?

(Just getting way too focused on the little things . . .)

Hi
It would have minimal impact at all. Firstly cos the variables are likely to be integers or longs. Secondly, with both methods u will always have those variables 'active' once only.

It's the biggies that u got to watch out for such as ur 3000 element array. It is important that u dimension them in the correct place to minimise resource and memory usage .. and of course u need to take the scope into account. ie if u need them thru one whole form then it is best to make it a form level variable. If only using it for a specific calc and then dumping u can use local but again u have to be aware of the size of ur array and its effect on the stack.. from memory it's a 64k limit.

I personally use a public variable for 1 integer counter and 1 long counter so it saves me having to dimension variables over and over. Is a matter of personal choice i guess.
Regards
Stuart