Screenmode refuses to change until reboot

[Overmann]

Hello,

I often get into trouble with my Amiga, but I'm getting better at understanding what is going on, but now I really have no idea. I hope some of you guys will be able and willing to help me out.

Everything has been working quite well for a while until i decided to install a bunch of stuff today. I figured that as long as I keep an eye out on my startup-sequence that I'd be able to revert averything if it went bad, but I'm not.

I've installed:
ReqAttack
SystemPatch2
mcc_betterstring
MCC_nlist
MCC_Toolbar
VisualPrefs
Executive 2.10
StackAttack
FBlit
BlazeWCP
PopupMenuUser
SnoopDOS

My problem is, as the title says, that screenmode no longer changes the screenmode. I am able to "save" and reboot, but after Ive pressed "save" or "use" the system hangs in a strange way. I am able to move around, close old windows etc. but if i try to open a new window it hangs on the "timer"-mousepointer.

SnoopDOS reports 3 FAILS when opening "screenmode":

Screenmode ToolType ACTION
Screenmode ToolType CREATEICONS
Screenmode ToolType PUBSCREEN

If i select a new screenmode and press "use" it reports OK from "screenmode" and "<< IPrefs >>".

I dont' know what this means or what could be causing the FAILS. But i have tried removing all traces of my installs in startup and userstartup but other then one less notice from "Virusz" nothing has changed.

Sorry for going on, but I really hope someone can help me out?

[thomas]

Looking only at failures is not the right way to read a SnoopDOS log. The absence of a tooltype is not a problem but might be expected.

What is going on is this: when you click on Use in ScreenMode, the program saves the new settings to env:sys/screenmode.prefs and quits. If you click on Save, it saves the settings to both env: and envarc:.

Whenever env:sys/screenmode.prefs is changed, IPrefs is notified, reads the new file and tries to apply the new settings. Now to apply a new screen mode, the old screen has to be closed and the new screen with the new mode will be opened. But to close a screen, all windows have to be closed first. Workbench can close its own windows, but if other programs have windows opened on the Workbench screen, you have to close these windows manually first.

In order to reduce the manual effort, several people have developed a notification mechanism which lets programs automatically close their windows before Workbench attempts to close its screen. I know of two: screennotify.library and notifyintuition.library. There might be others.

I suspect that a program which utilizes one such notification somehow deadlocks and thus hangs your system.

You should check which programs are running in the background and might have open or hidden windows on the Workbench screen. Remove these programs from your startup. Check startup-sequence, user-startup and WBStartup.

As a test you should remove #?notify#?.library from the libs directory.