Re: [Audacity-devel] wxWindows HashMaps, iterator storage and BlockFile storage

[<xip...@xi...>]

On Fri, Jul 30, 2004 at 07:18:10PM -0700, Dominic Mazzoni wrote:
> On Jul 30, 2004, at 1:47 PM, Monty wrote:
> >
> >Oh, third possibility: Abandon the idea of a centralized project
> >checker, and just modify the BlockFile subclasses to silently choose a
> >course of action when they notice A Problem; generally, there's only
> >one worthwhile response to a given situation anyway.  The DirManager
> >already has enough smarts to deal with orphaned blockfiles.
> >
> >Given the structural hassles, I think I vote for this one.
> 
> I was going to suggest this solution, too.
> 
> When a PCMAliasBlockFile gets asked for its summary data and the file
> isn't there, it should just silently generate it again, and so on.

That works.  The problem is the case where the PCMAliasBlockfile has
had it's aliased file yanked out from under, or a SimpleBlockFile has
lost is .au.  In this case, I can extend the classes to internally
implement the equivalent of a SilenceBlockFile, but then there's no
reason to have the SilentBlockFile.  There's currently no way to just
replace the damaged blockfile with a SilentBlockFile.

> A SimpleBlockFile shouldn't be replaced with a SilentBlockFile, because
> maybe the user accidentally moved the file, and then they could move it 
> back
> a minute later once they realize what they did.  So when it can't find 
> its
> .au file, it should just return silence.

That is why I'm popping dialogs that are explicit about what's going
on before making changes.  The user would have the option right then
and there to put the files back if they can.

Of coursem just returning silence is easy.  My concern is that the
condition is an error... and the condition will persist.  Should it be
reported every time the project is loaded?  Should we be sticking
'this is already reported' data in the XML save file to prevent that? 

> It would be nice in cases like this to display all of the error 
> messages in
> some modeless log window, since when there's one error there are likely 
> to
> be hundreds.  Perhaps the wxLog / wxLogWindow classes will work?

The original idea was to find all the problems all at once and report
them via a single summary, rather than the current behavior of
hundreds of modal dialogs.

Hm, I could still do that I suppose.  Of course, next time the project
loads, still damaged, the process will have to be repeated, files will
still be missing data, etc...  I want to fix the damaged projects, not
just tighten up the error reporting.

Monty