Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Ins. Memory on SHOW GET

Status
Not open for further replies.

Brak

Programmer
Jul 11, 2001
158
US
I have noticed something odd as I have been messing around trying to get a program to work.

I have a pop-up @ GET from an array with 3400 entries.
When the screen is drawn, or an SHOW GET or SHOW GETS is issued no problem happens, unless the value of the variable is at entry 386 or higher, then I get the dreaded "Ins. Mem." error.

So to re-articulate:
There is an array called BIG_ARRAY
I have a pop-up called BIG_POP.


When BIG_POP = BIG_ARRAY(1) to BIG_POP = BIG_ARRAY(385) all is fine, the screen draws ok and SHOW GETS work swell.
When BIG_POP = BIG_ARRAY(386) or higher then when the screen draws or when a SHOW GET is issued the "Ins. Mem." error comes up.

I don't expect an immediate solution. I was just hoping to tell of what I have observed. Maybe this info will help someone put two and two together and create a solution.

I just find it odd that the "Ins. Mem." error doesn't trigger when the array is created, or when the pop-up is drawn or refreshed - but it triggers when the variable is set to a value way down the list, after the 385 element.

Once again.
ALEN(BIG_ARRAY) = 3400
BIG_POP=BIG_ARRAY(1): No error on draw and SHOW GET
BIG_POP=BIG_ARRAY(386): Error on draw and SHOW GET


B"H
Brak
 
I remember running into something like this when my 2.6 apps started running on faster machines. I think the problem was that the machine was outpacing fp's speed in getting the data for the array. I think the fix was to build a wait loop into the snippet that was fetching the data. I can dig out the old code if needed.

HTH

Joe Halloran
 
Try going to and getting Lee's "FPWListBox: "Insufficient Memory" error workaround for fast CPU's - explanation/instructions in readme.txt file, and sample screen/table included. (07/05/98)"

Rick
 
J Hall,

If you could do that I would appreciate that.

RG Bean,
I downloaded it before and it only deals with list boxes, not pop-ups. Unless, of course, I missed somthing.


I found somthing interesting.
I downloaded a trial version of CPUKiller. I set it to slow my computer to 150Mhz. And my program works fine (no errors) but extremely slow. Slower than what I remember it running on the slower computer that I developed the code on.

I just think its weird that the error reports an memory problem, when the memory isn't the real issue.


B"H
Brak
 
Dave,

I looked over your code before, but I create my pop-up using the screen generator.
How would one impliment this in a snipet. Would it go in the When or Valid snipet or where (such as using the comment field and using GENSCRENX)?


B"H
Brak
 
Brak -

My app was fpw not fpd. The control is a listbox. I cannot remember where this fix came from - I did not create it. The fix was to define (in the screen generator) the item source as from a field and then enter a function call instead of a field:

showitem()

where:
Code:
proc showitem
PRIVATE Dummy && dummy variable slows down list box.
Dummy = "Dummy"
sele itemtable
*or if necessary you can use
*Private I
*FOR I = 1 TO 50 && or more than 50
*ENDFOR

RETURN itemtable.item && or other field combo's

Essentially you are creating a separate additional step in the process of grabbing the field values from the source table and this slows things down enought for fpw to keep up. The For loop would slow it down even more - I found that the function call itself did the job.

HTH - but it might not ;-)

Joe Halloran
 
Not sure if this would work, but you can try adding this line to the screen setup snippet:
ON ERROR *

Then in the Valid snippet for the popup, add:
ON ERROR

or change it to your default error handler, such as:
ON ERROR DO errhand WITH ;
ERROR(), ;
MESSAGE(), ;
MESSAGE(1), ;
LINENO()

Another option is to create that popup as a separate function and call it as a Valid function using a text box in place of the popup on your screen.

Otherwise, as much as I hate to say it, change the generated code. I know, it violates the rules of using the generator, but maybe the elimination of the problem is more important.
Just be sure to comment it well.



-Dave Summers-
[cheers]
Even more Fox stuff at:
 
JHall,

As this is a popup, the fix you gave for a listbox won't work. The popup dialog only allows for the popup to be based on a predefined list in the dialog, or an array.
I am using an array. If you try to put a function call in the array field Foxpro yells at you for it.


Dave,
I tried the tip to place the ON ERROR commands as you have directed in the Setup and Valid. When I select a high element on the popup the error message with the "Suspend Cancel Ignore" comes up, and I press "Ignore". I am abel to continue to use the program until I touch the popup again at which time I get another "Suspend Cancel Ignore" box, but upon pressing "Ignore" this time the program exits back to the command box.


The Mystery/Adventure continues.


B"H
Brak
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top