File lost when switching

[Unsub Press]

I don't hold out much hope, but here goes.

I've been doing some work in Designer. I'm making scientific diagrams for my blog. I'd done some work but I needed to use the warp tool. I've had the new version of Photo in my d/l folder since release, but haven't needed to use it, so I hadn't gotten around to updating it. However, I use Designer a lot, so that was updated as soon as I got the new version message. I needed a couple of minutes with mesh warp, so I clicked 'edit in photo' only to be met with an error message to the effect ''unable to open file; this was created in a newer version of affinity'. The file was not opened, but Designer closed it on the transfer, so now it's gone. 

So my question, is there a metafile somewhere that I can recover?

Yes, yes, I'm an idiot. I should have saved. It's not like I'm a noob, I was just in a hurry and my experience of Affinity has been much better than I'm used to, so I naïvely clicked through without thinking (which is not to say that this is the fault of anybody or anything other than me and my haste-borne stupidity).

I'm going to start again, but there's a lot of work, so I'm hoping a little advice can save me a considerable amount of work duplication.

Edited May 3, 2021 by Unsub Press
Clarity

[Callum]

Hi Unsub Press,

Welcome to the forums

Unfortunately this appears to be an oversight with no fallback in place unfortunately your file has been lost. I will log an improvement for some sort of auto save during this process.

Thanks

C

[Unsub Press]

Thank you, Callum. I appreciate that. 

In the event, I started again. At least having done it once meant that the workflow was fresh, so I got back to where I'd been in about a quarter of the time and learned some useful lessons on the way.

[IanSG]

You don't need @Unsub Press' unfortunate chain of events - if you exit AP without saving the file's gone!   It's the same for the entire suite - start in AP, edit in in AD or Apub, exit without saving and the work's lost.

[Unsub Press]

Indeed. The issue in this case was that AP never opened the file, so there was no option to switch back. Neither application had a recovery file to refer to, because AD had dropped it and AP had never opened it.

It's very much a user issue, and my own fault for not updating both at the same time. Sometimes, though, workflow supersedes such considerations, and it would be good if each application could hang onto its recovery file until the transfer back is complete to avoid it.

[carl123]

30 minutes ago, Unsub Press said:

and it would be good if each application could hang onto its recovery file until the transfer back is complete to avoid it.

Not every handoff requires a transfer back. Sometimes you finish your work once handing it off to the other application.

 

What's needed is a way for the apps to say...

"I've got it now so you can let go of it" 

not

"I've let it go, did you get it?" 

"Err, No!"

[IanSG]

1 hour ago, LondonSquirrel said:

That is incorrect. Quite a number of times, despite quitting APhoto, and NOT saving, on restarting APhoto I see the dialog below. I am not sure what causes it, but sure enough if I click 'Restore' back comes the unsaved file. Even if I have never saved the file in any way at all...

I've seen that too, but it doesn't seem to be repeatable, and never in this situation, where an image is being edited in different programs.   

[R C-R]

6 hours ago, Callum said:

Unfortunately this appears to be an oversight with no fallback in place unfortunately your file has been lost. I will log an improvement for some sort of auto save during this process.

For that particular issue (the Affinity app being switched to not yet being updated to a compatible version) I think the best solution would be for the current app to check for a compatible version of the other app(s) & if there is not one, greying out the appropriate 'Edit in...' option on the file menu.

[walt.farrell]

1 hour ago, R C-R said:

For that particular issue (the Affinity app being switched to not yet being updated to a compatible version) I think the best solution would be for the current app to check for a compatible version of the other app(s) & if there is not one, greying out the appropriate 'Edit in...' option on the file menu.

I agree. This is also similar to what happens in Publisher with StudioLink, and with the beta applications checking that you have a beta version of the other application(s) installed.

[Unsub Press]

2 hours ago, R C-R said:

For that particular issue (the Affinity app being switched to not yet being updated to a compatible version) I think the best solution would be for the current app to check for a compatible version of the other app(s) & if there is not one, greying out the appropriate 'Edit in...' option on the file menu.

There you go. Perfect solution, a couple of lines of code.

That's why they pay you the big bucks.

[R C-R]

20 minutes ago, LondonSquirrel said:

In my view, that can be improved a lot. It should instead show something like 'no compatible application available'.

As it is, by convention a greyed out menu item always means that menu item is unavailable. If instead each such item changed to something more verbose, we would see things like File > Save change to File > No document to save or File > Document already saved.

I do not think that would be an improvement.

[R C-R]

2 minutes ago, LondonSquirrel said:

There is nothing wrong with changing uninformative conventions.

The greyed out menu item convention is informative enough to have withstood the test of time.

Besides, even if it showed something like "no compatible application available" that won't prevent people from asking what "compatible application" means or what apps would be compatible.

[walt.farrell]

Perhaps it could be grayed out, and have a tooltip for the message explaining why.

But you're right that nothing will eliminate all the questions, @R C-R.

[R C-R]

3 hours ago, walt.farrell said:

Perhaps it could be grayed out, and have a tooltip for the message explaining why.

I don't think menu items in Mac apps can have tool tips. At least I have never seen one that does.

[v_kyr]

5 hours ago, R C-R said:

I don't think menu items in Mac apps can have tool tips. At least I have never seen one that does.

 

• A help tag for the menu item - (Apple Dev tooltip)
• Class NSMenuItem - (Apple Dev)

[R C-R]

6 hours ago, v_kyr said:

 

• A help tag for the menu item - (Apple Dev tooltip)
• Class NSMenuItem - (Apple Dev)

I stand corrected. But I have never seen a Mac app that actually used that capability. Do you know of any that do?

[walt.farrell]

10 minutes ago, LondonSquirrel said:

It does not impart any information at all. It is the absence of information.

It imparts at least two pieces of information:

1. You have found the function you were looking for; and
2. For whatever reason, you cannot use it.

Both are useful, though number 2 could explain further why you can't.

[R C-R]

4 minutes ago, LondonSquirrel said:

Can you explain how this greyed out menu item is useful? Show all what?

Show All shows all open apps. It is a complement to Hide & Hide Others, which is why it is grouped with them.

It is a fundamental macOS level window management function. Those 3 menu items appear on the app name menu in Mac apps, but they are not specifically a part of any app.

When it is greyed out it tells you that there are no other apps open & hidden.

[R C-R]

11 minutes ago, LondonSquirrel said:

I have eight apps open... Your information 'there are no other apps open' is clearly wrong.

Are any of them hidden? For example, if you choose "Hide Google Chrome" & then switch to any other app (including Finder) is "Show All" still greyed out?

[Unsub Press]

An interesting discussion. 

While, for me, the greyed-out menu item is a perfect solution, that's predicated on some assumptions that, while true for me, may not be for everybody. It's a perfect solution because it prevents an inadvertent loss of work and interruption of workflow.

I agree that it raises some questions, but they're questions I'd generally expect anybody competent to overcome the initial learning curve to use any of these apps to trivially overcome. Where it represents a deviation from expected behaviour, which is what it would almost need to be in order for it to be a problem, the question then becomes 'why is this normally-available function unavailable', which is pretty trivial to answer. In this instance, my first thought would have been to save my work and launch Photo, at which point I'd have received the message concerning the new version, remembered that It was sitting in my downloads folder, and updated, with no loss of work or significant interruption of workflow.