Subject:Crash when accessing ISfFileHost.Markers

Posted by: Alastair MacGregor

Date:12/28/2006 6:22:52 AM

Hi,

I'm trying to create a script that presents a UI that allows a user to manage markers in a wave file. If I attempt to access app.CurrentFile.Markers in a function called directly from EntryPoint.Begin() everything works Ok, however if I create a window in Begin() (using form.Show(), not ShowDialog() that would block execution until the dialog has closed) and at some point in the future try to access the same collection (for example after a button Click event on my window) I get a null reference exception within get_Markers(). If I instead call app.CurrentFile.NewMarker() it works as expected.

Does anyone have any suggestions about what I might be doing wrong?

Thanks,
Alastair

Subject:RE: Crash when accessing ISfFileHost.Markers

Reply by: _TJ

Date:12/28/2006 11:47:36 AM

I gather from your description that your entry point is showing a window, then exiting.

Then the window is manipulating markers and crashing.

correct?

Subject:RE: Crash when accessing ISfFileHost.Markers

Reply by: Alastair MacGregor

Date:12/29/2006 8:47:26 AM

Yes that's correct. If I use Show() rather than ShowDialog() so as to not block the SF UI but still block within EntryPoint until my window is closed will that work Ok?

Thanks,
Alastair

Subject:RE: Crash when accessing ISfFileHost.Markers

Reply by: Alastair MacGregor

Date:12/30/2006 2:41:03 AM

To answer my own question - blocking inside entry point doesnt work. Sound Forge must be running the scripts in the same thread, so a blocked EntryPoint hangs SF.

If I grab a copy of the Markers collection in EntryPoint and keep a reference directly to it I can access it later from my window event code without the crash (until I delete a marker but I've not investigated that problem yet). This leads me to believe that there is a bug in the Markers property get{} code and its relying on some object which is getting set to null after the script entrypoint runs.

Any suggestions?

Thanks,
Alastair

Subject:RE: Crash when accessing ISfFileHost.Markers

Reply by: _TJ

Date:1/2/2007 2:26:53 PM

Yes that's correct. If I use Show() rather than ShowDialog() so as to not block the SF UI but still block within EntryPoint until my window is closed will that work Ok?

Well, without seeing your script code, I can't say it will work. But I can say that is has no chance of working if you don't. If your script exits, but leaves a window open, then whatever you do after your script exits is unsupported. It should work OK as long as your script doesn't touch any Sound Forge object after it exits. But if you start touching Sound Forge objects, all bets are off.

You are in totally uncharted territory, When your script exits. We clean up. As far as Sound Forge is concerned. The script isn't running anymore. It's not allowed to interact with Sound Forge objects anymore. If it does interact, it is ENTIRELY the resposibility of the script to make sure that all of the right bits get kicked in the right order, and that the user is prevented from interfering with the order of operations.

And we can't help you. This configuration is unsupported, it is, in fact unsupportable. Once you leave your FromSoundForge() method, your script is done. A flag is set inside Sound Forge that tells it that there is no script running, and certain bits of Sound Forge change their behavior based on that flag.

It's simply not possible to make Sound Forge stable if we allow scripts to stick their fingers into the middle of operations that they didn't initiate. Scripts need to be the ONLY thing controlling operations, or they need to step aside and do nothing.

So if want to manipulate markers, you need to not exit your script.
You don't have to use ShowWindow(). You can also use Show(), followed by a DoEvents() loop to pump messages and keep your script from exiting.

If you can describe what you are trying to do in more detail. Or if you can share the code for your script. I can possibly give you some ideas about how to do what you want to do without getting into unsupported configurations.

tj

Subject:RE: Crash when accessing ISfFileHost.Markers

Reply by: Alastair MacGregor

Date:1/15/2007 2:26:49 AM

Hi,

What I need to do is present a simple UI that allows a user to drop markers, from a predefined list of marker names, into the file that they are currently editing. Additionally I need to know when the play cursor crosses one of these markers.

If I block inside FromSoundForge() but call DoEvents() will the user still be able to interact with SoundForge as normal while my script is running?

If you could suggest any way supported in which this could be done I'd be very grateful.

Thanks,
Alastair

Subject:RE: Crash when accessing ISfFileHost.Markers

Reply by: _TJ

Date:1/15/2007 2:15:34 PM

If I block inside FromSoundForge() but call DoEvents() will the user still be able to interact with SoundForge as normal while my script is running?

No. Or rather, it depends. The design of Scripting in Sound Forge is that scripts are modal operations. While a script is running, the user is prevented from interacting with Sound Forge, (s)he can only interact with the script. So the official answer is NO. You can't write a script that adds a window that the user can interact with but doesn't block the user from interacting with the rest of Sound Forge. This is unsupported, and as I said before unsupportable. We know for certain that some things WILL fail if you try to do this. (i.e. you can't try a run another script). We suspect that a lot more things will fail, because they were never made robust enough to tolerate getting invoked by the user and by script simultaneously.

The unofficial answer is maybe. Because we assume that the user can't interact with Sound Forge because the script is either showing a modal dialog, or it is not listening to user input. But we don't enforce that assumption, it's up to the script to enforce it. But if the script is NOT showing a modal dialog, and it IS running a pump listening for user inputs, Then the user will not be prevented from interacting with Sound Forge.

We expect that properly written scripts will prevent the user from getting into situations that will corrupt data or crash Sound Forge. The normal way to do this is to make your script do it's business and then exit, or to accept user input only through modal dialogs. But we don't have any way to gurantee that scripts do this, it's on you, the script writer. You can to in script what ever you can pull off.

But as soon as you get into unsupported territory, I can't help anymore. If you hit a situation that's crashing, try something else. It's on you to make it work. Basically you have to trick Sound Forge into doing something it's not designed to do.

I would suggest that you will have better luck with markers and marker lists if you treat them as bogus objects whenever there is a chance that the user may have made a change since you last got the object. Don't try and hold onto them, let go and re-fetch from the filehost each time you need to modify them.

Marker lists that you make from scratch, (e.g new SfAudioMarkerList) you can hold and use however you see fit, since they aren't attached to any filehost. But anytime you have a marker or list that's attached to a filehost (i.e. you got it from Sound Forge, rather than from new), you need to let go of that list as soon as your are done using it, BEFORE you give control back to the user.

So, There is no supported way to do what you are trying to do. However, there may be a supported way to actually achieve your goal. It depends on whether you actually need to show UI or not. Would a set of key bindings, one for marker name be sufficient? Why do you need to know when playback crosses a marker? what are you doing with that information?


tj