Mousehole Report

By Rusty Hodge & Larry Nedry, Mousehole BBS

From: Tomt

Re: global variables

This is probably a dumb question but is there a way in LSP 2.0 to create global variables that are accessible by multiple units? As an old Fortran person I’d really like the equivalent of a common statement to give global scope to a variable, I’d even settle for something likes C’s extern statement. Thanks for any help. By the way I’d like this to work independently of the build order.

From: Siegel

Re: global variables

Declare any public globals in the interface-part of a UNIT, and any other UNITs that want that global should USE the UNIT where the global is declared.

From: Jmoreno

Re: global variables

The best way to create global variable that are accessible by multiple units AND independent of the build order is to create a unit with just global declarations and have it first in the build and have all of your units use it. Something like this

Unit MyGlobals;
INTERFACE
CONST
MyConst = 32;
TYPE
MYTPE = INTEGER;
VAR
MyGlobalVar: INTEGER;
SecndGlob:Str255;
IMPLEMENTATION
{ I don’t need no stinkin implementation}
END.

From: Macww

Re: global variables

Someone else has probably replied by now, but here goes. It is very common for a Pascal program to have a separate unit, consisting of an interface section only, declaring all global constants, variables, types, etc. Put it first in the build order, but the order of subsequent units will not matter vis a vis the Globals unit.

From: Jmoreno

Re: Dispatch Table

I’m trying to gain some experience with C by translating a program I have from Pascal to C. I don’t want to do a line by line translation, and I noticed that I could handle menu events using a dispatch table to functions instead of a bunch of switch statements. My problem is that I can not get the dispatch table to compile under Think C 3.0. Could somebody please post an example of one?

From: Noisy

Re: Dispatch Table

One way to code a dispatch table in C is to create an array of pointers to functions. That way you can provide your own indexing techniques and bypass multiple depths of switch() statements. This does have some limitations though: since all the calls are made through a single statement, ensuring that each function gets the correct type/number of parameters can be a headache (typecasting unsigned longs is probably your best bet). Secondly, heaven help you if you try to jump with an invalid index value...you’ll discover the delights of the BRND (Branch to random address) opcode! Anyway...here’s a little source to help you on your way:

