gerhard@cs.arizona.edu (Gerhard Mehldau) (01/11/90)
I have two (unrelated) problems that I hope someone out there
can help me solve:
(1) I'm trying to use the same DLOG/DITL resource for several
related dialogs. This requires that a button be shifted
slightly before the dialog is displayed. I'm calling
GetNewDialog(...) to read in the resources, then
GetDItem(...) to get the button's handle and
MoveControl(...) to move the button, and finally
ShowWindow(...) to display the dialog. The button
is drawn in the correct location, but when I do a
ModalDialog(NULL,...) and try to click on the button,
the Dialog Manager only reacts if the mouse is in the
*intersection* of the old and new rectangles. What
am I doing wrong?
(2) I would like to print the contents of a CGrafPort by
using CopyBits(). However, IM-II has the printer
grafport's pixels defined as a bitmap, rather than a
pixmap, and I couldn't find an update on this in IM-V.
So, how do I go about this? Any ideas?
Any help would be greatly appreciated!
- Gerhard
--
-> Gerhard Mehldau
Dept. of Computer Science internet: gerhard@cs.arizona.edu
University of Arizona uucp: {cmcl2,noao,uunet}!arizona!gerhard
Tucson, AZ 85721, U.S.A. at&t: +1 (602) 621-4632olson@bootsie.UUCP (Eric Olson) (01/12/90)
In article <16747@megaron.cs.arizona.edu> gerhard@cs.arizona.edu (Gerhard Mehldau) writes: >(2) I would like to print the contents of a CGrafPort by > using CopyBits(). However, IM-II has the printer > grafport's pixels defined as a bitmap, rather than a > pixmap, and I couldn't find an update on this in IM-V. > So, how do I go about this? Any ideas? > I believe that the 6.0 version of the Laserwriter/LaserPrep (and perhaps other print drivers) open a CGrafPort and correctly image Greyscale data. I don't have release versions of these, but they came with either some 6.0.x update or the 32-Bit Quickdraw release. -Eric -- Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
bochner@speed.harvard.edu (Harry Bochner) (01/13/90)
In article <16747@megaron.cs.arizona.edu> gerhard@cs.arizona.edu (Gerhard Mehldau) writes:
(1) I'm trying to use the same DLOG/DITL resource for several
related dialogs. This requires that a button be shifted
slightly before the dialog is displayed. I'm calling
GetNewDialog(...) to read in the resources, then
GetDItem(...) to get the button's handle and
MoveControl(...) to move the button, and finally
ShowWindow(...) to display the dialog. The button
is drawn in the correct location, but when I do a
ModalDialog(NULL,...) and try to click on the button,
the Dialog Manager only reacts if the mouse is in the
*intersection* of the old and new rectangles. What
am I doing wrong?
Seems to me that you're effectively going behind the Dialog Manager back
by calling MoveControl yourself, and that's why it's confused. I don't
have IM in front of me, but I think you should be able to modify the
rect returned by GetDItem, and pass it back via SetDItem, letting the
Dialog Manager call MoveControl itself. Then its idea of where the
button is won't be out of date.
Harry Bochner
bochner@endor.harvard.edupem@cadnetix.COM (Paul Meyer) (01/13/90)
In article <16747@megaron.cs.arizona.edu> gerhard@cs.arizona.edu (Gerhard Mehldau) writes: >I have two (unrelated) problems that I hope someone out there >can help me solve: > >(1) I'm trying to use the same DLOG/DITL resource for several > related dialogs. This requires that a button be shifted > slightly before the dialog is displayed. I'm calling > GetNewDialog(...) to read in the resources, then > GetDItem(...) to get the button's handle and > MoveControl(...) to move the button, and finally > ShowWindow(...) to display the dialog. The button > is drawn in the correct location, but when I do a > ModalDialog(NULL,...) and try to click on the button, > the Dialog Manager only reacts if the mouse is in the > *intersection* of the old and new rectangles. What > am I doing wrong? This is because you are only changing the position of the control, not the rectangle of the controlItem. The Dialog Manager keeps track of the rectangles of all the stuff in the dialog and does hit-checking of enabled items. If the item is a control, it passes the mouse event on to the Control Manager to process. You need to add one more call to your sequence: GetNewDialog GetDItem MoveControl SetDItem (OffsetRect the Rect you got from GetDItem the same amount you moved the control in MoveControl) ShowWindow, etc. Similar problems can occur when you change the hilighting of a control and don't change the corresponding DItem enabled status--I suspect that leaving a grayed-out control enabled would do the right thing (since you can click on a control then drag out of it and the Dialog Manager won't call that an item hit), but if you un-gray a control without re-enabling it as a dialog item the mouse hit will never be passed on to it. Paul Meyer pem@cadnetix.COM Daisy/Cadnetix Inc. (DAZIX) {uunet,boulder}!cadnetix!pem 5775 Flatirons Pkwy. GEnie P.MEYER CI$ 73627,1274 Boulder, CO 80301 (303)444-8075x277
Andrew.Lindsey@f563.n107.z1.FIDONET.ORG (Andrew Lindsey) (03/13/90)
As part of a project I am working on, I am trying to write an INIT which will put a program in memory which the user can call up at any time by clicking on an icon on the menu bar. I have seen this kind of thing done before, but I can't figure out just how to do it! Does anyone have any suggestions? -- Andrew Lindsey via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!107!563!Andrew.Lindsey INET: Andrew.Lindsey@f563.n107.z1.FIDONET.ORG
rcfische@polyslo.CalPoly.EDU (Raymond C. Fischer) (03/15/90)
In article <45183.25FD20CE@cmhgate.FIDONET.ORG> Andrew.Lindsey@f563.n107.z1.FIDONET.ORG (Andrew Lindsey) writes: >As part of a project I am working on, I am trying to write an INIT which >will put a program in memory which the user can call up at any time by >clicking on an icon on the menu bar. I have seen this kind of thing done >before, but I can't figure out just how to do it! Does anyone have any >suggestions? INITs are code resources that are loaded into memory _once_ during startup and executed. Most INITs make some changes to the Mac and install some of their own code as part of the startup so that they can get control later and do some nifty stuff. In the INIT I wrote, I had it load code into the system heap and patched a couple traps so that the code would execute later. In your case, you need to figure out how to keep the icon displayed in the menu, even when the menu gets re-drawn. Then you might want to look at hooking into GetNextEvent so that you can intercept mouse downs and see if they're on your icon. Once you know how to do this, write code to handle the events, then write an INIT to install your code someplace and viola! Simple, eh? What you're proposing is not simple Mac programming; applications are easier. Look at the manuals for your development system for guidance on writing code resources. Alternatively, read up on MultiFinder and see if what you want to do is possible with an ordinary application. Ray Fischer rcfische@polyslo.calpoly.edu
chaffee@reed.UUCP (Alex Chaffee) (03/20/90)
In article <25ff4e70.643e@polyslo.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU
<INITs are code resources that are loaded into memory _once_ during
<startup and executed. Most INITs make some changes to the Mac and
<install some of their own code as part of the startup so that they
<can get control later and do some nifty stuff.
...
<in the menu, even when the menu gets re-drawn. Then you might want
<to look at hooking into GetNextEvent so that you can intercept mouse
<downs and see if they're on your icon.
A small suggestion - rather than patching GetNextEvent, take advantage of
the low-memory global jGNEFilter, which is sort of a built-in tail patch on
GNE. It's documeted in a tech note (I can't remember the number); I could
give you source code if you're interested.
<Ray Fischer
<rcfische@polyslo.calpoly.edu
--
Alex Chaffee
chaffee@reed.UUCP
Reed College, Portland OR 97202
____________________cak3g@astsun7.astro.Virginia.EDU (Colin Klipsch) (03/21/90)
In article <14463@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >In article <25ff4e70.643e@polyslo.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU ><in the menu, even when the menu gets re-drawn. Then you might want ><to look at hooking into GetNextEvent so that you can intercept mouse ><downs and see if they're on your icon. > >A small suggestion - rather than patching GetNextEvent, take advantage of >the low-memory global jGNEFilter, which is sort of a built-in tail patch on >GNE. It's documeted in a tech note (I can't remember the number); I could >give you source code if you're interested. > ><Ray Fischer ><rcfische@polyslo.calpoly.edu >-- >Alex Chaffee >chaffee@reed.UUCP >Reed College, Portland OR 97202 >____________________ Tech Note #85 talks about jGNEFilter. It is a low-memory global which points to code that will be executed upon every event, after the Mac has done some of its own processing. I used to use this method of event filtering for TappyType, and it worked as follows. . . In your INIT: - Load your event-filter code, presumably stored as another resource, into the system heap. - Make sure it's locked. (i.e. set its resLocked bit beforehand) - Detach it with _DetachResource. - Take the whatever pointer you find in jGNEfilter and store it somewhere safe in your event-filter. - Store the address of your event-filter in jGNEfilter. Now every time an event happens, your event-filter (tucked safely inside the system heap) will be called. Hopefully. In your event-filter: - Upon entry, A1 should point to the event record. Do whatever you want to do with the event. - After you've done your thing, jump to the old value of jGNEfilter that you saved previously. In effect, you are "splicing" your event-filter into the flow of event processing. If everyone were to do the same thing, then many different event filters could co-exist. Two Bad Things: Unfortunately, not everyone plays nicely, and thus it may matter when your INIT runs in relation to others. Secondly, jGNEfilter is a low memory global, and thus it is not guaranteed to be around in the long run. Patching GetNextEvent, as a method of event filtering, won't work except as a tail patch, which is a Thing Not To Be Done. The scheme I use now is head-patching SystemEvent, which also seems to be called after every event. SystemEvent is "guaranteed" to be supported, and you don't have to share a precarious memory global with random strangers. ---------------------------------------------------------------------- "May the forces of evil become confused on the way to your house." -- George Carlin \ / Bemusedly, | DISCLAIMER: Colin Klipsch | This text is actually a horrendously UVA Astronomy Department | garbled excerpt from _Mating_Rituals_ Charlottesville, Virginia | of_West_African_Ostriches_, Vol IV, cak3g@virginia.edu | by Davis & Griffin, 1913, pp. 134-135 ____________________________/ \_______________________________________
rrkasegu@athena.mit.edu (Rick R. Kaseguma) (03/21/90)
It all started with a request for ideas of how to draw an icon in the menubar which causes an action when clicked (probably like OnCue). Then... In article <25ff4e70.643e@polyslo.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU wrote: >...in the menu, even when the menu gets re-drawn. Then you might want >to look at hooking into GetNextEvent so that you can intercept mouse >downs and see if they're on your icon.... In article <14463@reed.UUCP> chaffee@reed.UUCP (Alex Chaffee) writes: >...A small suggestion - rather than patching GetNextEvent, take advantage of >the low-memory global jGNEFilter, which is sort of a built-in tail patch on >GNE. It's documeted in a tech note (I can't remember the number); I could >give you source code if you're interested... In article <2735@hudson.acc.virginia.edu> cak3g@astsun7.astro.Virginia.EDU (Colin Klipsch) writes make very useful comments on patching GNE, including: >...Patching GetNextEvent, as a method of event filtering, won't work >except as a tail patch, which is a Thing Not To Be Done. > >The scheme I use now is head-patching SystemEvent, which also seems to be >called after every event. SystemEvent is "guaranteed" to be supported, >and you don't have to share a precarious memory global with random >strangers... Wait! Why don't you just head patch MenuSelect? The point where the user clicked will be on the stack, and you won't be slowing everyone down by checking every single event. MenuSelect is called regardless of where you click in the menubar, and you can just drop through to the existing MenuSelect handler if the point is not in your icon's rectangle. You still have to worry about your A5 world, etc., but this seems like a much cleaner solution. Just an idea. Rick Kaseguma, Macintosh Programmer/Consultant/Bartender rrkasegu@athena.mit.edu (ARPA internet) 474 Memorial Drive, Cambridge, Massachusetts 02139 (617) 494-1286 (voice), (617) 225-7568 (voice/modem/fax)
lsr@Apple.COM (Larry Rosenstein) (03/21/90)
In article <1990Mar21.000232.18637@athena.mit.edu> rrkasegu@athena.mit.edu (Rick R. Kaseguma) writes: > Wait! Why don't you just head patch MenuSelect? The point where the > user clicked will be on the stack, and you won't be slowing everyone down This would be the right solution, except that there are programs out there that pass the address of the mouse point instead of the point itself. (The reason the Menu Manager works is that it immediately enters its loop tracking the mouse and quickly gets the correct coordinate.) So if you do patch MenuSelect, you should independently get the mouse position, and not rely on the validity of the parameter passed to MenuSelect. The next question is how to get the mouse position. You can call GetMouse, but you have to realize that this converts the global position into a local coordinate. In my ApplicationMenu init, I used to call OSEventAvail, since it fills in the event record with the current global mouse position. Unfortunately, this caused an incompatibility (at one point) with QUED/M. (Apparently they patch MenuSelect and one of these traps, and their patches weren't reentrant.) Now I simply access the Mouse low memory global. (I'm so embarrassed! :-) Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
wolf@mel.cipl.uiowa (07/13/90)
I am programming in Turbo Pascal for the Mac (I know its ancient, but I can't afford any of the new packages). Well, I have this program which is somewhat large and when I tried to compile it to memory or check sytax it gives me a segment to large error. So I tried compiling it on a machine with more memory and it seemed to work, so I bought more memory. Then I added a little more to it and now it won't compile to memory again. The same error comes up. When I compile it to disk it doesn't get the error at that time. Any clues as to get around this or what the problem is? I have and SE with 2.5M RAM. Thanks. WOLF@MEL.CIPL.UIOWA.EDU
islam1@husc9.harvard.edu (Shujaat Islam) (12/08/90)
I've been working on and programming the mac for some time, but I'm new to the networking and BBS world. I would like to know how I can download freeware/shareware programs from computers on the network (I heard that some computer at Stanford has a good collection). I've picked up pieces here in there about FTP's and BinHex and so on, but would really appreciate a coherent summary of the procedure involved. Thanks in advance. Please post info on the news system or e-mail to: islam1@husc9.harvard.edu