FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

RESOURCES

Prevent from memory errors with resources


Each time PG, or FB, or you, make a call to CHANGEDRESOURCE, the resource manager sets aside room for the resource and adds an entry to its internal table of resource handles. If you change the _same_ resource again, space for it is set aside again and an additional entry is made in the resource managers private pouch of info. Therefore, your multiple calls can have two possible (bad) side effects.

1) The resource table can only handle 2127 entires. (That was why I mentioned a year or two ago that a database system built entirely on resources would not usually work.)

2) The resource manager continues to add up the space required as tho it would have to rewrite every resource that has ever been changed (or added). If you change a 5K resource 200 times then Mr. Res Manager is looking at 1000K that it wants to set aside. You'll run out of disk space even tho you shouldn't have.

The fix... (This is the PG version, but you can translate.)

Set up a long integer global and update the file when the machine is idle. Your program will continue to operate quickly.

CASE _otherNullEvent
gSaveTks& = 0

CASE _otherFilterEvent
INC(gSaveTks&)
LONG IF gSaveTks& = 10000
  gSaveTks& = 0
  CALL UPDATERESFILE(gResRef)
END IF

Alternatively, you can create your own STR# handles and use a single call to FN pGreplaceRes instead of making 200 calls to the STR# append function.

Also, you _may_ have a memory leak, but the question that you posted here is unrelated. This is just something that requires a few years of hanging with the Resource Manager.

STAZ ~)~


Maybe you could also check the resource flags first.

flags%=fn GETRESATTRS(myResH&)
if (flags% and _resChanged%)=0 then CALL CHANGEDRESOURCE(myResH&)

I haven't tried this; it's just a guess.

wave