Mousehole Report

By Rusty Hodge & Larry Nedry, Mousehole BBS

The MouseHole has moved to Cupertino, CA, the home of Apple Computer. The MouseHole BBS and the MouseHole Download BBS have merged to provide a more complete, one stop technical BBS for the MacIntosh community. We currently have 4 telephone lines and will expand to meet demand. With the new software we now have E-Mail, Special Interest Groups, Teleconferencing and a file download section.

To join the MouseHole just call (408) 738-5791 with your favorite telecommunications program and type ‘new’ at the logon prompt. You can get help at anytime while online by typing a ‘?’.

From: Sysop

Re: The MouseHole is back

Sorry, we were gone for so long. The MouseHole is now running here in Cupertino, CA with a new sysop, Larry Nedry. He has been the sysop for the MouseHole Download since 1984 and a co-sysop on the MouseHole.

From: Rguerra

Re: FINDER QUESTION

Does anyone have any idea as to how the Finder places icons in its windows? I know about the FinderInfo fields returned by the PBGetCatInfo call, but what coordinate system is being used? The Finder does a SetOrigin on each of its windows so the coordinate system is somewhat odd. The POINT coordinates in the FInfo record very often will NOT correspond to a point in the visible window even though I can see the icon. Also, does anyone have any information on how the Finder keeps track of the files in each of the windows and how it determines which icons are selected and are to be opened by a double-click or an “Open” menu. I know this is all undocumented but I’d very much like to know how this works. Thanks!

Rich

From: Orourke

Re: SE/30 DISK ERRORS

Has anyone had any problems with the New drives in the SE30? I have had several disk fail to initialize (Sony and Maxell). Also I know of another new owner who has had similar problems.(Fuji disks) Hope this isn’t a pattern.

From: Spud

Re: MultiFinder bug???

I have noticed that when calling an alert in the background under MultiFinder, the alert does not re-draw correctly. I have noticed this in many commercial apps, as well as my own. Here’s the sequence of events:

1) Write an app that waits 5 seconds, and then puts up an alert. ProtoTyper, no problem.

2) Run the app. Within those 5 seconds, switch into another application whose window covers all others.

3) Okay, 5 seconds are up, so switch back into your original program. Notice that the icon and the alert’s bold item are not drawn.

Is this a bug in MultiFinder, or am I just seeing things? If it is a bug, then how can I program around such a dilemma?

Thanx in advance,

-Spud

From: Rdclark

Re: MultiFinder bug???

Spud,

Basically, background applications shouldn’t be putting up alerts -- that is the privilege of the foreground application. You should use the Notification Manager instead, (which can put up an alert in front of the frontmost application if you really have to.)

The Dialog Manager assumes (correctly) that modal dialogs (and alerts) will always be the frontmost window, and so have no redrawing code.

...Richard

From: Rguerra

Re: Dialog Redrawing

Ah, but that doesn’t mean that modal dialogs shouldn’t have redrawing code! What about the case when a modal dialog is in front and a screensaver kicks in? If you don’t handle the update event, the user is left with a blank dialog except for whatever buttons, etc. that were part of the DITL item list. If you need to draw frames, outline buttons, etc. you can either add a UserItem to the DITL (a custom drawing routine) or handle updates in a dialog filter proc that you pass to ModalDialog. I agree about using the Notification Manager from the background. You might want to make sure your program is MultiFinder-Aware and keep track of whether you’re in the foreground or background and call your normal dialog in the foreground and the Notification Manager dialog in the background or else do nothing until the user brings you to the foreground again.

Rich

From: Rdclark

Re: Dialog Redrawing

Ah, but that doesn’t mean that modal dialogs shouldn’t have redrawing code! I agree -- but who’s going to write the ROM patches to do it <grin>? Really, you have to assume that a modal dialog will be responded to immediately, and that your screen saver probably won’t have the chance to kick in. (By the way, there is _limited_ redrawing code for alerts, since your button’s contents and any static text will be redrawn...just not the icon or the outline around the button.)

...Richard

From: Lcoon

Re: Font utility

I’m looking for a utility which will display samples of all fonts loaded on the computer. I’ve got a few hundred fonts available, and I don’t want to print samples of each one. Anybody know of any such utility?

From: Rdclark

Re: Font utility

Tell me more about what you want it to do, and I should be able to modify some demonstration code that I’ve already written. OK?

...Richard

From: Lcoon

Re: Font utility

I have about three hundred fonts sitting around, and I want to have printed samples of each one available so I can find the font I want to use easily. It doesn’t have to be much, just a line of text for each font.

Thanks.........Larry

From: Rdclark

Re: Font utility

No, Suitcase won’t print all of your installed fonts...it will only show them on screen. (Unless you want to use command-shift-3 to take a snapshot of each of Suitcase’s displays...)

...Richard

From: Mark Worthington, Worcester, MA

Subject: XCMD intercepting mouseUp

I have written an XCMD which is called within a mouseDown handler in a HyperCard script, which tracks the mouse until it is released. No problem. Recently I decided to allow the user of the XCMD to be able to specify a parameter by which he could choose to have the XCMD intercept the inevitable subsequent mouseUp event, or let nature take its course and have HyperCard receive the event and do with it whatever it was supposed to. I therefore put a GetNextEvent loop at the end of my XCMD, expecting this would intercept one mouseUp event and then exit the XCMD. But it doesn’t intercept the mouseUp at all. I have added several diagnostic lines of code and found that the loop really is not finding a mouseup. I gave the loop 10 seconds to receive such an event. I also put a mouseUp handler in the button to beep 5 times. Lo and behold, when the 10 seconds had elapsed, the button beeped 5 times, and my diagnotics reported no mouseUp was detected by the XCMD. Now I know HyperCard 1.2.2 is supposed to change HyperCard’s habit of sending itself a mouseUp message *before* removing the mouseUp event from the queue (oh, yes. I am using HC 1.2.1), but that doesn’t seem to be the problem. What is HyperCard doing to me, and how? Would using WaitNextEvent make any difference, and if so, why? Please help. Thanks so much.

From: thecloud (Ken Mcleod, La Habra, CA)

Subject: trouble intercepting mouseUp

You might try setting the system event mask to enable mouseUp events yourself (using SetEventMask()...see the Toolbox Event & OS Event chapters of IM), since it sounds like HyperCard is disabling mouseUp events before calling your XCMD. Alternatively, you might want to try calling GetOSEvent() instead of GetNextEvent(), since the system can intercept events gotten with GetNextEvent() before your code ever sees them.

Somebody more familiar with HyperCard should be able to give you a better answer (or else an ‘official’ one); in the meantime, hope this proves helpful.

From: macww (Mark Worthington, )

Subject: trouble intercepting mouseUp

Ken, Thanks for the reply. I’ll try your ideas. In the meantime, if anybody else has more specific knowledge of what HyperCard is doing, or where else I might find out, I would appreciate it. Even if one of Ken’s suggestions works, it is always unsatisfying to “fix” something without understanding what got “fixed.” Thanks again, Ken.