Menu Bar Hiding and teLength

By Larry Nedry, Mousehole BBS

From: Sysop

Re: Trojan Horse

There is a trojan horse INIT called Steroid that claims to speed up QuickDraw by about 40% when in reality it will zero out all of the disks that are online. It checks to see if the date is 06/06/90 or later and wipes out your disk drives if it is.

From: Tenenbaum

Re: Rotating Regions

I trying to find an easy way (if it exists) to rotate previously defined regions. I’ve just started reading MacTutor regularly so I don’t know if this topic was covered in a previous issue (if not, maybe I’ll write something about it after I figure out the answer). I’m using THINK Pascal 2.0 and am trying to rotate irregular shapes (triangles, trapezoids, etc.) 45 degrees counter clockwise and clockwise. I appreciate any help or shove in the right direction(s).

From: Johncasey

Re: PICT Question

There is a problem with saving PICT images that exceed 32K in size. Before the color Macintosh II, it was very rare for a PICT file to exceed 32K. If you read pages 87-90 in Inside Macintosh volume V, it provides some example Pascal source code that shows you how to spool PICT data to and from disk. This code uses “hooks” to the Macintosh Toolbox routines, so don’t forget that any routine called by a Macintosh Toolbox routine MUST be declared as “pascal”.

From: Chenette

Re: Large Regions

Help! In using the new BitMapToRegion routine, I’m creating some really large regions ( like 20-30 K). When I try to do a FrameRgn(theRgn); one of the larger ones, I run out of memory big time! Inside Mac only says that if a line can intersect the region more than 25 times the results of FrameRgn are undefined. What in the heck does that mean, and what happened to setting good old error codes and nice things like that? A similar problem occurs of course in doing UnionRgn on these large regions. How can I tell I’m going to end up in never-never land before I actually get there? Thanks for any ideas.

From: Jduesen

Re: bitmapped image outlining

I have a graphics problem to solve on a Mac, Can anybody point me toward algorithms, articles, or source code that will help me to solve the following: given a bitmapped bilevel image (i.e. black & white) that exists in an offscreen bitmap, I need to come up with an outline that traces all the edges of the imaged object - something like the “auto-trace” or “trace edges” features found in many paint programs. The ultimate goal of this project is to derive a list of vectors that can be used to setup a Postscript clipping path. “Edges” means not only the outer boundary of the image, but any “donut holes” that may exist in the object. I’m sure this is a classic image processing problems, but so far I’ve seen little that seems relevant in the texts

I’ve looked at. Any advice appreciated! Needn’t be Mac-specific, though ultimately this must work on a Mac, under 32-bit Quickdraw.

From: Jmoreno

Re: Hiding the menu bar

I don’t know HOW to HIDE the menu bar. And I wouldn’t try to either. If you don’t want the menu bar showing up there are several things you can do, some of them bound to cause trouble later:

1: Draw to the screen at the top, bound to cause trouble sooner or later.

2: Change the menu bar info, i.e. heighth or width, ditto.

3: Make a window the width of the main screen and the heighth of the menubar and fill it with the desktop pattern, probably won’t cause problems.

4: Wait for Apple to add a HideMenuBar to the toolbox, no problems.

5: Patch the DrawMenuBar procedure, depends how good you are at writing patches and if there is some app out there that calls it directly instead of going through the DispatchTable like it’s supposed to.

From: Jersquare

Re: Hiding the menu bar

I remember doing this in C a while ago, what I did was set the MBarHeight to 0 (after saving it first) and then creating a rgn that was the size of the menubar, I then created a new window that was the size the the screen, and joined the two rgns.

I will see if I cannot dig up the code, and turn it into Pascal in the next couple of days.

From: Chip

Re: Palettes in Smalltalk

I am trying to implement palettes (or floating windows) in Smalltalk/v Mac. Has anyone done this?

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: Rguerra

Re: TP 3.0, HeapCheck, and standalone

An interesting observation re: TP 3.0 and its HeapCheck function. I was building an FKEY and debugging it in the TP environment. When I tried to compile it down to an FKEY resource, the Linker complained that I had 72 bytes of global space. After hunting unsuccessfully for the global variables I thought I left in one of the units, I realized that I had left the HeapCheck call in the code. I removed it, and all was well. Just thought I’d post this to save someone a few minutes of head scratching if they run into a similar problem.

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.

Hope this is of some use to others.

From: Dsifry To: /Toolbox

Re: DSAT resource format

Is there any documentation available on the DSAT resource (namely DSAT id = 0) in the system file? This is the file that contains things like “Welcome to Macintosh” etc shown on startup. How would you go about changing this resource safely? What is the format of the extra info? Any help is appreciated.

From: Tookie

Re: ArcMac de-arcing problems

I’m having no success in using ArcMac (or something called dearc 512) to de-arc .ARC files downloaded from, e.g., Compu$erve. I’ve tried this on several downloads and the de-arcer of the moment always complains that the file is not an ARC file, etc., whereupon I typically find myself in Macsbug. Is there an ArcGuru out there who knows how to diddle the secret decoder ring?

From: Sysop

Re: ArcMac de-arcing problems

There is a new version of ArcMac that I uploaded to the Utility file library a couple of days ago. I also just uploaded a couple of older programs that have a better user interface, MacArc and DeArc. Give them a try.

From: Mrteague

Re: ArcMac de-arcing problems

First of all, you have to make sure when you download .ARC files etc to a Mac, that you turn MacBinary OFF, and you DON’T let your comms program strip Linefeeds or other control characters (as some are wont to do), as this will screw your file.

Secondly, I think you will find that ArcMac (I think 1.3b is the latest version) works better than MacArc (0.4) as regards types of ARC files to unARC. I can’t remember the “magic” filetypes that some of these de-Arcers are looking for, but if you still have problems, let me know, and I will find this info out for you.

Thirdly, it is possible the files you downloaded were archived with a different version of ARC/ZIP/PKPAK etc that your Mac de-Arcer handles - in which case you are out of luck until you find something to do the job. If you get desperate, many of the PC BBS’s allow to extract specific files from an archive while ONLINE.

Hope this helps.

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.

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: Dsyl

Re: MSoft Basic w/ Appleshare

Environment: MacPluses and AppleShare 2.0 network. One office does not want their Mac on the network because user has Microsoft Basic program with LPRINTs and LPRINTs don’t work to print over the network. Is this true? (I don’t have Basic to try it). Can someone suggest an alternative programming style that works? I understand the user wants to intermix interactive screen stuff with printing, i.e. ask a question on the screen, get an response, print something and repeat. Apparently there are a series of programs, moved to Mac from who-knows-where, so I need a suggested change that is easy to apply, fast, etc.