|
Volume Number: | 6 | |
Issue Number: | 10 | |
Column Tag: | Mousehole Report |
Debuggers and Graphics Rotation
By Larry Nedry, Mousehole BBS
From: Carrel
Re: Standalone source debuggers
Can anyone recommend a good standalone source level debugger to use with code compiled with Think Pascal? I’m tempted to get TMON because it doesn’t cost too much, but I hear that “The Debugger” and MacNosy are much better though they cost a lot more. Any recommendations, personal experiences would be helpful.
From: Mward
Re: Standalone source debuggers
TMON isn’t a source level debugger. On the other hand it’s a whole lot easier to install and use than The Debugger. On the other hand, The Debugger gives you an incredible amount of power and information, and Steve Jasik gives support personally. I would hate to do without either. My normal mode of development is to use TMON and the Think debugger, and to use The Debugger when I come across an interesting problem.
From: Carrel
Re: Standalone source debuggers
How do you like the way The Debugger works with Think? I guess you can’t do source level debugging with The Debugger and Think Pascal since Think doesn’t provide the symbol information?
Thanks for the info about TMON, I hadn’t realized it was not a source level debugger. I guess that means I’d need to know 68000 assembly to use TMON?
From: Mward
Re: Standalone source debuggers
TMON is extremely valuable, though it is not a symbolic debugger. It lets you check the heap, it provides “discipline” (sanity checks on OS calls), does stack crawls, etc,etc,etc. You don’t have to know assembly (though, of course, it helps). The only reason I don’t use The Debugger with Think is because the Think debugger is really easy to use and is usually good enough. The Debugger, in its present incarnation, is not able to display local variables in an easily discernible way.
From: Carrel
Re: Standalone source debuggers
Okay, thanks.I guess maybe I’ll start with TMON and when I feel I’ve reached it’s limits, splurge on The Debugger. I gree that Think’s debugger is quite good, but I’ve run into problems where I need to debug XCMDs and, of course, that’s a little tough with the Think debugger. Thanks again!
From: Ruder
Re: Text Rotation - HELP!
QuickDraw, alas, does not do rotated text! We have hacked a solution in some of our products, but to my knowledge, there is no commonly accessible way to do it. When True Type comes out with System 7 (and even now, using ATM) there will be, I believe, hooks to do stuff like rotated text, but it won’t be built-in, even then. Don’t hold your breath...
From: Tenenbaum
Re: Rotating regions in THINK Pascal
Has anyone figured out how to rotate regions in THINK Pascal. I’d appreciate any help on this.
From: Dirk
Re: Rotating regions in THINK Pascal
I would also be interested in a solution. The only one I know of is to create a offscreen graphport with a bitmap the same size as the region’s bounds box, set the port to this offscreen port, frame the region to the port, do bitmap bit manipulation, and convert the result back to a region via the 32-bit QD BitmapToRegion routine call. The bitmap bit manipulations for rotate, invert, and flip I haven’t done yet, but if I don’t find something quick I will have to roll my own.
[Try looking at the following articles in MacTutor:
“Looking At Text From a Different Angle” by John Olsen, Vol. 4 No. 2. “Faster BitMap Rotation” by Mike Morton, Vol. 4 No. 11.
Also try Mac DTS Sample Code #20 found on the Developer’s CD, AppleLink, and various other sources. -ed]
From: Earthman
Re: color manipulations
I am trying to animate the colors of pict files, I can load them o.k. but when I try to do animate palette no color flux occurs. If i draw anything using Pmforcolor these lines change colors with animate palette calls, but again not the original pict colors. Can anyone point me in the right direction
From: Ruder
Re: Quick CopyBits
Be careful! If you roll your own CopyBits in assembly, better make sure the destination bitmap (and maybe even the source) is not on any screen! IM says you shouldn’t ever write (or read?) directly to (from?) a screen, and hope to remain compatible with future Macs.
From: Nicks
Re: Quick CopyBits
What you say about writing to screen memory is true, as far as it goes, but does not tell the whole story. If you take reasonable precautions about checking the destination memory and the depth of the bitmap and so forth, it is perfectly acceptable to write directly to screen memory. I think that what IM was saying is that you should not assume that screen memory will always be in an absolute physical location; if you make that assumption, then your code will definitely break even on current Macs.
A caveat to the above: The new accelerated display board from Apple (and some other makers, I assume) cache the screen bitmaps in another location in their own ram. If you write directly to screen memory, it will work fine, but the old copy of the screen memory stored elsewhere will not get updated, and the next QuickDraw call that the card intercepts will copy the old image back to the screen, leaving strange artifacts visible. The recommended solution (And Apple said so at the Developer’s Conference) is to do a test of how fast a QuickDraw call is, to determine if an accelerated card is installed. If it is, then don’t write to screen memory, but instead use the Toolbox calls (e.g. CopyBits) to do any graphics operations; with the accelerated card installed, your graphics will be plenty fast enough without any gymnastics.
BTW: The new display cards from Apple also make extensive use of the new gWorld structures in 32-bit QD to cache offscreebitmaps. If you use any offscreen drawing, and want the benefits of the accelerators to work optimally, start using gWorld. (For more info, see Develop, issue #2, or the APDA notes on 32-bit QD)
From: Nicks
Re: Quick CopyBits
Also, there is a new technote out (#277) that describes in depth how to influence the speed of CopyBits. Highly recommended for all pixel mungers.
From: Hweiss
Re: Assembly Language Programming
I would like to learn assembly language to supplement my C programming. However, I have been unable to locate any books that teach assembly language for the Mac. The few that were written are now out of print and unless I can find a copy on the shelf of a bookstore or find someone willing to sell their copy I don’t believe that I will be able to pursue learning assembly.
Dan Weston’s two volume set comes highly recommended, and I have seen two other books by other authors on programming assembly language on the Mac in the back of old books/magazines but have been unable to track them down with the help of a local bookstore. If anyone knows of the location of Dan Weston’s two volume series or is willing to sell me their copies then please reply.
I was initially planning to do some inline assembly with THINK C 4.0.2. I then wanted to use Consulair’s Assembler to generate object files that I could convert to THINK C Libraries (with the RelConv utility) and incorporate them into a project. Has anyone used this technique in their programming and, if so, what is your opinion of the results?
From: Walrus
Re: Assembly Language Programming
Dan Weston’s book is, indeed, probably the best you can get, altho’ it shows its age by what it doesn’t cover (Hey, Dan, what about volume 3??!!!). Best of all, it is still very much in print, although, in most parts of the country you will probably have to special order it, but you could try a large college bookstore--they might just have it. I believe the publisher is Scott, Foresman and Co. [That is correct. -ed]
I bought a Hayden (the publisher) book called “Assembly Language with MPW” or some such title. It was very disappointing, partly because the way it stores the QD globals IS NOT the way MPW wants it.
I hope this helps.
From: Noisy
Re: Assembly Language Programming
I have a slightly tattered copy of “Assembly Language Programming for the Macintosh” once published by Sybex. It was outdated with the release of the 256K ROMs, but is an excellent ‘novice’ book nonetheless.
From: Atom
Re: clobbering SANE
I’m trying to track down a weird bug in a MacApp program I’ve written whose main symptom is that Num2Str (the SANE conversion routine) frequently returns junk even though it’s given reasonable parameters. When debugging, crashes into the MacApp debugger with “Alleged heap header is invalid” messages are also common. Obviously I’m clobbering something but I can’t figure out how. I’ve carefully modified my code line by line trying to troubleshoot this, but the only thing that makes any difference is whether the command that malfunctions (which is initiated by a mouse click) is actually returned from DoMouseCommand, in which case the problem shows up, or is posted with gApplication.PostCommand, in which case everything works fine. This makes no sense to me. Does anyone have a clue as to what’s going on? Someone please help.
From: Lecroy
Re: clobbering SANE
From your description, it sounds like maybe you aren’t passing back a return value in the DoMouseCommand function. You should at least set the return value to NIL (or gNoChanges). If this isn’t the case, upload the code and maybe myself or someone can tell you what they think...
From: Atom
Re: clobbering SANE
Thanks for replying. As it turns out I found my mistake. I was passing the EXTENDED field of an object directly to Num2Str. Although it’s not a VAR parameter, Pascal callers treat EXTENDED parameters exactly as if they were VAR. I never knew that. My problem must have been caused by the Memory Manager moving the object while loading the SANE segment. Evidently you should never pass object fields over 4 bytes long as parameters, even non-VAR ones, unless you’re absolutely certain nothing in memory will move. An expensive lesson for me as I’d been doing this all over the place, but that’s life.
From: Thehulk
Re: Think C Help?
I think (no pun intended) that the problem people have in getting into any OOPs environment and using it is that they won’t let go. What I mean is that it is really hard to believe that the OOPs environment really is doing it all for you and the things that you used to have to worry about you no longer have to worry about as they are really taken care of for you. It is really a matter of letting go. I recommend that you get a copy of the latest (and so far the greatest) book on C++ programming for the Mac which is (drum roll please) Elements of C++ Programming by Dan Weston and published by Addison-Wesley. This book concerns itself with MPW C++ but you can get a general idea about Think C 4.0 and how things work from it. I went through a number of examples (posted on this BBS) of simpler example source written in Think C 4.0 and got the ‘hang’ of it. I now use Think C some of the time but still use MPW C++ alot. I prototype quickly in Think C. If anyone would like to talk to me personally about all this send me some private E-Mail with your phone number and
I’ll get in touch with you. It’s really not that hard.
From: Atom
Re: Think C Help?
The stumbling blocks with OOP probably vary from person to person. My biggest problem has always been designing my classes strategically, so that adding features to my app doesn’t force me to completely overhaul my code. I still haven’t gotten the hang of it entirely after over a year, though I’m getting better (I think). Especially (but not only) with OOP, it really pays to think first, code later.
From: Thomas
Re: Hierarchical Menus in MacApp
I’m new to MacApp and would like to create a hierarchical menu. How do I do this? Does anyone out there know? I look forward to hearing from you.
From: Atom
Re: Hierarchical Menus in MacApp
While I’ve never tried this myself, I gather that creating hierarchical menus with MacApp is almost exactly the same as without, except you’re using ‘cmnu’ resources instead of ‘MENU’ ones. Also, you need a ‘MBAR’ with ID=130 listing the hierarchical submenus. The DemoText example program that comes with MacApp (with v2.0 anyway) shows you how to do this, and the MBAR 130 resource is mentioned (all too briefly, I’m afraid) in the MacApp Resources chapter of the General Reference. BTW, the example programs are really worth checking out.
There’s a lot of stuff in them that they just don’t tell you in the manuals.
From: Rush
Re: Greying out popup menus
I need to be able to “grey out”, i.e. disable, a popup menu on one of my dialog. What I would like is for both the popup title and the popup item currently showing to be greyed out. DisableItem only greys out the items when pressed; ideally the user should know that they can’t currently use the popup menu. I guess what I really need to know is how DisableItem greys out text. And no, I haven’t bought Inside Mac (except for V5)--at least not yet.
From: Frankh
Re: Wierd Finder Problem
I spoke too soon; while BundAid fixed my problem with ResEdit resource files not being able to find ResEdit when i double clicked on them, now I have the same problem with AppMaker. When I double click on AppMaker generated files, I get the “application busy/not found” message. I’ve tried everything: rebuilding the desktop, running BundAid, removing all INITs, MacsBugs, etc. Run under Multifinder, under Finder, checked for viruses, checked for corrupted files on the HD, replaced AppMaker, etc. One wierd thing is that when I do a Get Info on the AppMaker file, instead of saying “Kind: AppMaker document” all it says in the kind box is “document”. Where does the Finder get this info from? I also checked, and the AppMaker file creator IS the same as the AppMaker application. I’m running a 5 meg Mac II and system 6.04; I tried it on the two Macs at work, and I have the same problem there. The only way I can get it to work is if I open the AppMaker application’s folder so that the Finder “sees” it; then I can double click on the file, and the app will launch; but this only works once - I have to “hide” the app again, then bring it to the front to repeat the trick. Any ideas of what’s going on?
From: Frankh
Re: Fixed the wierd finder problem
Finally! I figured out what was going on with my machine. Apparently, when I ran BundAid to fix the problem I was having with launching ResEdit generated files, it saw that AppMaker generated files had a BNDL resource...so it went ahead and set the bundle bit. Unfortunately, AppMaker files are just collections of resources, and the Finder was getting confused (I imagine it was trying to launch the AppMaker data file itself).
The solution is simple: I cleared the bundle bit, AND rebuilt the desktop. All is well now!
From: Rino
Re: ResEdit Custom Editors
I would like to write an Editor to be added to ResEdit. The Feb-90 issue of MacTutor addressed the issue but only by using MPW. Has anyone tried this using Think C ??? I am in the process of getting the ResEdit extension package from Apple but I doubt that it will address Think C. Any suggestions where to start looking??
From: Dionh
Re: Externals for 4D
I’m trying to write a 4th Dimension external is Think C (v4.0) that performs a specialized string function. The problem is that I cannot seem to return the processed string back to 4D. I am passing the address of the processed string via the stack when I return but 4D does not seem to pick it up. When I installed the routine using 4D Mover I set my external up as a function, but with no results. Does anyone out there know about external programming to give me a hand?
From: Will
Re: graf3d
Can anyone help me with a simple demo program on how to set up a graf3d world and draw into it? I’m working in MPW C and would really like to see how this can be done. I’ve given up on the MPW manual as it doesn’t seem to give enough info on the matter. Thanks!
From: Papaya
Re: Mac II SuperDrive Problem
Aloha from Hawaii - gotta problem w/ my Mac II SuperDrive when it attempts to write a DOS text file on a DOS diskette: although it worked fine for almost a year, in the last 2 months it has written files which PC/DOS machines interpret as corrupted diskettes and FAT directory structures. My local tech repair guy swapped out the FDHD drive but the same problem still occurs. I can read DOS files into the Mac with no problem. But I cannot transfer a file out onto a DOS diskette!! Even SoftPC 1.3 used to work and now does not - it writes the file but PC machines cannot read the file! Where else could the problem lie? {Apple File Exchange version is 1.1 But SoftPC 1.3 is current. Help!!
From: Ears
Re: Mac II SuperDrive Problem
I would be interested in hearing how the problem was solved. One question that comes to my mind is “have you changed your system from 6.0.4 to 6.0.5? are you running Multifinder 6.1b9 (SADE Multifinder), have you installed any new init recently? Aaaa ya I know that’s more than one question but what are you doing differently - system and such than you did two months ago.
From: Derek
Re: Marcos
Looking for a good macro program for my Mac II.
Quickkeys slows down the system too much and Macro Maker crashes on my system, so what other macro programs are out there? I just want something simple that I can use my Function Keys.
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine