Re: [Audacity-devel] more bugzilla review
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Dominic M. <do...@au...> - 2004-01-05 10:36:21
|
Vaughan Johnson wrote: > Okay. I put a hack in Importer::Import() to do this, but should it > instead be an importPluginNode that returns 0? Also, if this extra > verbiage is a translation burden, we can back this out to the > development version. My vote would be to go with the hack. Stable releases should be ugly and they should work. We should solve the problem the "right" way in the CVS HEAD. As for the translation, please mark the string as translatable so that the translation can be added in time for the 1.2.1 release. >>> * bug 110 (Doesn't ask if you save changes if you close while recording: >>> >>> Open a new Audacity project and click "Record". Then close the >>> window or Quit, >>> and Audacity closes the window without asking if you want to save >>> changes, so >>> you could lose everything you've recorded. >>> >> ... >> The fundamental problem is that the Project never pushes state, >> realizing that it's been modified, until it checks to see if recording >> has _finished_ during an idle event. >> >> Three ideas for solutions: >> >> * Is it enough to mark a project as Dirty (mDirty = true) when you >> start recording? > > No, that didn't do it. >> >> * Could a project PushState when you start recording, and then >> ModifyState when you finish? > > I hacked in a PushState (but not the ModifyState), and that makes it ask > whether to save when you click the close box, but it keeps recording! If > you save, it does it successfully, up to some completed chunk, and > closes. I was surprised it didn't crash, but as you said, Dominic, we > need to stop recording before exiting, and presumably before asking > whether to save. > > On these first 2 ideas, because mDirty and PushState are private, I just > hacked AudacityProject::SetAudioIOToken(). That's the wrong place to do > it, but for testing worked because the only place I could easily tell > where recording starts is in ControlToolBar::OnRecord(), and it calls > SetAudioIOToken on first successful loop. Is there a better place to > catch that, or will ControlToolBar need state-modifying callbacks a la > TrackPanel (to maintain the privacy restriction)? It doesn't look like > AudacityProject::OnRecord() is called anywhere. Again, ugly but simple is the key. Ugly, simple, and well-documented. AudacityProject::OnRecord is called when you press the 'R' key. See Menus.cpp and the CommandManager class for details. But since the implementation just calls the control toolbar, you could just patch ControlToolBar::OnRecord and/or SetAudioIOToken; I don't see a problem with that. To be safe, be sure to test it using the 'R' key, though... >> * Do an explicit check to see if you're in the middle of recording in >> the AudacityProject destructor, and if so, push state, duplicating a >> bit of code shown above. > > I didn't try this one, but does the above give you an indication whether > this is necessary? I didn't yet look into making it stop recording > before presenting the save dialog. Are both necessary? Hmmmm, I guess I'm starting to think that it may be necessary to stop recording before saving. Even though it worked for you once, it sounds like a potential race condition to me. It may be necessary to put up a stopwatch (wxBusyCursor), stop, wait until the token is returned (which means that the recording has _really_ finished), and then go on to save, exit, etc. Note that if you do this, you won't need to add another PushState anywhere, since this will already be done when AudioIO _completely_ finishes and zeros out the token. Yet another idea: modify the CloseWindow and Exit handlers to Veto the request if you're recording, popping up a wxMessageBox that says you must stop first. Not ideal, but if everything else gets too complicated, this would be a better solution than doing nothing. - Dominic |