on the little problem emailed to you yesterday

The one I suggested deserved a red star, about replication.

I believe I understand what’s going on, after sleeping on the matter-- with the clue of having the trigger come up several times more, but avoiding problems with it.

What can happen is this:

  • due to internet speed, rushing with PC and iOS Scrivener on the same desk, etc., expecting sync will take only the usual few seconds, an alert comes up saying there’s a conflict, and giving two choices which I didn’t really understand properly, it turns out.

  • thinking the alert came from Dropbox, I just told it to proceed. Bad move, as this resulted in the problem email reported.

  • what you really want to do is realize the alert come from Scrivener, and is warning you that Dropbox hasn’t finished updating, thus there is a conflict until it does in the sync. Thus the proper response is to hit cancel, and then can ask again for Sync from the iOS Scrivener top-level interface that will reappear.

  • doing that way until I didn’t see the alert on opening the Project gave me no problems, from that point on.

What can you do about this, as it’s really a UI problem which may be worse for people who understand the tech?

I’d suggest that the message in the alert be revised to say just what to do. I.e.,

== default button: 'Your latest sync isn’t completed yet, due to internet delays, etc… Please click here to go back to the Projects screen, and Sync again until it is."
== Cancel button: 'If you cancel, you could go ahead immediately, but your Project will probably be corrupted, as it showing not all elements are synced."

Well. And if you read the true explanation for the Cancel button, I don’t think you want to say it.

A better solution seems to correct what the defaulted button says (please edit for friendliest flavor), and then eliminate the Cancel button entirely.

Now the situation is safe, as you’ve put so much effort into intending. If there’s a reason Cancel would ever be used (worst case testing, etc.) it could be reachable by a hidden and obscure key combination, or a file configuration.

No?

Best, :wink:,
Clive

Please notice that I reversed the function lof the two buttons, as they are at present, in this little excursion.

However, what I wrote I think is also correct, as,they should be,reversed – canceling is the proper way out, whether you spell it with two ls or not (personal history), and deserves to be the default, as then you go back to syncing, until all,comes,up clean. It’s those partial, because unfinished, syncs that hurt, and wonderful Scrivener notices, lets us recover…

If you agree the full plan, which eliminates the visible other button, the way I got into trouble, then Scrivener should be marvelously clean in syncing, as its,very intended intention.