[net.micro.mac] Creating Resources: ResEdit or RMaker?

davidl@teklds.UUCP (David Levine) (02/04/86)

In article <492@lzaz.UUCP> mkg@lzaz.UUCP (Marsh Gosnell) writes:
>                                  ... I tried to make a .r file and compile
>it with Rmaker but I kept crashing when I tried to view or edit at the
>dialog with ResEdit (1.0D4).  I finally gave up on Rmaker and used ResEdit
>to cut the "standard" DLOG and DITL resources out of the system and add on
>my own new items.  This works just fine.
>    Marsh Gosnell   ihnp4!lzma!mkg

This brings up a question I've been wondering about for a while.  The looseleaf
Inside Macintosh says in many places that resources should be created and
edited "with the Resource Editor *** (for now, use the Resource Compiler) ***".
I haven't checked the paperback edition on this, but what I'd like to know is:

	Should resources be created with ResEdit or RMaker?

The way I see it, either RMaker was intended as just a stopgap until a 
bug-free Resource Editor is available, or the Resource Editor is a tool for 
hackers (like directly patching object code with adb) and RMaker should be 
used for "source-code" portability.  

The advantage of ResEdit is its interactive, visual editing capability.
The advantages of RMaker are that .r files can be mailed and printed easily,
and that it works better with compilers (especially with batch or shell 
scripts) in combining resources with (freshly-compiled) code.

Obviously, both methods will "work".  I want to know which is preferable for
serious software engineering.  I expect that the answer is a matter of personal
preference, but I might be surprised...

David D. Levine (...{decvax,ihnp4,hplabs}!tektronix!teklds!davidl) [UUCP]
                (davidl%teklds%tektronix@csnet-relay.arpa)         [ARPA]

smelser@wang.UUCP (02/06/86)

> I haven't checked the paperback edition on this, but what I'd like to know is:
> 
> 	Should resources be created with ResEdit or RMaker?
> 
> The advantage of ResEdit is its interactive, visual editing capability.
> The advantages of RMaker are that .r files can be mailed and printed easily,
> and that it works better with compilers (especially with batch or shell 
> scripts) in combining resources with (freshly-compiled) code.
> 
> Obviously, both methods will "work".  I want to know which is preferable for
> serious software engineering.

I've found it substantially easier to whip up dialogs and alerts (and make
them look right) with ResEdit than with RMaker.  But then I go and turn the
results back into a .r file.  Why?  Because ResEdit doesn't provide any
*direct* method of ordering the items in a DITL.  The order of items is
critical in using a dialog which has many (>1) controls in it.  Using RMaker
lets me be sure of that order.

dubois@uwmacc.UUCP (02/07/86)

> I've found it substantially easier to whip up dialogs and alerts (and make
> them look right) with ResEdit than with RMaker.  But then I go and turn the
> results back into a .r file.  Why?  Because ResEdit doesn't provide any
> *direct* method of ordering the items in a DITL.  The order of items is
> critical in using a dialog which has many (>1) controls in it.  Using RMaker
> lets me be sure of that order.

I use ResEdit also, and agree with this assessment, except for the
statement that there's no capability for direct ordering.  What
do you mean by "direct"?   You can use "send to back" and "bring to
front" under the ditl menu.  Suppose I have items a, b, c, d, e, and f,
in that order, and I want to switch them to a, f, e, d, c, b.
I successively select and bring to front f, e, d, c and b, in that order.
(In the general case, selectings and bringing to front all items, in
the order desired, accomplishes the task.  But often one only wants
to rearrange some rightmost set.   If the items to be reordered
constitute a leftmost set of smaller size than the corresponding
rightmost set, then select in reverse order and use send to back instead.)

I don't find this a big problem, even for dialogs with upwards of twenty
items.  Other schemes, say, select an item and then specify its ordinal
position, would be more unwieldy overall, I think.

-- 
                                                                    |
Paul DuBois     {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois        --+--
                                                                    |
...Nor do all agree on the definition of monophyly.                 |

smelser@wang.UUCP (pri=8 Craig Smelser) (02/10/86)

> 
> > I've found it substantially easier to whip up dialogs and alerts (and make
> > them look right) with ResEdit than with RMaker.  But then I go and turn the
> > results back into a .r file.  Why?  Because ResEdit doesn't provide any
> > *direct* method of ordering the items in a DITL.  The order of items is
> > critical in using a dialog which has many (>1) controls in it.  Using RMaker
> > lets me be sure of that order.
> 
> I use ResEdit also, and agree with this assessment, except for the
> statement that there's no capability for direct ordering.  What
> do you mean by "direct"? 

What I meant by "direct" is something along the lines of being able to
see (and renumber, or drag the elements of) an ordered list of the dialog
elements.  Having important aspects of the dialog be invisible makes me
nervous.  I took a look at ResEdit's TMPL definition language, but it's
not flexible enough to deal with DITL's because it lacks any conditional
constructs. (The size of DITL elements varies with their type.)

The solution you suggest (using send to back or bring to front) is functional,
but error-prone.  Perhaps you're more systematic than I am...