Ah yes, the cursor ID issue. I had held out hope for apparently too long that backward compatibility would ultimately become the higher priority, and that they'd adopt the principle of introducing new cursor images with new IDs in a quick bug-fix release.
But it's been long enough that it seems perhaps time that we all consider updating all of our software to correct for that anomaly, and that would include the MC IDE.
Should we update our cursor resource IDs to match the latest engine? Seems we're moving to a world in which is increasingly difficult to have a single IDE that works with multiple engines (consider libURL too), and thus far I think I've been the only one striving for that anyway.
I don't mind updating those resources if the general mood here is that it's time to do it.
Indeed it seems that RR is sitting this one out, so we can probably assume it ain't gonna change back. Otherwise, they would have corrected it right away. I just think they are hell bound to eliminate the hand cursor.
The only problem I see with fixing this in MC will be backwards compatibility with earlier engines.
"Necessary" is the only question. We can't determine how long this legacy bug with image pasting will remain in place, so if we want improved behavior it seems more productive to do what we can with what's in hand than wait for an unknowable possibility down the road.
So do we really want this behavior? I'd find it useful, but I'm not sure if that's a universal desire; maybe some folks like the current behavior (can't imagine it, but HyperCarders sometimes have the strangest habits and this behavior seems to play into the only-one-bitmap HC paradigm).
Would be it plausible for you as the head of the MC IDE group to inquire with Kevin directly about their policy/plans regarding such engine bugs? Possibly each one should be addressed individually. Then we can make an informed decision.
I'm not clear on why so many engine issues are addressed only in their IDE scripts, but since I work on the MC IDE and neither the engine nor their IDE it wouldn't be productive for me to conjecture. My job is just to get the best results I can with what I have to work with at the moment, and leave the learnability of the Rev IDE to its keepers.
It may be that they decided to pretty much freeze the engine and fix all that is possible only in IDE from now on. It probably simplifies their development cycle. I would not want to accuse them of malice and stabbing MC in its back yet, but it surely starts looking like they do little things that will lead to its slow death.
It sure would be nice if some of the things were finalized and we get the next formal release of MC IDE out of the door.
Robert _______________________________________________ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
