ADVERTISEMENT

Sorry, no Yerk

By Kirk Chase, Editor

Yerk is NOT on Disk

Kirk Chase

Jörg Langowski, in his March column, indicated that the sources for NEON, now public domain and called “Yerk”, would be put that month’s source code disk. It did not come in with Mr. Langowski’s materials, but we have obtained it. Unfortunately, Yerk is much to large, even after compression to place on anything but a high density floppy. Therefore, Yerk will NOT be distributed on the source code disk. We obtained it on America OnLine. Other BBS and on-line services should be carrying Yerk also. We are sorry that we are not able to distribute it to you.

Animated Cursor Corrections

Rich Lesh

In my March ’91 article “Animated Color Cursors,” I mentioned that you must be careful to avoid re-entrant conditions with the SetCursor() calls.

Sometimes this is difficult even in the most well behaved programs. I was informed by a reader, Joe Schwartz, that Apple has posted a tidbit of information that can solve this problem. According to the Q&A Stack that Apple distributes, there is a low memory byte, CrsrBusy at 0x8CD, that indicates whether or not the cursor is currently busy, i.e. shouldn’t be changed. The following correction to the code published in March makes use of this global to prevent any calls to SetCursor() when the cursor is busy.

This prevents any cursor fragments from appearing on the screen.

/* 1 */

static pascal void SpinCursorTask()
{
    long oldA5;
 
    oldA5=SetCurrentA5();
    gCursorTask->vblCount=gSpeed;
    if (gSpinCycles && !(*(Byte*)0x8cd)){
        gSpinCycles--;
        (*gCurrentHdl)->index++;
        (*gCurrentHdl)->index%=(*gCurrentHdl)->n;
        if (gColorCursor){
            SetCCursor((*gCurrentHdl)->frame[(*gCurrentHdl)->index].cursorHdl);
        }else{
            SetCursor(*(*gCurrentHdl)->frame[(*gCurrentHdl)->index].cursorHdl);
        }
    }
    SetA5(oldA5);
}

HOTWIRE Labs Address

Kirk Chase

HOTWIRE Labs’ address was inadvertently left off in the April issue. We regret this sincerely as their hardware debugger, Xtrap, is a great developer’s product. Their address is

HOTWIRE Labs

8912 Jamesburg

Witchita, KS 67212

(316) 838-8849

AppleLink: D4527

INIT Mr. Bus Error

Tom Nielsen

In February’s issue, Dave Dunham said “I don’t like them (programs) generating bus errors, having to reboot without Mr. Bus Error and rerunning the programs”. Being a programmer and tester myself, I can understand Mr. Dunham’s frustration; however, there is a way to continue the program’s execution as if INIT Mr. Bus Error were not installed.

In MacsBug, examine the registers on the left looking for the characteristic 00F0F0F1 that INIT Mr. Bus Error uses. (Note: Sometimes the register is 00F0F0Fx, where x is some number besides 1. This happens when the application uses the handle as a handle to an array or string). If this value is in register A0, then you would type “A0=0;g.” If it’s in A1, then you’d type “A1=0;g.” That’s it. The program continues as if INIT Mr. Bus Error were not installed. In fact, I type this line so often that I’ve created MacsBug macros to do it for me. These macros clear out register A0, A1 or both and then continue.

