Image from System.DocumentsDirectory not updating

[davidgmonical]

So I’m implementing a feature where a user can select photos from their photo library and put them into 3 slots.

What I’m doing now is having the selected image stored in the system.DocumentsDirectory under “selectedImage(1/2/3).png” based on the slot.

When the user reselects the same slot, the image is overrided with the new one (ie. user selects image for slot 1 -> image stored at “selectedImage1.png”, user selects another image for slot 1 -> new image stored at “selectedImage1.png”).

This seems to work fine, as when I check the Documents Directory, the new image is stored under the correct name, and the old image is not there. However, I then proceed to do a display.newImage of “selectedImage(1/2/3).png”, and the old one appears, not the new one.

Any idea why this may be happening?

Thanks

[roaminggamer]

Your post is a WOT and hard to read. Please use paragraphs separated by blank lines.

Are you saying, you write to the same filename over and over and you can’t display the modified texture? i.e. It shows the same texture no matter what you do. If so, it sounds like the old texture is still in texture memory.

Solution, flush it out: https://docs.coronalabs.com/guide/graphics/textureManagement.html

Failing that, consider making super-tiny demo project showing the problem and then attach it here so we can experiment directly.

[roaminggamer]

By the way, The best way around this is to simply not do it that way.   Trying to re-use the same files over an over is bound to run into problems: file-locked, texture not removed from memory, …

Use a unique name for each texture and delete the old ones.

SSK2comes with an extensive files helper that make deletion of files easy: https://roaminggamer.github.io/RGDocs/pages/SSK2/libraries/files/#utilities-sskfilesutil

local path = ssk.files.documents.getPath( "filename.jpg" ) ssk.files.util.rmFile( path )

[davidgmonical]

Sorry about the formatting. Hope it’s better now.

I guess I’ll come up with a work-around then, and only use new file names.

Thanks.

[roaminggamer]

**CODE MAY CONTAIN TYPOS**

Well manually loading and flushing shouldn’t be too hard.  You can probably make a wrapper to do all the work automatically.

Assuming you always delete the display object that uses the texture BEFORE you copy a new image to the file, then displaying new images from the library should go like this for a file named filename1.jpg.

1. Delete display object using texture  filename1.jpg.  (Be sure to clear all references to object so it can be garbage collected.)

2.  Copy photo library image to  filename1.jpg.

3. Show the image as follows (using simply module as example of way to package this):

   local textures = {} local mod = {} function mod.showImage( group, x, y, width, height, num ) local old = textures[num] – textures[num] = nil – if( old ) then old:releaseSelf() old = nil end – local texture = graphics.newTexture( { type=“image”, filename=“filename” … num … “.jpg” } ) textures[num] = texture – local img = display.newRect( group, x, y, width, height ) img.fill = { type = “image”, filename = texture.filename} – return img end return mod

Now later in your code:

local mod = require "mod" local myImg = mod.showImage( display.currentStage, 100, 100, 100, 100, 1 )

[davidgmonical]

It seems as if deleting the display object containing the texture BEFORE copying the new image to the file did the trick.

Am I missing something by not using the module you provided or do you think this is a safe fix?

Also, thank you so much for the help

[roaminggamer]

If you were not previously deleting the display object that used the texture BEFORE writing to the file, it was probably locked.

You don’t need to use my code if you have a simpler solution that works consistently.

[roaminggamer]

Your post is a WOT and hard to read. Please use paragraphs separated by blank lines.

Are you saying, you write to the same filename over and over and you can’t display the modified texture? i.e. It shows the same texture no matter what you do. If so, it sounds like the old texture is still in texture memory.

Solution, flush it out: https://docs.coronalabs.com/guide/graphics/textureManagement.html

Failing that, consider making super-tiny demo project showing the problem and then attach it here so we can experiment directly.

[roaminggamer]

By the way, The best way around this is to simply not do it that way.   Trying to re-use the same files over an over is bound to run into problems: file-locked, texture not removed from memory, …

Use a unique name for each texture and delete the old ones.

SSK2comes with an extensive files helper that make deletion of files easy: https://roaminggamer.github.io/RGDocs/pages/SSK2/libraries/files/#utilities-sskfilesutil

local path = ssk.files.documents.getPath( "filename.jpg" ) ssk.files.util.rmFile( path )

[davidgmonical]

Sorry about the formatting. Hope it’s better now.

I guess I’ll come up with a work-around then, and only use new file names.

Thanks.

[roaminggamer]

**CODE MAY CONTAIN TYPOS**

Well manually loading and flushing shouldn’t be too hard.  You can probably make a wrapper to do all the work automatically.

Assuming you always delete the display object that uses the texture BEFORE you copy a new image to the file, then displaying new images from the library should go like this for a file named filename1.jpg.

1. Delete display object using texture  filename1.jpg.  (Be sure to clear all references to object so it can be garbage collected.)

2.  Copy photo library image to  filename1.jpg.

3. Show the image as follows (using simply module as example of way to package this):

   local textures = {} local mod = {} function mod.showImage( group, x, y, width, height, num ) local old = textures[num] – textures[num] = nil – if( old ) then old:releaseSelf() old = nil end – local texture = graphics.newTexture( { type=“image”, filename=“filename” … num … “.jpg” } ) textures[num] = texture – local img = display.newRect( group, x, y, width, height ) img.fill = { type = “image”, filename = texture.filename} – return img end return mod

Now later in your code:

local mod = require "mod" local myImg = mod.showImage( display.currentStage, 100, 100, 100, 100, 1 )

[davidgmonical]

It seems as if deleting the display object containing the texture BEFORE copying the new image to the file did the trick.

Am I missing something by not using the module you provided or do you think this is a safe fix?

Also, thank you so much for the help

[roaminggamer]

If you were not previously deleting the display object that used the texture BEFORE writing to the file, it was probably locked.

You don’t need to use my code if you have a simpler solution that works consistently.