Jun 91 Letters
Volume Number: | | 7
|
Issue Number: | | 6
|
Column Tag: | | Letters
|
Sorry, no Yerk
By Kirk Chase, Editor
Yerk is NOT on Disk
Kirk Chase
MacTutor
Jörg Langowski, in his March column, indicated that the sources for NEON, now public domain and called Yerk, would be put that months source code disk. It did not come in with Mr. Langowskis 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
Bridgeton, MO
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. shouldnt 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
MacTutor
HOTWIRE Labs address was inadvertently left off in the April issue. We regret this sincerely as their hardware debugger, Xtrap, is a great developers product. Their address is
HOTWIRE Labs
8912 Jamesburg
Witchita, KS 67212
(316) 838-8849
AppleLink: D4527
INIT Mr. Bus Error
Tom Nielsen
Recommended Testing
336 Cernon St.
Vacaville, CA 95688
In Februarys issue, Dave Dunham said I dont 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. Dunhams frustration; however, there is a way to continue the programs 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 its in A1, then youd type A1=0;g. Thats it. The program continues as if INIT Mr. Bus Error were not installed. In fact, I type this line so often that Ive 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 MacsBugs prefs file Debugger Prefs (found in the System Folder) which may be found on this months source disk. Pasting these resources into this file and rebooting, adds the clear Mr Bus Error commands to the list of macros.
Macros Meaning Expansion
azg A Zero Go A0=0;g
aog A One Go A1=0;g
abg A Both Go A0=0;A1=0;g
The template for editing these resources should already be in your Debugger Prefs file.-ed and Tom]
More Debugging Tips
Mike Morton
Honolulu, HI
Some comments on Rex Reinharts letter in the March issue:
First, you neednt 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);
}
Dont 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 neednt enter your variables into the Data window in the Think C debugger. Or if you dont 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 dont usually need DebugStr().)
Another trick is the equivalent of Think Cs conditional breakpoints. Suppose you have a loop which is locking up after many iterations. If you press the Interrupt switch, youll 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 youre 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
Editor, MacTutor
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 applications 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 ins and outs 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 DEFs.
And the list goes on and on.
So if you have an elegant solution to a problem, send it in. Youll gain recognition and inspire others.
GUI Wars
XVT Software, Inc.
1800 30th St., Box 17665
Boulder, CO 80308
(303) 443-4223
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 DONT!), 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.