teLength, MacApp 2.0, and MPW

By Larry Nedry, Mousehole BBS

From: Fuzzy

Re: Change teLength

I have a programming problem. I hope someone can help me. I am using TC 4.0. I want to change the length of a Text Record as follows:

                (**gTheText).teLength = dataLen;

Using the TC debugger this appears to work just fine. However, when I follow this with a TEUpdate(gTheText), teLength is set back to the old value. Does anyone know why this happens?

From: Lecroy

Re: Change teLength

You need to also change the size of the htext handle to match the new teLength field. Changing teLength alone doesn’t cause anything to happen (except that teLength is temporarily wrong). The next time you call a TextEdit routine (ie. TEUpdate), teLength gets reset to the proper value.

Here is a Pascal(sorry) code fragment:

         gTheText^^.teLength = dataLen;
         HLock(HANDLE(gTheText));
         SetHandleSize(gTheText^^.hText,dataLen);
      {don’t forget to check MemError!!!}
         HUnLock(HANDLE(gTheText));

You don’t need to lock a handle unless you are dereferencing it *AND* passing the dereferenced portion of it as a parameter into a routine that may cause the heap to move. That’s exactly what I did with the SetHandleSize call. Heap movement can even occur when calling routines that can cause a LoadSeg when called. Also, some compilers may also have problems with using dereferenced handles in WITH statements and when making assignments from function calls (ie. aHdl^^:=funcThatMovesHeap;). I don’t know about the THINK compilers, but it’s my understanding that the MPW Pascal compiler deals with the last two examples properly.

From: Mward

Re: Change teLength

Don’t know exactly why that happens, but it’s probably just as well that it does, since if it didn’t, you might be clobbering important data. The TE data structure, like any other structure, has enough memory allocated to it to hold it, and no more. If you just started acting like it was bigger, you would be writing into someone else’s memory. Use one of the TE functions to add data to the Text Record. That way the toolbox will allocate memory as needed.

From: Venture

Re: Change teLength

Thanks for the clear explanation. What makes me leary of the dereferencing is that sometimes you have to really think (always painful) about when something is passed even within an expression. In retrospect it always seems obvious. One of these days I guess I’ll get a more intuitive feel for what is going on.

Relative to the HLock and HUnLock - maybe it was old code or you were completely sure that you were locking and unlocking a 100% private value.

Anyway, In Vol V of IM (almost sounds like a biblical reference) they change the recommended locking and unlocking process. The new “approved” way is to use HGetState to determine the current handle state and then use HSetState to reset the state after you are done. Thus HUnlock is never (?) used and you won’t inadvertently unlock something which someone else wanted to keep locked.

(Ooops, yes HLock would still be used after the HGetState has been used to find the state to save).

From: Lecroy

Re: Change teLength

You’re right, I should have been checking the state of the handle first to make sure it wasn’t already locked, otherwise I would end up unlocking a handle that was initially locked already by someone (something) else.

Here is a corrected code fragment:

     gTheText^^.teLength = dataLen;
     state:=HGetState(HANDLE(gTheText));
     HLock(HANDLE(gTheText));
     SetHandleSize(gTheText^^.hText,dataLen);
     HSetState(HANDLE(gTheText),state);

Alternately, if you’re really worried about knocking off cycles you can possibly get a speed improvement by using GetHandleBits and checking to see if you really even need to do any locking/unlocking like so:

    handleBits := GetHandleBits(aHandle);
    alreadylocked := BTST(handleBits, lockBit);  {lockBit=7}
    IF NOT alreadylocked THEN HLock(aHandle);
                .
                .
          {play with the dereferenced handle here!}
                .
                .
    IF NOT alreadylocked THEN HUnLock(aHandle);

By the way, where is this documented in I.M. V?? I looked everywhere for it to no avail...

I don’t know of a TE manager routine that concats text to a TEHandle, or truncates the text in a TEHandle. Adjusting the size of TEHandle.hText is certainly better than using [GS]etText with multiple copies of the text handle(?).

From: Venture

Re: Change teLength

I’ll go back and check for the reference tonight. I’m pretty sure it was in V, but let me check.

With regard to lockBit, hadn’t even thought of looking that deep. Fortunately I don’t have the need to get that efficient yet, or I would get completely lost.

I’ll get back to you.

From: Atom

Re: MacApp 2.0 -- worth the cost?

An application I intend to write using OOP will need to include code written in Fortran. Can THINK Pascal 3.0 use MPW runtime libraries? My impression after reading the manual is no, which is why I didn’t consider sticking with TCL a possibility.

From: Siegel

Re: MacApp 2.0 -- worth the cost?

