Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!ukma!asuvax!stjhmc!p88.f15.n300.z1.fidonet.org!Lawson.English
From: Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English)
Newsgroups: comp.sys.mac.programmer
Subject: Re: WDEF editor ?
Message-ID: <9563.2820DE7A@stjhmc.fidonet.org>
Date: 1 May 91 18:38:51 GMT
Sender: ufgate@stjhmc.fidonet.org (newsout1.26)
Organization: FidoNet node 1:300/15.88 - Tucson Apple Core, Tucson AZ
Lines: 34

Matthias Ulrich Neeracher writes in a message to All

MUN>Anyway, WDEF and CDEF resources are 100% pure 68000 binary code. 

>>>>      Also what about the same sort of thing for buttons (a la
>>>>Olivers Buttons) and which resource is used for that ?
>> 
>>Maybe the editor could do both.
MUN>  Sure. Any compiler or assembler. Get the picture ? :-

Is there any reason why the Drawing of a button CDEF couldn't be defined using
PICTs? A WDEF as a PICT seems unreasonable, but a drawing program that records
PICTs could have a shell that simply specifies which PICT is drawn for each
CDEF. IE, get a DrawCntl msgCode and use PICT id 3386 for unhilited, 3387 for
hilited, etc.


This would be a generic button CDEF editor. WDEF's might be a bit trickier,
but some enterprising soul could do it: maybe have a default rectangle (or circle
or whatever) that all parts of the WDEF must lie inside of and treat the drawing
and updating, etc. as a series of DrawPict calls... Maybe even irregular regions
could be specified for the frame. A zooming irregular window would be a bit
tricky, but no doubt someone could work it out... Maybe successive calls to
InsetRgn, DrawRgn with XOR could do it for generic irregular windows...

Comments, criticism, flames (lots of those, no doubt!)?


Lawson
 

--  
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org