tecot@apple.UUCP (05/30/87)
I posted this to INFO-MAC a while ago, but I was informed that some people might not read comp.sys.mac.digest, so I'm posting again here: What makes programming for the Macintosh difficult? What would you like to see in terms of software to make it simpler? Please no flames about deficencies in Pascal, C, 68xxx or documentation. Also, examples of software which already achieves these means would be useful, such as MacApp or Skel. I'll summarize. _emt
cbenda@unccvax.UUCP (carl m benda) (05/31/87)
In article <869@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: > I posted this to INFO-MAC a while ago, but I was informed that some > people might not read comp.sys.mac.digest, so I'm posting again here: > > What makes programming for the Macintosh difficult? What would you like speed... look at c development on an unloaded vax 780 running BSD 4.3... What I think most programmers would like to see is c development tools and environment such as exists in a Unix programming environment. I personally would like to see the ability to create c code using the text editor of my choice and then leave the editor (using switcher), going to the finder and typing cc filename and with in 30 seconnds I would like to be able to double click the a.out icon. /Carl ...decvax!mcnc!unccvax!cbenda
jwhitnel@csib.UUCP (06/01/87)
In article <725@unccvax.UUCP> cbenda@unccvax.UUCP (carl m benda) writes: >In article <869@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: >> I posted this to INFO-MAC a while ago, but I was informed that some >> people might not read comp.sys.mac.digest, so I'm posting again here: >> >> What makes programming for the Macintosh difficult? What would you like > >speed... look at c development on an unloaded vax 780 running BSD 4.3... >What I think most programmers would like to see is c development tools >and environment such as exists in a Unix programming environment. > >I personally would like to see the ability to create c code using the text >editor of my choice and then leave the editor (using switcher), going to >the finder and typing cc filename and with in 30 seconnds I would like to >be able to double click the a.out icon. How often do you get to use an unloaded vax 780? And who is this wonderful company that gives every programmer their own 780? I use LightspeedC on a Mac with a DataFrame 40XP and this system will meet or beat your 30 second limit for most single file recompiles. It is mostly CPU bound, so with a '20 add-on, it should beat an unloaded 780! Oh, and I don't have to type cc filename (trying to get the filename right) or make or anything, I just hit cmd-R, with 15 seconds and I'm in my application. The real problem with programming the mac is the learning curve. There are five volumes totaling well over 1000 pages of documentation for the OS, not even including tech notes. Once you figure out how to do something, it's a lot faster to use the toolbox then to write it yourself, but learning the toolbox is the major problem. > >/Carl >...decvax!mcnc!unccvax!cbenda Jerry Whitnell Communications Solutions, Inc.
cbenda@unccvax.UUCP (06/02/87)
In article <1118@csib.UUCP>, jwhitnel@csib.UUCP (Jerry Whitnell) writes: > >the finder and typing cc filename and with in 30 seconnds I would like to > >be able to double click the a.out icon. > > I just hit cmd-R, with 15 seconds and I'm in my application. > > > >/Carl > >...decvax!mcnc!unccvax!cbenda > > Jerry Whitnell My question then becomes: Is this "application" a single file which I can then bring to any unsuspecting mac, see the applications icon in the finder, double click on the icon and then have it run in the manner in which it did on the system I developed it on, assuming of course similar memory and other hardware configurations were taken into consideration while creating the application... /Carl
jwhitnel@csib.UUCP (06/03/87)
In article <729@unccvax.UUCP> cbenda@unccvax.UUCP (carl m benda) writes: >In article <1118@csib.UUCP>, jwhitnel@csib.UUCP (Jerry Whitnell) writes: >> >the finder and typing cc filename and with in 30 seconnds I would like to >> >be able to double click the a.out icon. >> >> I just hit cmd-R, with 15 seconds and I'm in my application. >> > >> >/Carl >> >...decvax!mcnc!unccvax!cbenda >> >> Jerry Whitnell > >My question then becomes: Is this "application" a single file which I can >then bring to any unsuspecting mac, see the applications icon in the finder, >double click on the icon and then have it run in the manner in which it did >on the system I developed it on, assuming of course similar memory and >other hardware configurations were taken into consideration while creating the >application... >/Carl You have two options with LightspeedC. During the development phase (Edit, compile, link, crash and burn :-)), it does not actually make a complete application, nor does it strip out all unnecessary routines. This gives it a very quick "link" to execute time. When your application works, you can then build a real Mac application just like any other. The differences between the quick-link mode and a real application are very small, the primary one being that resources must be put in a seperate file (which is automatically opened for you). Of course, when you build a real application, it automatically copies those resources over for you. A more accurate number for the compile speed of LightspeedC is 17,000 to 21,000 lines per minute. The former is the advertised number (Version 0.40) on a HyperDrive, the latter was measured with the latest version (2.01) on a DataFrame 40XP. This number is all the more interesting since Borland's Turbo-C on the PC claims a rate of 7,000 to 10,000 lpm! Jerry Whitnell Communications Solutions, Inc.
tim@ism780c.UUCP (06/04/87)
In article <729@unccvax.UUCP> cbenda@unccvax.UUCP (carl m benda) writes:
<My question then becomes: Is this "application" a single file which I can
<then bring to any unsuspecting mac, see the applications icon in the finder,
<double click on the icon and then have it run in the manner in which it did
<on the system I developed it on, assuming of course similar memory and
<other hardware configurations were taken into consideration while creating the
<application...
No. That will take an additional five seconds to build the applicaton,
and whatever it takes to create an icon. You don't need any of this
during development, which is the slow part.
Here's how it works with LightspeedC:
1: Start up Switcher
2: Start LightspeedC version >= 2, and open your project
3: Edit files
4: issue the run command
5: 10 or 15 seconds later your application appears
running in another switcher partition ( sort of ).
6: if you don't want to see any more, GOTO 9
7: switch to LightspeedC and look at your source
code to try and figure out what is going wrong.
8: switch back to your program. GOTO 6
9: If more work to do, GOTO 3
10: Select "build application", and wait about 5 seconds.
The main slowness comes from the fact that the Mac has no MMU. You have
to insert one more step in the above:
5.1: Your program crashes the Mac. Reboot, GOTO 1.
If you have TMON running, you can often select "relaunch current application",
or "relaunch finder" to save having to reboot, or if you do have to reboot,
you can at least get TMON to unmount all volumes first, so you don't wait
forever for the system to rebuild things when you boot.
--
Tim Smith "Well if you want to say yes, say yes
{seismo,sdcrdcf}!ism780c!tim And if you want to say no, say no
'Cause there's a million ways to go
You know that there are"jdb@mordor.UUCP (06/04/87)
I've been thinking about this subject for some time, but I still have difficulty defining exactly why I find programming the Mac so much harder than programming other machines (particularly UNIX machines). I think that part of the reason for this perception is that (prior to MacApp, at least) the Mac programmer has been required to worry about a large number of interface-specific details, each of which is managed through detailed data structures. By contrast, UNIX programs (other than screen editors or visually-oriented games) have a significantly simpler interface to the underlying system. I haven't done much coding in X (or Suntools, or NeWS [what a stupid name!], or ...), but I suspect that some of this advantage is now disappearing. I have written (BSD) UNIX programs which play with different sockets, XDR/RPC, NFS, etc. protocols, often requiring quite a bit of detail. Transporting a simple UNIX-like program to the Mac (e.g. to run as a tool under MPW) is not particularly difficult. Ever since I first read *Inside Macintosh* I have felt that the interface to the Mac O/S is too low-level. (I am annoyed, for instance, that if I'm using XON/XOFF output flow control the received XON/XOFF characters which the serial driver receives not only stop/start output but also are passed by to my applications as input.) One consequence of this low-level interface is that enhancements and bug fixes invariably seem to break working programs. [One thing which makes UNIX easier for me is that I know how the internals work. (Or at least I once knew. Our BSD kernel is huge, and I can't claim to understand every one of the tens of thousands of source lines.) That understanding biases my comparison with the Mac, because the familiar is always easier than the less-familiar.] Some of my complaints about Mac development have been or are being resolved. These include slow/bad compilers and poor debugging facilities. MPW C is good (although slow), LightspeedC is very fast and accepts modern C constructs. I still sorely miss multitasking, though. I've heard all of the arguments about how we don't really need multitasking if there's enough memory and processor speed. I don't believe them. I know how I use my Mac and how I use my Sun (and how I once used a V7 PDP-11), and I want multitasking. I've already been ridiculed for my editor preferences, so I won't comment on that again. The state of Mac program development is considerably different than it was a couple of years ago, but I think it still has a ways to go. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!seismo!mordor!jdb (415) 423-4848
socha@drivax.UUCP (06/05/87)
<< NOTE: >> Tried To: hal6000!trsvax!ctvax!pollux!smu!texsun!suntri!rti-sel!unccvax!cbenda But died at trsvax calling ctvax so am posting to the net. << original message follows >> In article <729@unccvax.UUCP> you write: >In article <1118@csib.UUCP>, jwhitnel@csib.UUCP (Jerry Whitnell) writes: [in Lightspeed C] >> I just hit cmd-R, with 15 seconds and I'm in my application. >My question then becomes: Is this "application" a single file which I can >then bring to any unsuspecting mac, see the applications icon in the finder, >double click on the icon and then have it run in the manner in which it did >on the system I developed it on, assuming of course similar memory and >other hardware configurations were taken into consideration while creating the >application... For a definite answer, yes AND no! It is a single file but in its normal state it can not be double clicked and run. The programme runs UNDER Lighspeed C (sub-launch) and when it terminates, LSC come back. Now, that's the NO. There is a menu option to make a TRUE double-clickable application (also DA, code library, and more). When this is done, a seperate file is created which is the executable version. It is EXACTLY the same except the internal controls for symbol table/project/make/etc. information have been removed. Also modules that are not necessary have been removed. (i.e. intelligent linker functions.) Therefore it is now independent of LSC, a full app. Therefore YES (with qualifications), you must go through this seperate step to make a double-clickable app. NOTE: the time to generate this app is about the same as the <cmd> R time till running. (Time it takes to read the project and write the app., almost no processing overhead, its minimal.) Note: I've heard mention (not tried) that double clicking with <cmd> <option>? down (forced execution) will run a LSC project. So, in one unusual sense (if this is true), by changing the Creator-Type words you can actually convert the LSC project to a runnable application. (Another qualified YES answer.) Did this help or did I confuse you more? -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein
han@apple.UUCP (06/08/87)
In article <1784@drivax.UUCP>, socha@drivax.UUCP (Henri J. Socha (x6251)) writes: > >In article <1118@csib.UUCP>, jwhitnel@csib.UUCP (Jerry Whitnell) writes: > [in Lightspeed C] > >> I just hit cmd-R, with 15 seconds and I'm in my application. > > >My question then becomes: Is this "application" a single file which I can > >then bring to any unsuspecting mac, see the applications icon in the finder, > >double click on the icon and then have it run in the manner in which it did > >on the system I developed it on, assuming of course similar memory and > >other hardware configurations were taken into consideration while creating the > >application... > > > For a definite answer, yes AND no! > > > It is a single file but in its normal state it can not be double clicked > and run. The programme runs UNDER Lighspeed C (sub-launch) and when it > terminates, LSC come back. Now, that's the NO. > > There is a menu option to make a TRUE double-clickable application > (also DA, code library, and more). When this is done, a seperate file > is created which is the executable version. It is EXACTLY the same except > the internal controls for symbol table/project/make/etc. information have > been removed. Also modules that are not necessary have been removed. > (i.e. intelligent linker functions.) Therefore it is now independent of > LSC, a full app. Therefore YES (with qualifications), you must go through > this seperate step to make a double-clickable app. NOTE: the time to generate > this app is about the same as the <cmd> R time till running. > (Time it takes to read the project and write the app., almost no processing > overhead, its minimal.) > > Note: I've heard mention (not tried) that double clicking with <cmd> <option>? > down (forced execution) will run a LSC project. So, in one unusual sense > (if this is true), by changing the Creator-Type words you can actually > convert the LSC project to a runnable application. > (Another qualified YES answer.) > > An application refers either to a stand alone application (which may be double clicked from the Finder or launched via the _Launch trap) or to desk accessories, definition procedures, or any other type of code resource. I did try to launch a LSC project via the forced launch mechanism (cmd-opt-dlb click) and one of my applications did launch (though it crashed later through no fault of LSC). Also the idea of needing a similar hardware/memory configuration of the machine that the application was built on and the application is run on is not valid. You can build an application on a 5Megabyte Macintosh II with a 80MByte hard disk and run it on a Macintosh 128K - provided that you follow the rules (i.e. do not use too much memory for target machine, make calls that are not supported on the target machine, etc etc etc) ===================================================================== Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han Apple Computer, Inc. | CSNET: han@apple.csnet 20525 Mariani Ave, | ATTNet: 408-973-6450 Cupertino, CA 95014 | GENIE: BYRONHAN MS 27Y | CSERVE: 72167,1664 ===================================================================== All opinions and statements do not necessarily represent those of my employer, Apple Computer Inc. =====================================================================
herbw@midas.UUCP (06/09/87)
--------
Ed, thanks for asking this question. It shows that folks at Apple are interested.
In summary, I believe that there are a few common operations (things that every
application developer needs to deal with) that are not handled completely by
the toolbox routines:
1. I want to put up a dialog with the default button highlighted. The toolbox
routine does almost everything. I must provide my own code to highlight the
button. (Clue that this is difficult: so many applications simply neglect
to highlight the default button.)
2. I want to do a CopyBits of more than 3K bytes. I must write a loop to do
this. Why couldn't the toolbox routine include a check for the 3K limit and
automatically copy the picture in 3K chunks? (Or better yet, check how
much stack space is available, and optimize the copy for the size of the
stack.)
3. My desktop (file) has seen countless failed attempts (by public domain and
shareware programs) to create custom icons for applications and documents.
If the number of failures is any indication, this is the *most* difficult
aspect of programming the Mac. (It's easy once you know how :-) ) I believe
a tool is in order here: Give it the application's signature and a list of
file types with their corresponding icons, and it creates the *correct* BNDL
and FREF resources.
4. Writing custom routines to TrackControl (with different numbers of parameters
for different situations).
5. You asked us not to flame the documentation, so I won't. I'll just say that
doing *anything* with HFS is difficult, since I haven't deciphered it yet
(fortunately, I've not had the need); and creating/playing back pictures
(OpenPicture/DrawPicture) *directly to/from disk* was as much of a mystery
adventure as a number of game programs.
I recognize that MacApp *might* solve some of these criticisms, but MacApp is
not a solution for everyone. It certainly will not help me with the maintenance
of applications that I've already written.
Finally, I would like to point out that I would not have taken the time to offer
these constructive criticisms if I did not like my Mac. Since I believe that
a program is not worth writing *unless* it's going to be friendly, the Mac is
the *easiest* computer I have ever programmed!
-- Herb Weiner (UUCP: !tektronix!midas!herbw)
(AppleLink: D0521)olson@endor.UUCP (06/10/87)
In article <1499@midas.TEK.COM> herbw@midas.UUCP (Herb Weiner) writes: >2. I want to do a CopyBits of more than 3K bytes. I must write a loop to do > this. Why couldn't the toolbox routine include a check for the 3K limit and > > automatically copy the picture in 3K chunks? (Or better yet, check how > much stack space is available, and optimize the copy for the size of the > stack.) > I'm not the least bit familiar with this. I regularly do CopyBits on much larger bitmaps than 3K. Perhaps you are talking about the old 3K limit on the Scrap? I (and I think everybody else) ignore that, since it was a sort of arbitrary limit in the documentation only, to keep things working on 128K Macs. On an unenhanced (64K ROM) Mac, there may be a real limit of 32K on the scrap, due to the bug in WriteResource-- but I've never run into this possible problem, so maybe it doesn't exist. -Eric Eric K. Olson olson@harvard.harvard.edu harvard!olson "If the War were fought today, most Americans doubt that we could defeat the new Japan. Its atom bombs would be cleaner than ours and come equipped with "How Did You Like Our Product" postcards that would drop from the sky and ask questions like "Where did you hear about us?" and "How many in your family died?" -John Dvorak
lsr@apple.UUCP (Larry Rosenstein) (06/10/87)
In article <1499@midas.TEK.COM> herbw@midas.UUCP (Herb Weiner) writes: > >2. I want to do a CopyBits of more than 3K bytes. I must write a loop to >do this. Why couldn't the toolbox routine include a check for the 3K >limit and automatically copy the picture in 3K chunks? (Or better yet, >check how much stack space is available, and optimize the copy for the >size of the stack.) > I don't think the problem is with the CopyBits itself. I have done large CopyBits with no problems (although this was using srcCopy mode, which might be a special case). The only reference to a 3K limit I can recall is in the Tech Note about MacDraw's picture format. The problem there is that if you create a QD picture that contains a CopyBits call, QuickDraw will pack the bitmap in order to save space. When an application tries to draw the picture, QuickDraw will allocate a handle into which it can unpack the bitmap. So a courteous application will create the picture using small CopyBits, so that the receiving application doesn't require as much heap space to draw the picture. I think it would be a mistake for QuickDraw to decide to do the CopyBits in pieces behind the programmer's back. That could have an unknown affect on the application, and is not necessary in some cases. Quickdraw should, however, recover gracefully from a lack of memory when drawing a picture. In general, one of the things I think makes programming the Macintosh difficult is the lack of error handling by the ROM. I will point out that the error handling has improved greatly since the old 64K ROM, and keeps getting better. >4. Writing custom routines to TrackControl (with different numbers of >parameters for different situations). This was an architectural mistake by the original ROM designers. They wanted to save ROM space by using the DragGrayRgn call to drag a control's indicator. Unfortunately, DragGrayRgn's actionProc takes no parameters, while TrackControl's take a couple of parameters. Hence the conflict. >I recognize that MacApp *might* solve some of these criticisms, but MacApp >is not a solution for everyone. It certainly will not help me with the >maintenance of applications that I've already written. You are right on both accounts. MacApp does take care of some of these things for you (eg, outlining the default button and dealing with HFS). We never expected people to rewrite their applications to use MacApp. The best you can do is get the MacApp source listings and see how we handled these situations. (If people are interested in a particular topic -- eg, HFS -- I or someone else can post a short note about how we handled it in MacApp.) >Finally, I would like to point out that I would not have taken the time to >offer these constructive criticisms if I did not like my Mac. You should not have to appologize for well thought out, constructive criticism. I would like to see more comments from other people out there. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
merchant@dartvax.UUCP (06/11/87)
In article <1499@midas.TEK.COM>, herbw@midas.TEK.COM (Herb Weiner) writes: > Ed, thanks for asking this question. It shows that folks at Apple are interested. > In summary, I believe that there are a few common operations (things that every > application developer needs to deal with) that are not handled completely by > the toolbox routines: > > 1. I want to put up a dialog with the default button highlighted. The toolbox > routine does almost everything. I must provide my own code to highlight the > button. (Clue that this is difficult: so many applications simply neglect > to highlight the default button.) > -- Herb Weiner (UUCP: !tektronix!midas!herbw) > (AppleLink: D0521) You do have to provide your own code to highlight it, granted, but in the phone book version of Inside Macintosh (don't know about the other one) they tell you explicitly how to do it and even give you some sample code. I tried it and it wasn't particularly tricky. Not doing it, I think, may be inspired by laziness, not through any major difficulty. Either that or the theory that hitting return or enter is an undocumented feature and need not be highlighted. -- "There were times we had it all..." Peter Merchant (merchant@dartvax.UUCP)
james@cantuar.UUCP (J. Collier) (06/11/87)
carl m benda (cbenda@unccvax.UUCP) writes: >In article <869@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: >> ... >> What makes programming for the Macintosh difficult? What would you like >... >What I think most programmers would like to see is c development tools >and environment such as exists in a Unix programming environment. > >I personally would like to see the ability to create c code using the text >editor of my choice and then leave the editor (using switcher), going to >the finder and typing cc filename and with in 30 seconnds I would like to >be able to double click the a.out icon. No flames please - I know it uses BasicGlobs to hold its global base register, I know it produces atrocious code (don't ever look at what it does to switch statements %-{), BUT I STILL USE MEGAMAX C. I much prefer working with small applications which each do ONE thing (and preferably do it well). The Megamax environment uses small, stand-alone programs which can be tailored into a working environment using a script interpreter "batch". Within this system I can choose any editor and integrate my own utility programs. For backups and access to UNIX tools I can synchronise the batch program with shell scripts on our 4.3bsd VAX, using a hacked terminal emulator. I have made the Mac feel almost like home :-) Lightspeed C epitomises the opposite approach. I hate it. We can't afford MPW. Now if only Megamax would get around to writing a DECENT compiler... ----------------------- The nearest thing I have to an employer doesn't hold opinions on ANYTHING.
lsr@apple.UUCP (06/11/87)
In article <981@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: > >I don't think the problem is with the CopyBits itself. I have done large >CopyBits with no problems (although this was using srcCopy mode, which >might be a special case). The only reference to a 3K limit I can recall is >in the Tech Note about MacDraw's picture format. Someone here pointed out that the 3K reference is in Inside Macintosh (p. I-188). However, the rule cannot be a strict one. For example, the Toolbox itself does not follow it to the letter. When you move a window, the Window Manager does one CopyBits, regardless of the screen size. Again, this is using srcCopy mode, so perhaps the stack is not used in that particular case. This is a case where Inside Macintosh (or a Tech Note) needs to be more explicit about what the stack is used for, so programmers can decide if the warning applies to their applications. I agree that QuickDraw should handle the boundary conditions better (ie, without bombing), but I still would like to know what's going on inside (in order to do optimizations, for example). -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
tecot@apple.UUCP (06/12/87)
In article <1004@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <981@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >> >>I don't think the problem is with the CopyBits itself. I have done large >>CopyBits with no problems (although this was using srcCopy mode, which >>might be a special case). The only reference to a 3K limit I can recall is >>in the Tech Note about MacDraw's picture format. > >Someone here pointed out that the 3K reference is in Inside Macintosh (p. >I-188). > >However, the rule cannot be a strict one. For example, the Toolbox itself >does not follow it to the letter. When you move a window, the Window >Manager does one CopyBits, regardless of the screen size. Again, this is >using srcCopy mode, so perhaps the stack is not used in that particular >case. > >This is a case where Inside Macintosh (or a Tech Note) needs to be more >explicit about what the stack is used for, so programmers can decide if the >warning applies to their applications. > >I agree that QuickDraw should handle the boundary conditions better (ie, >without bombing), but I still would like to know what's going on inside (in >order to do optimizations, for example). > Actually, I got the impression that the 3K convention was only necessary for recorded pictures that would make their way to the scrap. The reason behind this is so that any application receiving a picture from the scrap could guarantee being able to play it if there was at least 3K of stack space available. _emt
herbw@midas.TEK.COM (Herb Weiner) (06/12/87)
-------- In article <1499@midas.TEK.COM> I wrote: >2. I want to do a CopyBits of more than 3K bytes. I must write a loop to do > this. Why couldn't the toolbox routine include a check for the 3K limit > and automatically copy the picture in 3K chunks? (Or better yet, check > how much stack space is available, and optimize the copy for the size of > the stack.) In article <2259@husc6.UUCP> olson@endor.harvard.edu (Eric Olson) replies: > I'm not the least bit familiar with this. I regularly do CopyBits on much > larger bitmaps than 3K. Perhaps you are talking about the old 3K limit > on the Scrap? I (and I think everybody else) ignore that, since it was a > sort of arbitrary limit in the documentation only, to keep things working > on 128K Macs. In article <978@apple.UUCP> han@apple.UUCP (Byron Han) replies: > You could set your application stack size to be larger at startup. In article <981@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) replies: > I don't think the problem is with the CopyBits itself. I have done large > CopyBits with no problems (although this was using srcCopy mode, which > might be a special case). The only reference to a 3K limit I can recall is > in the Tech Note about MacDraw's picture format. > > I think it would be a mistake for QuickDraw to decide to do the CopyBits in > pieces behind the programmer's back. That could have an unknown affect on > the application, and is not necessary in some cases. Quickdraw should, > however, recover gracefully from a lack of memory when drawing a picture. I therefore offer the following quote from Inside Mac, Page I-188, as part of the description of CopyBits (*not* OpenPicture): "Warning: The source bit map must not occupy more memory than half the available stack space. A good rule of thumb is not to copy more than 3K bytes." Since the application involved (MacScan (TM) from New Image Technology) does *not* support 64K ROM Macs (no flames please; it requires a SCSI port and other features available only on MacPlus, Mac SE, and Mac II), I checked Inside Mac, Page IV-23. There is *no* reference to the elimination of the 3K restriction in the new ROMs, although I did find there is a precedent in the new ROMs to gracefully handle limited stack space: "If you tried to draw a long piece of shadowed text, ... Now it detects the potential stack overflow and recurses..." Incidentally, the reason that MacScan does *not* use a larger application stack (as Byron suggests) is that I wanted to dedicate as much memory as possible to the scanned data. An image scanned at 300 DPI eats up memory rather quickly. For this reason, MacScan always creates/reads pictures directly to/from disk (using custom GetPic/PutPic routines) rather than memory (as suggested by Byron in the code fragment he supplied). If it is *really* OK to CopyBits more than 3K bytes under some circumstances, I would like to see those circumstances documented in a Tech Note. (Is temporary stack space required when scaling the bitmap? Is it required when the bit alignment of the source and dest bitmaps does not correspond? Or is it required *only* when copying into or out of a picture definition?) Without such documentation, what assurance do I as a developer have that I would *not* get burned by future Macs for doing something contrary to the advice of Inside Mac (even though it just happens to work correctly on current products). (Shame on you, Larry :-) ) Incidentally, I was quite pleased to be informed that MacScan worked properly on the Mac SE and Mac II even though I had never used either of those machines. There's certainly something to be said for following Inside Mac 100%. I'd like to conclude by thanking Larry and Byron and all those other folks at Apple for their contributions to Usenet. -- Herb Weiner (UUCP: !tektronix!midas!herbw) (AppleLink: D0521)
jww@sdcsvax.UUCP (06/13/87)
I have used a filter proc to outline the default button when it receives
an update event (then pass the update event on). It has worked since 1/86;
and is in my Serializer DA.
--
Joel West
{ucbvax,ihnp4}!sdcsvax!jww or jww@sdcsvax.ucsd.edujdb@mordor.UUCP (06/15/87)
I don't want to seem argumentative about this (something which is very easy to do given the nature of the network). I appreciate that there are ways to highlight buttons so that update events work. I'm not happy with any of them. The default dialog button is an important part of the user interface, and there should be a primitive control type for it. (I think the best approach would be to use SetCtlValue for this, since the value is not defined for ordinary buttons.) I grant that a userItem will work exactly as desired; however, I feel that using a second dialog item in this fashion is a kludge. The highlighted button is one conceptual entity. It shouldn't be necessary to get the order of two separate dialog items correct and to move both of them around when creating and editing the dialog. Nonetheless, it is obvious to me that this is a workable solution which is likely to be compatible with future software, so I'll probably start using it. *Inside Macintosh* indicates that filterProc's can call drawing routines (it mentions an example with a clock). Apparently highlighting the default button before returning the update event (for ModalDialog to handle) works, but this seems to be dependent upon the way in which updates are handled (or, more specifically, upon the way that button controls are updated). If the update procedure for buttons ever changes so that (e.g.) the enclosing rectangle is filled with the background color before the button is drawn, then this method will fail. I hadn't considered calling DialogSelect from inside a filterProc (and then highlighting the button after the update even has been processed), because it seemed like the sort of implementation detail that one shouldn't depend upon. The fact that it works with the current ROMs and System is irrelevant if a future ROM/System change will break it (I was burned by Megamax and BasicGlob, so I'm sensitive to this). If this is an approved technique and isn't subject to change, then I'll happily start using it in preference to a userItem. (In that case, it should also be included in a technote so that all developers can take advantage of it.) The larger issue isn't default button highlighting but providing a framework that shields developers from all of these low-level user-interface details so that they can concentrate upon their application-specific problems. I don't have MacApp yet (I wish there were a C++ version!), but it sounds as though it may be the answer. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!seismo!mordor!jdb (415) 423-4848
lsr@apple.UUCP (06/18/87)
In article <1506@midas.TEK.COM> herbw@midas.TEK.COM (Herb Weiner) writes: >In article <1499@midas.TEK.COM> I wrote: >>2. I want to do a CopyBits of more than 3K bytes. I must write a loop to do >> this. Why couldn't the toolbox routine include a check for the 3K limit > >I therefore offer the following quote from Inside Mac, Page I-188, as part >of the description of CopyBits (*not* OpenPicture): >"Warning: The source bit map must not occupy more memory than half the >available stack space. A good rule of thumb is not to copy more than >3K bytes." I talked to someone in Tech Support about this to get a definitive answer. He thought that the 3K rule was a holdover from the days of 128K Macs, when there wasn't much stack space. He also thought that CopyBits only needs lots of stack space when the bitmap is being stretched (ie, source and destination rectangles are not the same size). -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
carlile@trwrb.UUCP (Donald E. Carlile) (06/24/87)
In article <1499@midas.TEK.COM> herbw@midas.TEK.COM (Herb Weiner) writes: >>2. I want to do a CopyBits of more than 3K bytes. I must write a loop to do >> this. Why couldn't the toolbox routine include a check for the 3K limit > Maybe I'm missing something, but I have done a CopyBits with >3K. I did it by not allocating my source or destination bitmaps on the stack, but on the heap. That gets around the 3K stack problem. Don Carlile