You could use MPW .O files in THINK Pascal since 2.0; version 3.0 supports a couple of extra relocation modes and it supports the segmentation directives, so there should be little trouble in using Fortran .O files.

You may also need to add in FRuntime.o....

From: Walrus

Re: MacApp 2.0

For those of you who aren’t completely turned off by the drastic price increase of MacApp 2.0, it should be shipping any day now. The price does include a few extras that previous releases did not have. Apple’s ‘Intro to OOP and MacApp’ and the MacApp Tutorial (updated to the full 2.0 version) are included when you buy the package. This is saying something since ‘Intro’ is a pretty good introduction for the object programming new-comer (altho’ the new book ‘Programming in MacApp’ is probably the best one -- at least for procedural language programmers).

The upgrade for MacApp 2.0 is a bit odd. It is $120 for the disk version, $80 for the CD ROM. Hmmmm. Of course the CD ROM thing is whole new flame, i.e. why can you get an audio CD player for less than $100 but computer peripherals are many times more and it doesn’t seem to be really much of a difference in function?

All in all, unless one is committed to Think’s Class libraries, this is the way it is.

From: Mward

Re: MacApp 2.0

All in all, this Apple rip-off sounds like a real good reason to get committed to Think’s Class libraries. Think’s product is quick, efficient, pleasant to use, reasonably priced, well supported. And they don’t use upgrades to try and jam Marketing’s Hot Scam down your throat. Apple fails on all these counts.

From: Ray

Re: Desktop Discoloration

I’ve written an application is THINK C that uses the animated colors (i.e. I wanted total control of the color palette). Unfortunately, when you come out of this application, you usually find that the desktop is discolored, because dinking with the palette has changed the colors the desktop uses. Is there a way to record the original palette colors, then restore them so that you “clean up your own mess” when you’re finished?

From: Nicks

Re: Desktop Discoloration