[Tom has included three resources that can be added to MacsBug’s prefs file “Debugger Prefs” (found in the System Folder) which may be found on this month’s source disk. Pasting these resources into this file and rebooting, adds the clear Mr Bus Error commands to the list of macros.

More Debugging Tips

Mike Morton

Some comments on Rex Reinhart’s letter in the March issue:

First, you needn’t use “asm” to drop into the debugger. Think C has a Debugger() trap defined for you, so just put this line in your source:

/* 2 */

Debugger(); /* invoke debugger */

An equally useful trap is the DebugStr(), which takes a single Pascal-string argument. You can “print” simple messages with:

/* 3 */

DebugStr(“\phello, world!”);

or you can print out more useful information to print variables or other values:

/* 4 */

{
 char tempBuf[100];
 sprintf(tempBuf, “x is %d”, x);
 CtoPstr(tempBuf);
 DebugStr(tempBuf);
}

Don’t forget the CtoPstr() call to convert the string from C to Pascal format.

An advantage of this kind of output is that during repeated debugging sessions you needn’t enter your variables into the Data window in the Think C debugger. Or if you don’t have the memory for the debugger, or are debugging a standalone application, this stuff is handy. (of course, if you have a text window for debugging output, you don’t usually need DebugStr().)

Another trick is the equivalent of Think C’s conditional breakpoints. Suppose you have a loop which is locking up after many iterations. If you press the Interrupt switch, you’ll get Macsbug or TMON, not the Think C debugger. Instead, put this line anywhere in the loop:

/* 5 */

if (optionKeyDown()) DeBugger();

(Here, optionKeyDown() is some function you write which tests for the option key.) Run your application until it seems to hang up, then hold down the option key-now you’re in the Think C debugger.

Lastly, be sure to remove all these calls before you distribute your application!

[Still, Think C would definitely be friendlier if its debugger were more like Think Pascal. I feel something like selecting a variable and the a menu command to examine its contents would be nice. I suppose something a little more interactive than DebugStr().-ed]

Call For Articles

Kirk Chase

Every so often (about five or six times a day), I am asked what I would like to see in the way of articles for MacTutor. At that time, I pull out my editorial calendar (which is scribbled on with a multitude of changes) to read off some of the upcoming topics. Here are a number of requests from readers:

• Programming for modules. This would include such things as given the application’s working directory, a folder name of where the modules are located, and a filter proc, return a path (or directory) and list of filtered files to be used later. Also, we have had articles on external functions/modules in January and February of 1990, but one on file format filters would also be nice.

• Dialog enhancements such as a preview picture.

• A great article or two on the in’s and out’s of the File Manager, Resource Manager, Finder information and MultiFinder information (such as proper use of the SCC ports).

• System 7 quirks, tips and discussions.

• 32-bit QuickDraw, animation (B&W/Color), sound.

• Networking/Groupware articles.

• Neat DEF’s.

And the list goes on and on.

So if you have an elegant solution to a problem, send it in. You’ll gain recognition and inspire others.

GUI Wars

XVT Software, Inc.

One way to reach a bigger market for your product is to publish it on multiple platforms. This is called, “cross development”. This has been growing steadily for the past few years. Even on the Macintosh, there are different platforms such as A/UX to develope for.

The problem with cross development is differing machine architectures and user interfaces. You can reuse some of your code, but it is hard to separate the Mac Toolbox from your code; this makes it difficult to port your code over. You could go to the lowest level of character I/O (PLEASE DON’T!), but that is not why you got started on the Macintosh. You could even rewrite everything from scratch.

Another solution offers an elegant way to port your graphical program over to another windowing environment. Enter XVT, or the Extensible Virtual Toolkit, from XVT Software Inc. With XVT, you can obtain GUI portability. Now you can develope C/C++ code for THINK or MPW. Then, you take that same source over to your other platform environment and compile without a whole lot of changes.

There is a down side to this GUI solution. The first is the cost factor; each library for a particular platform costs about $800; to get the source it is around $5000; also a license is required for distribution. This price does include an annual technical support and update program.

The second problem and third problem are speed degradation and capability limitations. These problems are only natural. One would expect a slight slow down in execution speed because of the higher-level calls. Also, some features beyond the normal ones are not implemented due to the need for cross compatibility.

Still, these factors are probably not large when faced with the potential savings in time/resources and potential gains in new markets. I know now that AppMaker now generates code for XVT. This makes development time go down dramatically. Imagine using AppMaker to get the user interface down, and then generating code that is cross compatible. I imagine dollar signs.