Tim Wegner wrote:
Actually, it's an invaluable feature that can be used for many purposes like demos and debugging.
I didn't mean to belittle this feature in any way, in fact it's quite nifty.
Understand that the autokey feature works by directly trapping user interface keystrokes. If the user interface changes, old autokey filews won't necessarily work. There are things the developers can do to minimize this, by adding new menu items to the bottom of menus, etc. It is desireably to not make changes that would break compatability with old autokey files. But fundamentally autokey files are designed to work with the version that created them. If autokey files were procedural instead of just trapping keystrokes, the situatrion would be different. That would be better, but would require a big redesign.
Yes, the Fractint docs are quite clear about the possible "limited lifetime" of an autokey file, so one using them has to expect to have to do some modifying of scripts from time to time. Menu changes are not hard to compensate for, if possibly a bit tedious finding the right places in the files. But things like the zoom box behaving differently require much more fiddling to get the same result as before the change. I wouldn't have bothered you if it hadn't been for the demo files supplied with Fractint - new users would expect these to work. Regards, Gerald
We do need to check to make sure that the new virtual screen logic uses the standard fractint keyboard input routine.