typedef void (*FuncPtr)();
FuncPtr func_list[] = { my_func1, my_func2, my_func3 };
...
index_val = 2; /* whichever value you want to jump to
(*func_list[index_val])(parameters...);
...

Eh voila! Instant jump table.

From: Gurglekat

From: Dhands

Re: MacApp & Dialog Items

I just started using MacApp 2.0b9 and I have a simple question... What’s the best way to validate a dialog item’s data before dismissing the dialog? I currently override the “CanDismiss” function and check the items there, this seems awkward as I go about checking each field for valid data. The checks are very simple, for example, verify that all EditText items have text. Any suggestions?

From: MacDTS

Re: MacApp & Dialog Items

Override this taken from UMacApp.TControls

FUNCTION TControl.Validate: LONGINT;
BEGIN
Validate := noErr;
END;

Write the routine that validates the control’s data. Also look at how the numbered text controls work.

From: Chuckb

Re: Cross-Compilers

I’m looking for a cross-compiler that runs on a mac and compiles at least z80 code. I’d prefer to have one that does a variety of different processors. Does anyone have any experience with such a beast?

From: Apage

Re: Cross-Compilers

Check out MicroAsm’s in MacTutor’s ads, they have a wide variety of cross assemblers for the Mac.

From: Gpoole

Re: INITs

This is a fairly open-ended question but we would appreciate any help we can get on this matter. The subject is INIT’s, or more specifically, how to get along with them. We are developing a program for commercial release and all seems to work fine as long as we are using just Finder or MultiFinder, no bombs, errors, weird happenings, quitting unexpectedly, etc. As soon as we have some INITs in the system though, all kinds of weird things start happening. With that said, are there any general guidelines we as developers should follow in coding to peacefully co-exist with INITs? Are there any known defensive programming techniques? In case it helps, some the INITs we have are: DialogKeys (CE Software), SuperLaserSpool, PowerMenus, Capture, CanOpener, and Suitcase. Thanks for any help you can give.

From: Gurglekat

Re: INITs

The only thing I can think of for general defensive programming against INITs is to assume that ALL traps move memory. Patched traps can, of course, move memory, and INITs patch traps... I don’t remember where I heard this; maybe from one of Knaster’s books.

From: Rguerra

Re: INITs

It’s probably SAFEST to assume that ANY trap can move memory. While a patched trap’s code in and of itself doesn’t absolutely HAVE to move memory, there are no guarantees. If you’re going to patch traps, one should avoid appending code that moves memory in a trap that is NOT supposed to do so. But who knows what goes on so ... Let’s all be careful out there!

From: Gpoole

Re: INITs

Thanks for the replies to my INIT question, especially the one from DTS. I also asked them this same question and the reply was that there is nothing that can be done for defense. The trenches seem to know best.

From: Brad

Re: INITs

If your program doesn’t get along with the INIT’s you mentioned in your message, then either you have a knack for finding bugs in other people’s code, or your program is doing something very wrong. I work on a very large commercial product, and I run with dozens of INITs, MultiFinder, EtherTalk, etc, and darned near all of the crashes I see are either bugs in my code or bugs (occasionally) in the system. Some INITs out there are downright dangerous and shouldn’t be distributed, but many of those you mentioned could be considered standard equipment on many machines.

From: Brad

Re: INITs

It’s ridiculous to program as if any trap can move memory. If someone patches a trap that is documented as NOT moving memory, and, as a result of something in the patch, memory may be moved, then the patch has a bug and shouldn’t be used. Defensive programming is important; check your error codes, preflight, don’t assume, etc - but there’s no need to get carried away. Relocatable blocks don’t relocate unless provoked, and they only get purged if they’re purgeable and memory is tight. (But come System 7, and who knows...)

From: Gurglekat

Re: INITs

It’s not the tough to program as if any trap can move memory. All you really have to be careful of are WITH statements, keeping handles half-dereferenced across traps, and passing dereferenced elements of records in handles as VAR parameters. HLock and HUnlock aren’t that hard to use.

From: Coretech

Re: TEHilite, ColorWindows, & Mac II

I am making reference to the color that TextEdit uses for marking highlighted text for selection purposes. When the COLOR cdev changes this, does TE then ignore the color specified for highlighting in the window auxiliary record? Is there anyway to avoid this change from occurring? (I would like to be sure that highlighted text is always visible by controlling the colors myself). I don’t know much about color as I don’t have a color machine, but I do have an SE/30 which has the color QD roms. The only problem is that I don’t encounter the problem on the SE/30 machine, only on a true color machine. I fear that the problem stems from something that I am doing in my code. If the text that is highlighted is left highlighted and a different selection is highlighted, the second selection is highlighted without any problems. The problem only appears after I do a mouse down in content and then move the cursor location to the location of the mouse down, deselecting any highlighted text. If text is again highlighted, the problem of the “invisible highlighting” occurs once again. Please help me. I am new to the color world and would like to support it in my program.

From: Essam

Re: Simple INIT

There was a beautiful example of an INIT that stays around (by patching GetResource and ExitToShell to beep when an application is launched or quit, found in MacTutor June 1989. Unfortunately, this INIT was in Forth. Does anyone have a LSP Pascal version of this code?

From: Inbox

Re: LSP I/O procs

It seems that LSP’s built-in I/O procs don’t work properly with HFS. My app uses info passed by SFGetFile in the Open(myFileVar,name) call but I can’t access files that are in a directory other than the one the app is in. What should I do? Do I need to use PBGetCatInfo or something of this sort?!

From: Siegel

Re: LSP I/O procs

IF you’re getting back from a standard file call, do a SetVol(NIL, reply.vRefNum) before calling the library routines.

From: Unclejim

Re: Disk Based Scrolling

Help! I am still struggling with getting some disk based scrolling to work. I need to scroll around in 200-300K files and only keep 40-50K in memory at one time. (Scroll Up & down etc). I can’t seem to keep my scroll bars moving smoothly as I swap buffers and use TESetText etc. If anyone has even the simplest example of this disk based scroll in any language it would be a terrific help. Editing is not an issue at this stage just scroll up and down and keep track of the buffers. I thought it would be easy; it probably is, but I’m not having much luck so far. Thanks Jim

From: Inbox

Re: Ah, yes...

Yet another wall stands before me... Can an Apple IIGS connect to a Mac via the AppleTalk cable? It seems that I’ll have to pump data back and 4th between the Mac and the GS, and I wonder whether AppleTalk can do it. Also, what special knowledge will I have to obtain to use the thing?

From: Mrteague

Re: Ah, yes...

I have often transferred data between Apple IIGS & Mac, using a DIN-8 to DIN-8 serial cable, and comms software on each end - I have 19.2K out of it no problem. As for using AppleTalk - you would need to have appropriate software on both ends, and the only product that I know would fit your ends, is AppleShare. Can’t help you on the other question.

From: Jmoreno

Re: arrays as files

Here is some pascal source for finding you were launched with a file

CountAppFiles(AppMessage, NumAppFiles);

IF NumAppFiles <> 0 THEN { the user has opened documents from the finder }

that would be something like

CountAppFiles(AppMessage,&NumAppFiles);

if NumAppFile != 0 /* open the file */

From: Cforden

Re: Converting to TC 4.0 docs?

I have just started trying to get our project converted from THINK C 3.0x to version 4.0. There have been a few things I’ve had to change to do to accomplish the conversion. Not one of them has really stumped me for more than a hour, but I wonder: isn’t there any documentation addressed specifically to 3.0x users who are trying to convert their existing projects? We ordered our version 4.0 in response to Symantec’s upgrade brochure, but when I opened the package I saw no documentation directed towards those of us who already had 3.0 projects. I already like some of the little improvements in 4.0-- like allowing duplicate function prototypes-- but wish there was some hand holding by THINK for us as we convert. I also would like to see a complete list of differences between the two versions so I could take full advantage of all the improvements.

