"Francois Labreque" <fla### [at] videotronca> wrote in message
news:40512aef$1@news.povray.org...
> >
> > What would you prefer it do in the case where the file exists, but is
(a) corrupt, (b) of the wrong format (e.g. bit-depth), or (c)
> > of the wrong resolution.
>
> You could warn the user and offer and interactive choice to:
> (a) start from scratch, overwriting the file.
> (b) start from scratch, renaming the previous file.
> (c) continue using the original file's resolution and color depth.
> (d) abort the render.
>
> Or maybe, if and interactive choice is not a good idea, have these
behaviours be
> part of an .ini setting.

Ahem. Please excuse me if I am making this seem trivial. Maybe there should
only be a warning telling of the incompatible file so the user can check
into that themselves.

This error was about a default system output file not being continuable, so
with that fixed (whether about the file itself or only the switch +F) I'd
think it simpler to just warn with a text message that there is a fault with
the file intended for usage. Most any typical circumstance would be that a
partial (and correct) image file is awaiting continuance and be written to.
Specifying a different output type would obviously be a mistake.

Now, I'll take back what I say here if Francois' suggestion were to be
invoked for every file type, because that means a person might be trying to
juggle image files around and would need the extra presentation of options
before allowing the +C switch to have control automatically. Guess that was
the idea about additional INI settings, to intervene in various ways. If you
can see it my way a moment, what I'm trying to convey here is that a popup
dialog asking to make a few choices either needs plenty of info passed to
the user (more than just "there's a problem"), or can cause the user to need
to go check on the file anyhow while that dialog sits awaiting a response.

Hopefully I'm making some sense. For me, a continued trace is always just
that, continued and not changed. On the other hand, I'd hate to see a
potentially usable file overwritten from the start by mistake too. But this
depends on how much failsafe you think ought to be built in to guard against
that happening, regardless of how one might get named and placed the same as
what would be done during the next render.

Bob H.

Post a reply to this message