Designer 2.53: Freeze on start-up if a recently accessed SVG file is deleted

[MC1]

Freeze on start-up happens in 2.53 and for as long as I remember in previous versions.

This will happen if the "recent file" window is accessed and if a recently accessed SVG is no longer at the original path, for example it has been deleted or moved.

Steps to reproduce:

1. Open SVG file in Affinity Deisgner 2
2. Close the file
3. Close designer
4. Delete or move the file to a different folder
5. Open designer
6. Open recent files window
7. App is now frozen

Workaround when frozen without losing all your file history:

1) Open task manager, find Affinity Designer under Processes, and end task.

2) In windows explorer navigate to Designer's setting files, your path will be similar to this, change the username:

C:\Users\YOURUSERNAME\AppData\Roaming\Affinity\Designer\2.0\Settings

3) Open RecentFiles.xml in a text editor

4) Delete relevant the MruPath entries for the files that no longer exist, for example your file will look like a longer version of this:
 

<?xml version="1.0" encoding="utf-8"?>
<Settings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="Serif.Affinity.Settings.MruSettings">
	<MruPaths>
		<MruPath>
			<Path>YOURFILENAME.afdesign</Path>
			<IsPinned>False</IsPinned>
			<Timestamp>09/08/2024 15:51:52 +00:00</Timestamp>
		</MruPath>
		<MruPath>
			<Path>YOURFILENAME.svg</Path>
			<IsPinned>False</IsPinned>
			<Timestamp>09/08/2024 15:50:21 +00:00</Timestamp>
		</MruPath>
		<MruPath>
			<Path>YOURFILENAME.eps</Path>
			<IsPinned>False</IsPinned>
			<Timestamp>09/08/2024 15:50:12 +00:00</Timestamp>
		</MruPath>
		<MruPath>
			<Path>YOURFILENAME.afdesign</Path>
			<IsPinned>False</IsPinned>
			<Timestamp>09/08/2024 15:49:46 +00:00</Timestamp>
		</MruPath>
		<MruPath>
			<Path>YOURFILENAME.eps</Path>
			<IsPinned>False</IsPinned>
			<Timestamp>09/08/2024 15:11:20 +00:00</Timestamp>
		</MruPath>
	</MruPaths>
</Settings>

A single entry is this:

		<MruPath>
			<Path>YOURFILENAME.svg</Path>
			<IsPinned>False</IsPinned>
			<Timestamp>09/08/2024 15:50:21 +00:00</Timestamp>
		</MruPath>

 

Edited August 10, 2024 by MC1

[Lee D]

@MC1 Thanks for your report.

It's not something I can replicate on my Windows system following your steps using some random SVG files that I have.

Once the app is frozen on your system, if you close and reopen and go to File > Open Recent > Clear this should allow you to continue to use the app without needing to edit the .xml files. Obviously the recents list is cleared but you can still open any of the files using File > Open.

[MC1]

Quote

Once the app is frozen on your system, if you close and reopen and go to File > Open Recent > Clear this should allow you to continue to use the app without needing to edit the .xml files. Obviously the recents list is cleared but you can still open any of the files using File > Open.

 

I can't do anything when I reopen the app, it is completely frozen unless the relevant SVG file entry is removed form RecentFiles.xml. All I can do is CTRL ALT DEL and end process.

This has been happening for as long as I remember. Only with SVG, regardless of the size or content of the SVG.

I am using Windows 11 23H2 and the .exe if that makes a difference.

[Hangman]

Hi @MC1,

I'm equally not seeing any crash in the Retail or Beta version...

Following your recipe, I see the following message... Are you seeing the issue with any or all SVG files or just particular SVG files? If the latter, could you upload a sample file so we can take a look?

[walt.farrell]

There's a Setting to automatically  re-open documents when starting the app. 

Do you have that enabled?

[Hangman]

3 minutes ago, walt.farrell said:

There's a Setting to automatically  re-open documents when starting the app. 

That would or should result in the same message rather than freezing the App...

[walt.farrell]

3 minutes ago, Hangman said:

That would or should result in the same message rather than freezing the App...

It certainly shouldn't freeze the app, but if the missing file was on a missing network or a network drive that's not responding it could. 

The message you showed is related to using the Recent list or File > Open Recent, which may operate differently, I think. But I agree getting the same message would be nice.

[Hangman]

36 minutes ago, walt.farrell said:

The message you showed is related to using the Recent list or File > Open Recent, which may operate differently, I think. But I agree getting the same message would be nice.

It was but having now tested File > New > Recent, the behaviour differs between Windows and Mac after the file in question is moved to another location, i.e.,

• On Windows, the file name still appears in both the File > Open Recent submenu and the File > New > Recent window where it shows the original file path...
• On Mac, the file name no longer appears in the File > Open Recent submenu or the File > New > Recent window so the file can't be physically opened using either method...

[MC1]

Hi everyone, thank you for your time looking in this.

Even following my own recipe, I cannot replicate this. I am debating my own sanity now as this has absolutely been happening in V2 for as long as I can remember. If I find I this has in fact been a thing and I am not loosing my marbles, I will save the file for sure and post it here.

On 8/14/2024 at 3:19 PM, walt.farrell said:

There's a Setting to automatically  re-open documents when starting the app. 

Do you have that enabled?

I know for sure I don't, or didn't, however, you mentioned network drive being an issue if the file was removed. This could apply to me. Would cloud sync services or similar features on a NAS cause this? Could a hibernating local drive also cause this?

On 8/14/2024 at 2:45 PM, Hangman said:

Hi @MC1,

I'm equally not seeing any crash in the Retail or Beta version...

Following your recipe, I see the following message... Are you seeing the issue with any or all SVG files or just particular SVG files? If the latter, could you upload a sample file so we can take a look?

Thank you for trying and sorry to waste your time.

[walt.farrell]

10 hours ago, MC1 said:

however, you mentioned network drive being an issue if the file was removed. This could apply to me. Would cloud sync services or similar features on a NAS cause this? Could a hibernating local drive also cause this?

Cloud: probably not, but it's conceivable if the Cloud service takes a long time to respond or to deliver the file if it has been migrated off of the local folder.

NAS: yes, but typically this happens only if the NAS has gone to sleep and doesn't want to wake up, but the OS still thinks it's there.

Hibernating local drive: if it doesn't wake up promptly, probably.