From: Siegel

Re: Converting to TC 4.0 docs?

The differences between earlier versions and 4.0 are described starting at the bottom of Page 8 in the 4.0 User’s Manual: “Notes For Experienced Users”.

From: Nedry

Re: Converting to TC 4.0 docs?

The Think 4.0 User’s Manual does not describe any differences between 3.0 and 4.0. It only describe the additions. I have had to modify every one of my projects dues to changes in Think C 4.0. Most changes are minor but they take time. A list of the changes would be nice to have!

From: Cforden

Re: Converting to TC 4.0

Some hints for converting your projects from THINK C 3.0 to 4.0. There is a serious bug-- atof(“.03”) returns a value of .3. (The new routine wrongly strips leading zeros between the decimal point and the first significant digit.) You will encounter “unknown error -192” when compiling files with previously precompiled headers. Re-precompile them. You will have to change ‘#include “strings.h” ‘ to: ‘#include “string.h”’. You will be allowed to have multiple identical function prototypes. The new version of ResEdit supplied (1.2) now allows you to open a Project.rsrc file and launch ResEdit by double clicking on the .rsrc file.

From: Brad

Re: Dialogs

Don’t over-complicate things. There is no restriction that all of the code for your XCMD needs to be local to your Main function. As long as the entry point is Main, you’re all set. If your filter function needs to access variables, just allocate them somewhere and stuff a reference to them (either a pointer or a handle, if you prefer) in the RefCon field of the dialog. Since your filter gets the dialogPtr passed to it, you can use GetWRefCon (dialogPtr) to access the reference to your variables.

From: Alamac

Re: LocalTalk xones

I’ve read the threads on this subject and I understand your need to provide a solution without adding a lot of expensive hardware. Check out a software solution called Liaison from Infosphere at 800 445 7085. It looks like it will accomplish what you want. Plug an Appletalk line into the printer port of a Mac and plug the other Appletalk line into the modem port of the same Mac, run Liaison in the background and voila, you have just created two Appletalk zones. Sorry for the late supply but my machine has been away for about 6 weeks. Hope this helps.

From: Gurglekat

Re: LocalTalk xones

Well, it looks like we got some little beastie from Shiva to do the zone divisions. It turned about to be close to $500, but what’s $500 when you NEED the thing?... Thanks for the reply anyway. The software solution sounds like a nice alternative.

From: Rguerra

Re: APPLICON

Has any seen or heard of an INIT called “Applicon”? It apparently was written by someone at Apple and implements a Set-Aside feature such that the switched out layer’s windows are zoomed down to a single icon placed on one side of the screen. I was told by another Apple employee that it has been discussed on AppleLink and the internal Usenet areas at Apple quite a bit and that the author wrote it as Freeware. If anyone has it, I’d really appreciate it if you’d upload it here. Thanks!

From: Gurglekat

Re: APPLICON

There’s a thing running around on CompuServe called AltWDEF (and another similar one called AWinDef, I believe) that does the window-shrink-to-icon business. It’s an evolving thing, so I’d need to check on it if you’re interested. Odds are that someone who calls here has it. I suggest you repost under a different header that long distance people (most of the users?) might not skip over.

From: Walrus

Re: Programming Environments

Is it my imagination or are many of the programming environments available on the MS-DOS machines slicker and simpler than on the Mac? I am most familiar with the Borland products for the IBM and the Symantec packages. For instance, you are writing a program, you try to run it and it bombs. Turbo whatever will blow you back into your source code, right where the problem happened. Turbo Pascal 3.0 was doing this years ago. Is there some inherent problem with the Mac that prevents some of these labor saving things (like moving necessary files into projects, can’t it do it on the fly?). Of course, I work on a mainframe so I still have to submit batch jobs to compile and run programs, but, the Mac is supposed to be slicker than the IBM!!

From: Siegel

Re: Programming Environments

The Symantec environments do all of this; if an error happens, the source debugger will show you where it was detected; also, both THINK C and THINK Pascal have commands to add the current window to a project, and THINK C will add a file as soon as you save it and compile it.

From: Gurglekat

Re: Programming Environments

As a matter of fact, I did a project a while back that run under Turbo/PC and Lightspeed/Mac both. At the time, Turbo/PC had just come out with a new version that looked suspiciously like it had taken a LOT of cues from Lightspeed. I’ve heard the new debugger in Turbo/PC looks a little bit too much like Lightspeed, too...

From: Arlen

Re: Programming Environments

Yes the “integrated” environments are slicker on the IBM. Why is a good question, but I suspect that it’s more difficult to do some of the cute hacks the IBM-ers do without breaking the programming rules for the Mac (at least I’m finding that a problem in the projects I work on). You can still break the rules if you want to, but be prepared for a customer service headache bigger than the Grand Canyon.