Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!princeton!udel!burdvax!sdcrdcf!trwrb!cadovax!keithd From: keithd@cadovax.UUCP Newsgroups: comp.sys.amiga Subject: Re: Intuition's "dont mess with these" fields... Message-ID: <1857@cadovax.UUCP> Date: Mon, 9-Nov-87 13:50:52 EST Article-I.D.: cadovax.1857 Posted: Mon Nov 9 13:50:52 1987 Date-Received: Thu, 12-Nov-87 02:40:52 EST References: <1961@amiga.amiga.UUCP> <1825@cadovax.UUCP> Reply-To: keithd@cadovax.UUCP (Keith Doyle) Organization: Contel Business Systems, Torrance, CA Lines: 62 Keywords: Intuition verboten nopokenzefields In article <305@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >Wrong. Once a program exists that supports a feature produced by a hack, >that program is in deadly danger of breaking at the next OS release, as >had been found out, sadly, by many vendors of Apple ][ software, Mac >software, Atari software, IBM software, and endlessly on. The culprits >include some of the biggest names around, not just hackers. Yes, and why? Because IBM, Apple, Atari, etc. couldn't give them the kind of support they needed to produce their package. They had to resort to hacks to remain competitive. >> 4. Most end-user customers have no understanding of any technical >> difficulties caused by any of these issues (which are all self- >> imposed software limitations) and will expect such features. > >Wrong. End users do not understand these limitations, and quickly learn >to adapt to the limitations as they use the software. Yes, and they blame the individual software package for limiitations that were actually imposed by the underlying support system. You find that acceptable? I don't. I think they'd like me better if I sent them a new version at 1.3, just like most of the rest of their packages. *I'm* the one that want's to avoid that, because it costs me money. >>When CBM is not responsive to the demands of the customer, they lose a >>lot of currency with the customers. > >And when Keith Doyle is not responsive to the demands of the customer, >by providing software which will break as soon as a new OS release comes >out, he loses even more. They won't think it's Commodore's fault, they'll >think it's YOUR'S. Either now or later. If I don't provide the capability, they'll blame me now for having limitations they don't understand, or later if it breaks under a new release. At least later, I will no doubt be in company with a lot of other developers, and aren't opening myself up to the competition now. >How about figuring a way to do whatever it is that you want to do within >the limitations of the system as it really is, rather than as you want >it to be? Sure, that might not be as slick as you originally thought, >but it will have the advantage of working, now and forever. Well, I suppose I could create a mouse pointer image where the "hot" point is actually a hundred or so pixels above where it seems to be, so that the visible pointer will extend as far as I need, and then compensate the coordinates. Then I can detect the middle of the screen and readjust it when I am in the upper portion of the screen so I can also move all the way to the top and left as well. While such a scheme could be made to work, it is darn messy, prone to bugs, probably causes some kind of a crazy glitch in the middle of the screen, won't multitask well, and it probably will end up having to do something that isn't guaranteed to work in 1.3 either. In fact, I doubt that much is "guaranteed" to work in 1.3 anyway. I can think of a few other ways to kludge a mouse that will cover an overscan screen, but we're all subject to something breaking at 1.3 anyway. I figure the best way to avoid that is to open a discussion with Commodore on the subject ahead of time. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170