Flare taking image from .props file?

[Paul Griffiths]

What seems to happening is this:

When I open the image from Content Explorer, Flare is showing the correct, up-to-date PNG file, but in the XML Editor and at build time it's substituting the original (now long superseded) bitmap from the props file.

Anyone else seen this? I'm thinking of hacking the .props file to remove it.

[Nita Beck]

Paul, the .props has embedded in it the original image as the background image. You need to REPLACE the background image.

To get ready to do this, I think that first you'll need to make a copy of your new image and put it somewhere outside the Flare project.

Next, from within Flare, edit your new image in Capture. When Capture opens, use the REPLACE command and when prompted for the image to replace the embedded background image, select the copy of the image that you placed outside of Flare. Then save the image, close Capture, and you're done.

You (or others) might wonder why you first had to make the copy of the image. Honestly, I dunno. It's just that when I've attempted to replace the background image with the image that's within Flare, Capture doesn't like it.

[Paul Griffiths]

Thanks NIta, I'll try this. Odd I haven't seen this behaviour before now!

[SteveS]

As Nita said.

The props file contains the original image and the changes you make, similar to a photoshop file. That's why you can open the image at a later date and go back to the original and make a new output image. It also contains the capture information to make it easier to recreate the screenshot using a changed interface, although I haven't used that capability myself.

[ChoccieMuffin]

I don't user Capture, but I still get lots of .props files, which I thought just contained conditions. Can I assume that you only get this original image thing when you took the original with Capture?

[Nita Beck]

I don't user Capture, but I still get lots of .props files, which I thought just contained conditions. Can I assume that you only get this original image thing when you took the original with Capture?

No, your assumption isn't correct. I regularly take screencaps with SnagIt (just out of old habit) and then add callouts and objects using Capture. Capture embeds the image in the props file as the background image. Later, in order to replace that background image, I use Capture's Replace command.

If I took the original screencap with Capture, then I could use Capture's Recapture command to replace the background image with a new image.

[Paulie]

Sorry Nita, but I think ChoccieMuffin's assumption is right in this instance... If you do not use Capture at all, but place a condition or file tag property on a non-XML file (PDF, image etc.) then a props file will be created to contain that information.

The structure of this props file is different from the one created if you use Capture to edit the image, and does not contain the <ImageOverlay> element where the original image is encoded as a Base64 string. I assume that if you later use Capture to edit the image that the existing .png.props file will be merged with the one that is created when the Capture image is saved.

[Nita Beck]

Sorry Nita, but I think ChoccieMuffin's assumption is right in this instance... If you do not use Capture at all, but place a condition or file tag property on a non-XML file (PDF, image etc.) then a props file will be created to contain that information.

You are correct and Choccie is correct that placing a condition on a non-XML file will indeed create a props file. But that's not what Choccie said he was assuming and what I was correcting him about. I should have cut out the bit about conditions when I quoted him. I was reacting to his wondering "Can I assume that you get this original image thing when you took the original with Capture." His assumption is not correct. If one takes an image captured with some other tool and then opens it in Capture and does stuff like add callouts, arrows, and so forth, that original image is embedded in the props file. If one later wants to update the image, one will need to replace the background image in Capture. And maybe even all one would have to do is place a condition on it, too, to embed the background image.

My point is that one will need to replace the background image regardless of the tool used to capture the original image.

[ChoccieMuffin]

Update: We've just discovered that this is happening here, but it's ONLY when using Madbuild and not when building output using the regular Flare GUI. I have added a bug (Case 87558), and in the meantime I have searched through the 1200+ .props files scattered through all our projects.

For some files we've happily just deleted the .props file (because we don't use Capture but one of our predecessors did) but clearly we can't just delete them all because conditions are also stored in .props files.

So we have done a search in all of those for files that contain <OriginalImage> and now have 218 to play with - an improvement over nearly 1300 but still a pain in the behind. For the .props files to go with images that don't have any conditions, we are just going to delete the .props files. CAN ANYONE SEE A DOWNSIDE TO THAT APPROACH?

For files that contain the OriginalImage tag AND conditions, we're going to delete the info about the original image. As before, CAN ANYONE SEE A DOWNSIDE TO THAT APPROACH?

Clearly we don't want to do shed-loads more work than we have to, so your advice is very welcome.

p.s. It's only because I read the forums most days that I remembered seeing something about .props files causing this problem, so thanks to everyone who contributed, you definitely saved several days of effort that we didn't have to spend digging around in the mud and getting nowhere!