Workshop crashes---whose fault, mine or TADS?

I’m experiencing frequent crashes of the Workbench. I write some code, run it in the debugger, quit the game window, go back into the debugger, and the Workbench crashes.

I also experience a non-response to keyboard input in the game window. I enter a command, the game window responds, displays a prompt for the next input, then ignores my input. I have to click the mouse in the window then enter text on the keyboard, at each prompt. Then after a while, the condition corrects itself for a few lines of input then it’s back to ignoring me.

Have I made some sort of subtle error in my code that triggers this (I don’t see anything obvious, even in the simplest of code source)? Or do I just have to learn to live with it?



That doesn’t sound normal.

What OS are you using?

You say, “…run it in the debugger, quit the game window, go back to the debugger…” Does that mean you’re quitting the game in the game window – or perhaps actually closing the game window? Because that could conceivably cause problems. On the other hand, if you just mean the game is still active in the game window and you have merely switched back to Workbench, it’s a different kettle of fish.

How are you using the debugger? Have you set breakpoints? Are you using the step into/step through keys?

All of the above.

I work in Windows 7 Ultimate.

I write some code, compile for debugging (sometimes clean then compile all, sometimes just compile), then choose Go from the Debug menu.

The game comes up in the game window, I do some stuff, then I have tried both…

a) just go back to WorkBench. Sometimes that’s all it takes, the Workbench is inactive, I get a popup that says workbench is working, then after a while the popup says workbench as quit.

b) Quit the game (q, then y, for yes I’m sure) in the game window and then go back to the Workbench. I terminate the game (or not, done both), then go back to the game window and close it (or not, done both).

Workbench crashes, or it doesn’t. Have not yet seen a pattern of when it will crash or when it will keep working.

Yes, sometimes I set breakpoints, yes sometimes I step through code. Again, though, no pattern of when it will crash and when it won’t.

Does this happen with a basic project – not your code, but say just a one room game?

This is a good question.

You might try uninstalling and reinstalling. Also, which version of T3 and Workbench are you using? Did you install everything in the default locations, or did you do a custom install?

Also, are you compiling to the WebUI, or is this a straight-up T3 game? That definitely makes a difference in terms of the behavior of the game window.

Hmmm. Good question. I do not recall it happening when I run any of the example projects that I downloaded with the Learning TADS3 manual.

I’ll run a few of them again just to be sure.



Also good suggestions and questions, Jim.

I kept all defaults when installing.

Workbench Help | About screen says…

Release HT-23 (Build Win119; TADS 3.1.2)

Now that you’ve raised the question, I see there is a readme.txt in C:\Program Files (x86)\TADS 3 that says the Author’s Kit was built for Windows 95 and NT, and it goes on to say there may be some HTML TADS incompatibilities with earlier Windows versions due to changes in ComCT32.dll. I have a later version (Win7) but that doesn’t necessarily mean no incompatibilities (though one would hope Microsoft would maintain backwards compatibility).

I am selecting Web UI for my projects in the New Projects wizard.


That’s the same version of Workbench that I have. I think it’s probably current.

I’ve encountered some weirdness running the interpreter in conjunction with Workbench with a WebUI game. One factor that you may need to look at is what version of Internet Explorer is installed in your system. My recollection is that the WebUI interpreter uses IE.

The next step would be to try to identify a set of actions that consistently causes the crash. If you can do this, Mike should be able to find and fix the bug.

I have IE8. Well, specifically 8.0.7601.17514 :slight_smile:

Narrowing down the ‘when’ doesn’t seem likely. It happens under different circumstances. I can’t seem to reliably reproduce it.

The nearest I can come to cause/effect relationships are…

a) when I do some stuff in the game window then go to the Workbench and terminate the game, without having first quit in the game window

b) quit in the game window and start editing stuff and recompiling without having first selected Terminate on the Debug menu and without then going back out of the Workbench to close the now-idle game window

c) let too many idle game windows stack up on the Windows desktop (terminating the game does not close the window, but if I close the window before terminating the game…well, see b above); how many is too many windows? don’t know, eight or ten or so

If I’m ever able to identify how to reproduce it reliably I’ll be happy to file a bug on the TADS website, but without that it’s kind of a wild goose chase. In the meantime, I guess I’ll just have to live with it. As crashes go, it seems benign enough. I’m always able to restart the Workbench. Sometimes I forget to save my source file first and I lose some recent changes, but I’m working on that habit. :slight_smile:


Try upgrading to IE 9. If you still have the problem, do file a bug report. Even if the steps to reproduce it aren’t clear, Mike may be able to help.

I’m getting the same crash. Here’s my suggestion: While developing your game, don’t bother creating it as a WebUI project – just make it the normal way, but read the section on the WebUI and be careful to follow the coding guidelines. That way, when your game is complete, you can recompile for WebUI with no muss or fuss.