fore@athena.cs.uga.edu (Howard Fore) (01/04/91)
Ok, you MacAppies: 1. How well is MacApp at dealing with Apple/LocalTalk communication? Are there prewritten methods and classes to deal with this? I need to write a program that will communicate across a LocalTalk LAN to retrieve a text file from a hard drive. Will I have to write the routines myself for going across LocalTalk? Any advice? 2. The APDAlog lists MacApp 2.0 as being available on a CD as well as 10 disks. It also mentions various "goodies" that are on the said CD with MacApp. What are these "goodies"? 3. (To the general public) Does anyone have the source code for Public Folder or know where I can get it or the code for something similar? Thanks. -- ------------------------------------------------------------------------------ Howard Fore fore@athena.cs.uga.edu (128.192.4.49)
peirce@outpost.UUCP (Michael Peirce) (01/05/91)
In article <1991Jan3.221839.21979@athena.cs.uga.edu>, fore@athena.cs.uga.edu (Howard Fore) writes: > > Ok, you MacAppies: > > 1. How well is MacApp at dealing with Apple/LocalTalk communication? Are there > prewritten methods and classes to deal with this? I need to write a program > that will communicate across a LocalTalk LAN to retrieve a text file from > a hard drive. Will I have to write the routines myself for going across > LocalTalk? Any advice? No built-in support. I'll be releasing some classes for using ADSP with MacApp in a couple of months - it's part of a book on AppleTalk programming that I'm writing for Addison-Wesley. Unfortunately, they're not ready for public consumption just yet. > 2. The APDAlog lists MacApp 2.0 as being available on a CD as well as 10 disks. > It also mentions various "goodies" that are on the said CD with MacApp. What > are these "goodies"? The biggest (literally) thing on the MacApp CD is the precompiled libraries. They have precompiled versions of MacApp that have various combinations of compiler flags and such. This can save you some time UNLESS you want to use an updated version, then they're worthless. There is also a tutorial and some unsupported classes too. > 3. (To the general public) Does anyone have the source code for Public Folder > or know where I can get it or the code for something similar? Sorry, Public Folder is Copyright Claris Corporation. Although they make it available for free, it's still their program. > Thanks. Good luck! - michael, author of Public Folder in a previous life -- Michael Peirce -- {apple,decwrl}!claris!outpost!peirce -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
wiechman@athos.rutgers.edu (NightMeower) (01/05/91)
In article <1991Jan3.221839.21979@athena.cs.uga.edu> fore@athena.cs.uga.edu (Howard Fore) writes: > Ok, you MacAppies: > > 1. How well is MacApp at dealing with Apple/LocalTalk communication? Are there > prewritten methods and classes to deal with this? I need to write a program > that will communicate across a LocalTalk LAN to retrieve a text file from > a hard drive. Will I have to write the routines myself for going across > LocalTalk? Any advice? The 2.0+ version of MacApp does not have anything on AppleTalk. 1.1b1 had an example of a Communications program that would send messages from one Mac to another. When MacApp was updated they left this sample out due its lack of popularity and improved the other samples. The code from the previous sample code be updated without too many problems because the deep down code has no user interface. One point to mention is that MacApp cannot be used to write DAs, INITs, etc. I imagine that it will be possible to do so in the future. > 2. The APDAlog lists MacApp 2.0 as being available on a CD as well as 10 disks. > It also mentions various "goodies" that are on the said CD with MacApp. What > are these "goodies"? The goodies include tear-off menus, custom menus, and floating palettes. These are currently unsupported but work very well. I am using them inside of a project that I am working on. There are others that I probably did not mention. Kevin -- =========================================================================== Kevin S. Wiechmann arpa: wiechman@cs.rutgers.edu This is only a test... for the next sixty seconds...
tim@hoptoad.uucp (Tim Maroney) (01/05/91)
In article <1991Jan3.221839.21979@athena.cs.uga.edu> fore@athena.cs.uga.edu (Howard Fore) writes: >Ok, you MacAppies: > >1. How well is MacApp at dealing with Apple/LocalTalk communication? Are there > prewritten methods and classes to deal with this? I need to write a program > that will communicate across a LocalTalk LAN to retrieve a text file from > a hard drive. Will I have to write the routines myself for going across > LocalTalk? Any advice? There are no built-in methods. It doesn't seem (and I'm familiar with both domains) that it would be hard to create object wrappers for the Appletalk driver calls. And it does seem that they would be useful in program beautification. Higher-level objects could then be built to do what you want in terms of file transfer and so forth. They wouldn't be very useful for implementing other people's protocols, which would require going down to the lower-level object wrappers. But they would be very useful for making up your own applications which could rely on these higher-level services. >2. The APDAlog lists MacApp 2.0 as being available on a CD as well as 10 disks. > It also mentions various "goodies" that are on the said CD with MacApp. What > are these "goodies"? Nothing extraordinary. Some MPW scripts that are somewhat useful for MPW developers, that's all I remember. Maybe they're also including ViewEdit, example programs, and unsupported modifications under "goodies". Incidentally, MacAppers -- please ignore the example programs shipped by Apple. They are very small and do not scale well. If you adopt the unit strategy of the example programs, in which everything knows about the applications and document subclasses and those subclasses know about everything else, you will not be able to expand beyond a few source files or do much information hiding or code reusability. Instead, the strategy to use is: Your application and document subclasses do know about everything, but hardly anything knows about them. They are "master controllers" which are unknown to most of the things they control. This will lead to a lot of USES in the units dealing with document and application subclasses, but a manageable number elsewhere. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion." -- Carl Sagan, 1987 CSICOP keynote address
urlichs@smurf.sub.org (Matthias Urlichs) (01/05/91)
In comp.sys.mac.programmer, article <1991Jan3.221839.21979@athena.cs.uga.edu>,
fore@athena.cs.uga.edu (Howard Fore) writes:
< Ok, you MacAppies:
<
< 1. How well is MacApp at dealing with Apple/LocalTalk communication? Are there
< prewritten methods and classes to deal with this? I need to write a program
< that will communicate across a LocalTalk LAN to retrieve a text file from
< a hard drive. Will I have to write the routines myself for going across
< LocalTalk? Any advice?
<
Hmm, yes, sort of..:
I'm currently writing a MacApp-lication (to be exact, it's destined to be a
nifty News reader) which features a "TConnection" class which makes it pretty
easy to write asynchronous data transfer stuff.
I already have handlers for MacTCP and the File Manager; it's pretty easy to
add more.
The important point here is that it's asynchronous, which means that the user
can continue working while stuff is shuttled through the network.
The whole beast will be freely available, including source; however, it'll
take a while. I'm still working at the low-level stuff, currently debugging
a list class which stores variable-sized chunks of data (without requiring an
extra object for each chunk) and which can sort (via an AVL tree, which is
where the debugging comes from. ;-)
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/tim@hoptoad.uucp (Tim Maroney) (01/05/91)
In article <Jan.4.13.24.17.1991.14211@athos.rutgers.edu> wiechman@athos.rutgers.edu (NightMeower) writes: >One point to mention is that MacApp cannot be used to write DAs, >INITs, etc. I imagine that it will be possible to do so in the future. I would be *very* surprised if it were. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Americans will buy anything, as long as it doesn't cross the thin line between cute and demonic." -- Ian Shoales
urlichs@smurf.sub.org (Matthias Urlichs) (01/06/91)
In comp.sys.mac.programmer, article <14545@hoptoad.uucp>,
tim@hoptoad.UUCP (Tim Maroney) writes:
<
< Incidentally, MacAppers -- please ignore the example programs shipped
< by Apple. They are very small and do not scale well. If you adopt the
< unit strategy of the example programs, in which everything knows about
< the applications and document subclasses and those subclasses know
< about everything else, you will not be able to expand beyond a few
< source files or do much information hiding or code reusability.
<
Hmm, perhaps the MacApp sample programs were intended to show specific
features of MacApp, and not to be templates for big applications?
Relates to this problem, unfortunately, is the fact that the Pascal USES
clause is purely textual, not recursive, and can't be specified in the
IMPLEMENTATION section (unless you play with {$IFC xyzzy} and {$I
xyzzy.stuff.p.include}, which generates other problems).
That's where MacApp-compatible languages like Modula-2 come in...
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/lsr@Apple.com (Larry Rosenstein) (01/08/91)
In article <Jan.4.13.24.17.1991.14211@athos.rutgers.edu>, wiechman@athos.rutgers.edu (NightMeower) writes: > > The 2.0+ version of MacApp does not have anything on AppleTalk. 1.1b1 > had an example of a Communications program that would send messages The AppleTalk unit from MacApp 1.x was written using the (now-frowned-upon) high-level AppleTalk interface. It also, was a first guess at what an AppleTalk unit might be like, and we never got any feedback on whether it helped anyone, or what should be included in an AppleTalk unit. So it was downgraded to an experimental unit, and later removed.