Rather than clutter up SteamHammer's thread, I thought it might be better if I raised this slightly different NS problem here...

I noticed 2 things after the last system reboot yesterday.

First, the Nexus magnify effect which was working until about an hour ago has suddenly stopped again. I haven't touched anything in NS or WS, nothing has been installed, removed, deleted, or added, it just stopped. I'll chase that up in the other thread later, but I wanted to drop that in here in case I forget... sorry!

The biggie is that NS is now repeatedly crashing and taking away the systray almost every time I try to bring up the NS prefs dialog. It nearly always (8/10 times) crashes if I double-left-click on the NS systray icon, and I don't really use the other alternatives (context menu on NS objects) enough to say reliably that they are worse or better than the systray icon.

I don't have a lot of bandwidth at the moment (I'm ramping up after tax reaming) to keep testing the prefs dialog/crash/systray removal/restart the shell or logoff/on again, but if that would help, I'll try my best in the next day or so.

The UAE message seems to be consistent, and choosing to attempt to continue or cancel doesn't seem to make any difference to whether or not the systray goes or stays. So far, no matter which option I choose, I lose the systray every time.

I'm using a different theme setting to the WS, and I don't have WS and NS "engaged" (think Jean-Luc Picard...).

Ummmm.... I think that's it for now. I started this post at around 11AM, so 9-some hours later I finish... Wow that's slow typing, huh

Oh Pete, I really wish I had something to tell you.

All I know is that Nexus magnification uses the hardware hi-response multimedia timer. If something prevents it from firing, magnification goes bye-bye.

If you think about it, you shold realize this is not a WorkShelf bug per se, not if it was working and it suddenly stopped without you making any changes. Probably some weird system interaction? But what?

Did you try setting another effect to see if that works?

Jorge, there's no need to apologise! I learn something new every day. I wasn't aware at all that the visual effects used in the docks rely so completely on windows mm internals to work properly.

You're right, if nothing changed as far as Workshelf/Nexus is concerned, then something else is wrong with this system.

I'm not completely surprised about this issue not being related to WX. I've had an open call with AMD for nearly a year trying to find out why directdraw actions cause all active application windows to frantically repaint tens (and in some cases, hundreds) of times - each time the mouse movement triggers an underlying graphic effect. It's most noticeable with Winstep, the zoom behaviour triggers thousands of frantic repaint flurries due to the number of actions performed during the zoom, and especially when I'm scrolling the mouse across one of the subdocks.

The graphics subsystem is as fast as it was possible to design it at the time, so the flickering literally takes just milliseconds per trigger even with thousands of onscreen GDI objects, but it does happen.

But so far, Winstep has not really suffered from the problem, instead it used to just trigger the repaints but was able to keep the effect working. This problem (WS now not working as it used to) is definitely new!

This started out being an Adobe-only effect, and Adobe is by far the worst offender. They use non-standard GUI (and GDI) objects in their applications, with Audition listing over 2,100 GDI object handles alone - with no waveform loaded! Premiere Pro is even worse - up to 3900 GDI handles before any editing is started. And all the Adobe apps are so poorly coded in terms of device context handling, they interfere with EVERYTHING. Including blocking DC repaint calls to unrelated apps. The number of times Audition will suddenly and without warning paint itself across an office application, or during video editing (or posting on forums) has to be seen to be believed.

The Logitech and Microsoft "point" drivers make the problem very much worse, but neither will own up to their coding bugs and poorly tested drivers. As always, it's a "hot potato" game between the OS, driver, and app developers.

Unfortunately, my business is built around Adobe apps, so this is a problem I have to put up with, because there's nothing else out there that even comes close to Adobe's apps in terms of features or performance, regardless of cost. I've been doing this long enough to know the main players, and in a limited marketplace, the seller has the control!

Unfortunately for me, AMD keep telling me it's an application issue, Adobe tell me it's a driver/OS issue, and Microsoft tell me it's a driver/app issue.

Meanwhile I end up on your forum complaining about a visual effect that doesn't work because of A) Adobe, and/or B) Microsoft, and/or C) AMD.

If you have any ideas or suggestions on how to maybe find out where the disconnect is, using log files or events, or anything that might help figure out why Winstep is suddenly getting affected worse by the problem, that would be a good next step (pun not intended ).

Whoops, I should add, that the NextStart problem (crashing when the preferences dialog is opened using the systray) still happens about 5 times out of 4...