It’s not necessary to save and restore the system palette if you do it right. First, never modify the system palette. Instead, create a new palette, and then make the appropriate QD/Palette Mgr calls to attach it to your app’s window. This involves locking/reserving the colors and defining them as animated colors. Next, use the colors any way you like, and when you’re all done, MAKE SURE YOU RELEASE THE PALETTE and its associated colors, or any other application (such as the Finder drawing the desktop) will be unable to revert to their preferred palette. This is probably the step you’ve left out. (BTW: there are a few games out there, such as Gauntlet, that do the same thing: they grab the system colors, and never release them, so any other color app looks very strange after you run that game.

From: Ray

Re: Desktop Discoloration

Thanks for that information. I am leaving that step out. It’s nice to know I have plenty of company.

From: Chip

Re: MPW vs THINK

I have been programming on Mac for 4+ years in Forth, assembler Pascal, C and now Smalltalk. I originally learned ASM, Pascal and C using MPW, I am now using THINK C. The learning curve on think is significantly less then MPW, and I haven’t experienced any limitations thus far. As for OOP, Smalltalk provides a good tool for learning OOP concepts however I am not particularly fond of programming in it because it was developed on a PC and ported to Mac, and the implementation of some things like buttons etc. stinks. Try an object C language.

From: Hweiss

Re: MPW

I am thinking about purchasing MPW since I would eventually like to learn C++. I thought it best to ask those of you familiar with the MPW environment for some advice.

My biggest concern is the possible limitation of my hardware. Will MPW run comfortably on a Mac Plus with 2.5 megs of RAM? If so, can I assume that I must at least purchase the MPW Shell and MPW C as a bare minimum to program in C? Is it also a good idea to buy the Symbolic Debugger (SADE) now?

I also would like to know if MPW C is 100% ANSI C compatible?

From: Walrus

Re: MPW

OK, I have a Mac SE with 2.5 megs and use MPW Assembler and Pascal -- neither of which can be called a resource hog as far as compilers go. Oh yeah, I also use MacApp. With that configuration, compiling Apples TESample application in the Pascal examples takes more than 2 minutes. The compiled application is a little more than 10k. Turbo Pascal it is not. C generally takes longer to compile, on top of C++ (which is only a pre-processor if my memory is correct) and that the SE is a little faster than the Plus, you’re talking about waiting a few minutes for each compile, although MPW is kinda smart and will not re-compile unchanged files.

I don’t use SADE so I don’t know how much that might affect performance. But I can say that using Multifinder, I don’t have a problem with the memory constraints. And if the compiles get a little over-long, you can click over to another application and work on something else.

If you have Think C and that is not good enough, then you probably don’t have much choice in the matter, it all depends on your reasons for going with MPW.

From: Atom

Re: MPW

MPW C will probably work OK with 2.5 megs, but C++ symbol tables take a LOT of memory. You can get by with a 1 MB partition for the MPW Shell if you’re only compiling small files, but beyond that it depends what you want to do. I would say MacApp is probably not feasible -- you need at least 3 megs to compile the headers with C++ 3.1B1. The final release is due real soon (less than a month), so you might want to wait for it and check back then.

As far as speed is concerned, bear in mind that MPW is VERY disk-intensive, so your hard drive is almost as important as your CPU. SADE requires Multifinder and a 1 MB partition. I wouldn’t recommend it with less than a 4 meg configuration.

From: Jumpcut

Re: MPW

I used C++ and MacApp, and didn’t have enough headroom until I got 8 megs. Watch out, those symbol tables get huge. (Fun thing to do: bring up the Finder’s about box, and watch the memory graph as you compile. It’s amazing how much it sucks up!)

From: Derek

Re: Bypass Chooser

Hello there. I am writing a program that needs to use 2 printers. So I need to know how to bypass the chooser within my program. They are both on the network. So what toolbox commands do I use? Is there any code example out there? Any help would be real nice. Thanks in advance.

From: Mrteague

Re: Bypass Chooser

I can’t tell how to bypass the chooser (nor would I recommend that), but there is an FKEY making the rounds at the moment that allows a user to toggle through all printer drivers in their System Folder - maybe you could get a hold of a copy and have a look at it. I imagine all it does it change the STR# resource in the System File that contains the information about the current printer etc.

From: Listhax

Re: Volume Icons

Does anyone know how to get the actual volume icons (e.g., the AppleShare icon) from the device drivers? The Tech Node just talks about the media/drive icons. I’m writing an application that needs to display the icons as they appear on la Desktop.

From: Rino

Re: Mystery globals & Macsbug

There is a “technote” or pamphlet about Macsbug that somewhat describes the MacJmp vector. Macsbug keeps the pc,regs,etc at a special ram location which are sometimes purposely corrupted by some a.....les copy protection. Anyway, Macsbug uses the MacJmp vector to determine if the break is from within or without ???? what. Upon entry into MacsBug, it determines if the breakpoint that was set earlier is still there. That is how it sees if it has been overwritten. I believe that for brkpnts in ROM it is using the special RAM locations to know where the PC is and what the state of the registers is. I hope this was of some help.

From: Ray

Re: Coprocessor help

Is there a way (in Think C in particular) that you can make a program take full advantage of a coprocessor if it is there, but still run on a Plus or SE? I know SysEnvirons will tell you if the coprocessor is there, but I don’t see how to take advantage of this fact, since with Think C you compile either for the coprocessor or not, and you can’t change off within a program (I don’t think) to use the right code. Maybe a macro that calls either of two branches depending on whether the coprocessor is there or not?

From: Fortune

Re: Patching Traps correctly

I was wondering if there was an example init or a document describing the correct method for Patching traps. Most the examples I have seen are tail patches (i.e. they do something, call the original trap, get the return value {if any}, and then return themselves). At the last MacWorld tail patching was something the Apple Guru’s were VERY much against.

I am looking for a *COMPLETE* description of a head patch. I am interested in what values are on the stack when the trap is called, and how to manipulate these values and replace them on the stack before *JUMPING* to the original trap.

The ideal answer to the request is a pointer to a well documented INIT which does a good head patch and manipulates the parameters that are passed to the trap, but pointers to documentation would also be helpful.

From: Rguerra

Re: Standard File Answer

Well, it seems I was a bit premature in posting the prior message. It turns out that just prior to calling the SFdlogHook procedure, Standard file stuffs the name and fileType in the fName and fType fields of the SFReply record respectively for FILES, and stuffs the dirID into the fType field for FOLDERS while leaving the fName field equal to nil. If NOTHING is selected BOTH fields are set to nil. So ... to test if the currently selected item in an SF dialog is a folder:

if (LONGINT(theReply.fType) <> 0) and (theReply.fName = ‘’) then {it’s 
a folder}

if you know the restype you are displaying, you can test the fType field for a specific resType to determine whether you’ve got a file selected.

From: Siegel

Re: 2 questions re: Memory Mgmt.

1) When running under MultiFinder, BufPtr should only be modified at system startup time, otherwise you end up stomping on MultiFinder’s heap.

2) You can preflight segment loads at a low level if you hook the _LoadSeg trap, as MacApp does. Getting in on SysError is way too late. If you don’t want to hook LoadSeg, you can always preflight your segment loads by calling GetNamedResource (assuming you’ve named your code segments), and verifying that the result is non-NIL.