07-08-2025, 11:15 PM
_LoadImage loads an image in memory, and it returns a handle so you can access that image.
_NewImage basically does the same, except it creates a blank image in memory at the size and color depth you specify.
All the handle is, is the pointer to that memory.
Umm... Let's see the easiest way to explain it, so everyone can follow along with the concept:
F = FREEFILE <-- this would get you a file handle for you to access a file on your drive. Right?
OPEN "temp.txt" FOR OUTPUT AS #f <--- and this would open that file usin that file handle
F = FREEFILE <-- this will now give you another file handle so you won't run into issues when trying to access the next file you need.
OPEN "foo.txt" FOR INPUT AS #F
Only thing is.... You now have the first file which you opened for OUTPUT *still* open for OUTPUT. You also now have a file open for INPUT... The issue here is now:
How would you close that first file that you opened for OUTPUT?? F doesn't point to it anymore. If you issue a CLOSE F, it's not going to close the file opened for OUTPUT; it's just going to close the file which was opened last for input and assigned to that variable...
With the above, you have written yourself into a memory leak with an always opened file that you just can't close easily. (Not without issuing a CLOSE statement by itself and closing *every* file you have opened for any access!)
It's the same type thing with all the _LOAD or _NEW type commands.
foo = _LOADIMAGE is very similar to F = FREEFILE, in the fact that it just gives you the *handle* pointing to the proper place in memory/disk to work from. If you overwrite that variable, you're going to end up making it impossible to FREE that resource later once you're done with it.
Fonts, Images, Sounds, Mem, File access.... Doesn't matter. They *ALL* follow this same style of rule set. If you _LOAD them or create them, you need a corresponding _FREE for them. If you reuse the same variable without freeing them first, you have a memory leak that will eventually come back and bite you in the arse.
I really think that everyone needs to get in this habit when it comes to resource management:
If handle <> 0 THEN _FREEwhatever handle
handle = _LOADwhatever("blah blah.bllah")
Check to see if the handle is in use (a non-zero value), and if so, then free it. If you haven't used that handle, you're fine and life is golden (except in subs or something which erases variable values after exit -- code smartly around them with passed or global handles). If the handle is in use, free it before you overwrite it.
Just be certain to have that IF check suitable for your type. (I think valid images are all less than -1, with -1 being an error message, so a check for 0 there might not be what you want and could lead to issues. I'm just spitballing on that though, and without checking the wiki, don't trust that 100%. I reserve the right to get confuzzled as much as anyone, and to not always keep up with every change/fix/update.
)
If you start adding those type checks in your code, it'll save you a lot of possible issues and memory leaks in the future. Just be certain to zero out that handle if you ever manually free the image yourself, so it won't try to free something which has already been freed.
_FREEIMAGE handle: handle = 0 ' <<--- Just something as simple as this, and then if it goes back to that IF check above later, it won't try to free what's already been freed.
_NewImage basically does the same, except it creates a blank image in memory at the size and color depth you specify.
All the handle is, is the pointer to that memory.
Umm... Let's see the easiest way to explain it, so everyone can follow along with the concept:
F = FREEFILE <-- this would get you a file handle for you to access a file on your drive. Right?
OPEN "temp.txt" FOR OUTPUT AS #f <--- and this would open that file usin that file handle
F = FREEFILE <-- this will now give you another file handle so you won't run into issues when trying to access the next file you need.
OPEN "foo.txt" FOR INPUT AS #F
Only thing is.... You now have the first file which you opened for OUTPUT *still* open for OUTPUT. You also now have a file open for INPUT... The issue here is now:
How would you close that first file that you opened for OUTPUT?? F doesn't point to it anymore. If you issue a CLOSE F, it's not going to close the file opened for OUTPUT; it's just going to close the file which was opened last for input and assigned to that variable...
With the above, you have written yourself into a memory leak with an always opened file that you just can't close easily. (Not without issuing a CLOSE statement by itself and closing *every* file you have opened for any access!)
It's the same type thing with all the _LOAD or _NEW type commands.
foo = _LOADIMAGE is very similar to F = FREEFILE, in the fact that it just gives you the *handle* pointing to the proper place in memory/disk to work from. If you overwrite that variable, you're going to end up making it impossible to FREE that resource later once you're done with it.
Fonts, Images, Sounds, Mem, File access.... Doesn't matter. They *ALL* follow this same style of rule set. If you _LOAD them or create them, you need a corresponding _FREE for them. If you reuse the same variable without freeing them first, you have a memory leak that will eventually come back and bite you in the arse.
I really think that everyone needs to get in this habit when it comes to resource management:
If handle <> 0 THEN _FREEwhatever handle
handle = _LOADwhatever("blah blah.bllah")
Check to see if the handle is in use (a non-zero value), and if so, then free it. If you haven't used that handle, you're fine and life is golden (except in subs or something which erases variable values after exit -- code smartly around them with passed or global handles). If the handle is in use, free it before you overwrite it.
Just be certain to have that IF check suitable for your type. (I think valid images are all less than -1, with -1 being an error message, so a check for 0 there might not be what you want and could lead to issues. I'm just spitballing on that though, and without checking the wiki, don't trust that 100%. I reserve the right to get confuzzled as much as anyone, and to not always keep up with every change/fix/update.
)If you start adding those type checks in your code, it'll save you a lot of possible issues and memory leaks in the future. Just be certain to zero out that handle if you ever manually free the image yourself, so it won't try to free something which has already been freed.
_FREEIMAGE handle: handle = 0 ' <<--- Just something as simple as this, and then if it goes back to that IF check above later, it won't try to free what's already been freed.