Copy Link
Add to Bookmark
Report
GEnieLamp A2Pro - Vol.4, Issue 19
|||||| |||||| || || |||||| ||||||
|| || ||| || || ||
|| ||| |||| |||||| || |||| Your
|| || || || ||| || ||
|||||| |||||| || || |||||| |||||| GEnieLamp Computing
|| |||||| || || |||||| RoundTable
|| || || ||| ||| || ||
|| |||||| |||||||| |||||| RESOURCE!
|| || || || || || ||
||||| || || || || ||
~ WELCOME TO GENIELAMP A2Pro! ~
"""""""""""""""""""""""""""
~ Publish and Subscribe ~
~ We Want Information! ~ A2U Applesoft Course Continues ~
~ Preferences Mania ~ New APDA Source ~
~ HOT NEWS, HOT FILES, HOT MESSAGES ~
////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
GEnieLamp A2Pro ~ A T/TalkNET OnLine Publication ~ Vol.4, Issue 19
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Editor.......................................................Nate Trost
Publisher.................................................John Peters
Copy-Editor............................................Bruce Maples
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
~ GEnieLamp IBM ~ GEnieLamp ST ~ GEnieLamp [PR] ~ GEnieLamp Windows ~
~ GEnieLamp A2Pro ~ GEnieLamp Macintosh ~ GEnieLamp TX2 ~
~ GEnieLamp A2 ~ LiveWire (ASCII) ~ GEnieLamp MacPRO ~
~ Solid Windows ~ Config.sys ~ A2-Central ~
~ Member Of The Digital Publishing Association ~
GE Mail: GENIELAMP Internet: genielamp@genie.geis.com FTP: sosi.com
////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>>> WHAT'S HAPPENING IN THE APPLE A2Pro ROUNDTABLE? <<<
"""""""""""""""""""""""""""""""""""""""""""""""""""""""
~ September 1, 1994 ~
FROM MY DESKTOP ......... [FRM] HEY MISTER POSTMAN ...... [HEY]
Notes From The Editor. Is That A Letter For Me?
A2PRO ROUNDTABLE STAFF .. [DIR] CAMPUS GREEN ............ [CAM]
Directory of A2Pro Staff. A2U Course Marches On.
LIBRARY BIT BONANZA ..... [LIB] DEVELOPERS CORNER ....... [DEV]
HOT Files You Can Download. News From Online Developers.
RTC Watch ............... [RTC] PUBLISH & SUBSCRIBE ..... [PUB]
Happenings in A2Pro RTCs. An A2Pro RTC transcript.
LOG OFF ................. [LOG]
GEnieLamp Information.
[IDX]"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
READING GEnieLamp GEnieLamp has incorporated a unique indexing
""""""""""""""""" system to help make reading the magazine easier.
To utilize this system, load GEnieLamp into any ASCII word processor
or text editor. In the index you will find the following example:
HUMOR ONLINE ............ [HUM]
[*]GEnie Fun & Games.
To read this article, set your find or search command to [HUM]. If
you want to scan all of the articles, search for [EOA]. [EOF] will take
you to the last page, whereas [IDX] will bring you back to the index.
MESSAGE INFO To make it easy for you to respond to messages re-printed
"""""""""""" here in GEnieLamp, you will find all the information you
need immediately following the message. For example:
(SMITH, CAT6, TOP1, MSG:58/M530)
_____________| _____|__ _|O__ |____ |_____________
|Name of sender CATegory TOPic Msg. Page number|
In this example, to respond to Smith's message, log on to page
475 enter the bulletin board and set CAT 6. Enter your REPly in TOPic 1.
A message number that is surrounded by brackets indicates that this
message is a "target" message and is referring to a "chain" of two
or more messages that are following the same topic. For example: {58}.
ABOUT GEnie GEnie's monthly fee is $8.95 which gives you up to four hours
""""""""""" of non-prime time access to most GEnie services, such as
software downloads, bulletin boards, GE Mail, an Internet gateway,
multi-player games and chat lines. GEnie's non-prime time connect rate is
$3.00 an hour. To sign up for GEnie, just follow these simple steps.
1. Set your communications software to half duplex (local echo) 8 bits, no
parity and 1 stop bit, at 300, 1200 or 2400 baud.
2. Call (with modem) 1-800-638-8369. Upon connection type HHH.
3. Wait for the U#= prompt. Type: JOINGENIE and hit RETURN. When you
get the prompt asking for the signup/offer code, type: DSD524 and hit
RETURN.
4. Have a major credit card ready, as the system will prompt you for your
information. If you need more information, call GEnie's Customer Service
department at 1-800-638-9636.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
[EOA]
[FRM]//////////////////////////////
FROM MY DESKTOP /
/////////////////////////////////
Notes From My Desktop
"""""""""""""""""""""
o TOP OF THE PAGE
>>> TOP OF THE PAGE <<<
"""""""""""""""""""""""
PUBLISH AND WHAT? No, GEnieLamp A2Pro has not changed
""""""""""""""""" distribution formats! However, we DO feature an
engrossing RTC transcript this month--Mike Westerfield from The
Byte Works, Inc with "Publish and Subscribe". What is it? Well, if
you're into IIGS application programming, you'll want to read the
transcript and find out!
In other news...A2Pro's A2 University course "An Introduction to
Applesoft BASIC" continues, and we have the latest information on
that course. A2Pro has been quite busy this past month, and it shows
in this issue, so I'll sit back, shut up and let you read all about it!
Enjoy the issue!
Nate Trost
GEnieLamp A2Pro
[EOA]
[DIR]//////////////////////////////
A2PRO ROUNDTABLE STAFF /
/////////////////////////////////
By Nate Trost
[A2PRO.GELAMP]
______________________________________________
APPLE II PROGRAMMERS & DEVELOPERS ROUNDTABLE
_____ ______ ______________________________________________
/_____|/______\
/__/|__| ___|__| Head Sysop: Hangtime (HANGTIME)
/__/_|__| /_____/ Your Sysops: Greg Da Costa (A2PRO.GREG)
/________|/__/ __ __ __ Todd P. Whitesel (A2PRO.TODDPW)
/__/ |__|__/______ /_//_// / Nathaniel Sloan (A2PRO.HELP)
/__/ |__|________// / \/_/ Nate Trost (A2PRO.GELAMP)
[*][*][*]
[EOA]
[HEY]//////////////////////////////
HEY MISTER POSTMAN /
/////////////////////////////////
Is That A Letter For Me?
""""""""""""""""""""""""
By Nate Trost
[A2PRO.GELAMP]
o BULLETIN BOARD HOT SPOTS
o PROGRAMMER'S TIPS
o HOT TOPICS
o MESSAGE SPOTLIGHT
>>> BULLETIN BOARD HOT SPOTS <<<
""""""""""""""""""""""""""""""""
[*] CAT12, TOP19, MSG{36}.......................Apple II EPROM Burners
[*] CAT15, TOP14, MSG{154}..............................Window Manager
[*] CAT16, TOP22, MSG{72}.....................Program Preference Files
[*] CAT17, TOP5, MSG{91}................................AppleTalk-ing
[*] CAT18, TOP3, MSG{2}..................................Stack Design
[*] CAT20, TOP4, MSG{139}...........................Finder Extensions
[*] CAT36, TOP10, MSG{206}.................................ORCA/Pascal
[*] CAT36, TOP11, MSG{268}......................................ORCA/C
>>> PROGRAMMER'S TIPS <<<
"""""""""""""""""""""""""
READING AND WRITING WITH APPLESOFT I am an experienced programmer but I
"""""""""""""""""""""""""""""""""" am new to the Apple IIe. I can't
find any information about creating, reading and writing files in
Applesoft BASIC in any of the manuals I have been able to get my hands
on. I need both sequential and relative(random?) files. Can anyone
pass on that information to me? It's been very frustrating trying to
find this information. Thanks.
(M.ALLSUP, CAT7, TOP2, MSG:5/M530)
<<<<< Sequential files:
"""""
10 D$ = CHR$(4)
20 F$ = "FILENAME"
25 REM -- how to create a text file without writing anything to it.
30 PRINT D$"CREATE";F$;",TTXT"
35 REM -- how to open and write to a text file
40 PRINT D$"OPEN";F$
50 PRINT D$"WRITE";F$
60 PRINT "Something you want to print."
70 PRINT D$"CLOSE"
75 REM -- how to open and add to a text file
80 PRINT D$"APPEND";F$
90 PRINT "Something you want to add to this file."
100 PRINT D$"CLOSE"
105 REM -- how to open and read from a text file
110 PRINT D$"OPEN";F$
120 PRINT D$"READ";F$
130 INPUT GT$ : REM variable to collect what you are reading
140 PRINT D$"CLOSE"
You really need to pick up a book on ProDOS. I highly recommend _ProDOS
Inside and Out_ by Dennis Doms and Tom Weishaar. I bet Resource Central
will be delighted to sell you a copy.
Charlie
(C.HARTLEY3, CAT7, TOP2, MSG:6/M530)
>>>>> Now available from Byte Works, Inc:
"""""
AppleSoft Tutorial
by Apple Computer Inc.
Addison-Wesley
260 pages, 5.25" disk
$29.95
Applesoft BASIC Programmer's Reference Manual
by Apple Computer, Inc.
Addison-Wesley
340 pages
$22.95
We have a small number in stock, ready for immediate shipment. Look
for a complete, official annoucement from us later this week about APDA &
Addison- Wesley products, now available from us.
If anyone reading this has not heard about Byte Works, visit Cat 36
for more information.
Mike Westerfield
(BYTEWORKS, CAT7, TOP2, MSG:9/M530)
USING MDBASIC AND PROSEL I recently purchased MDBASIC. I wanted to use
"""""""""""""""""""""""" this software as a PROSEL-16 shell command.
But the MDBASIC documentation only described how to setup for the ORCA or
GNO shells. I don't have ORCA or GNO.
The 'Easy Install' is described on page 12. It says from Finder:
---> Drag the icons....
H*ll, I don't use the FINDER and in the little time I've spent
running desktop applications I've never 'pulled on an icon'. :) Anyway
through trial and error I got MDBASIC to run from the PROSEL-16 command
line.
This is what worked for me:
1. Create a new MDBASIC subdirectory on your hard drive.
2. Use PROSEL-16 to copy the following files into the MDBASIC
subdirectory.
Name Type Blks
MDBASIC S16 204
BInclude DIR 2
MDB.Fonts DIR 1
Help DIR 1
Samples DIR 1
3. Place an additional copy of MDBASIC (the S16 file) into the
COMMANDS subdirectory. Then change it's filetype to EXE.
4. Use PROSEL-16's Modify Parameters option to set Prefix #09 to the
full pathname of the MDBASIC directory. For example /hard1/mdbasic
or /hard2/asoft/mdbasic.
Nez
(L.JIMINEZ [Nez], CAT9, TOP2, MSG:70/M530)
RESOURCE FORK AND TEXT FILES I'm opening a text file and displaying it
"""""""""""""""""""""""""""" in a window along with the pathname and
number of bytes. I'm using eof from GS/OS Open call for the byte total.
A certain text file shows 28,920 bytes. ShadowWrite agrees w/ this
number as does AWGS. Finder's Icon Info, however, shows 29,495 bytes,
31k on disk. Can anyone tell me why this should be?
...
I just found out that text file, gshk.docs, has a resource fork. I
didn't know text files could have a resource fork. I guess that would
explain the discrepancy. Yes?
Mark Wade
(M.WADE7 [Mark], CAT1, TOP21, MSG:97-98/M530)
<<<<< Mark, yes, that would explain the discrepancy.
"""""
Text files can have resource forks, but usually do not.
(POWERPC.PRO [Sheppy], CAT1, TOP21, MSG:99/M530)
>>>>> Well, you can put a resource fork on just about any file...BUT
""""" text files usually do not, because once a resource fork is
attached to a file, that file CANNOT be used from ProDOS 8. This has
caused problems for people who have used the Finder to add comments to
files..comments are stored in the rComment resource with an ID of 1..
Probably this is the resource in that text files. Just don't try to use
it from ProDOS 8, and everything will be okay :)
(T.BUCHHEIM [] Tim 'pi' [], CAT1, TOP21, MSG:100/M530)
GSBUG & 8-BIT PROGRAMS I haven't installed AppleWorks 4.0 yet. Could
"""""""""""""""""""""" someone answer a lazy question?
Does entering GSBug and immediately exiting crash AWKS 4? It just
happened to me with 3.0. I hate that.
-- Jay
(JAY.KRELL, CAT5, TOP3, MSG:40/M530)
<<<<< Actually, GSBug has a serious problem with the way it handles the
""""" emulation-mode stack that can cause your system to be flaky after
entering GSBug. It effectively cuts the size of the emulation mode stack
IN HALF. In addition, in emulation-mode programs, just entering GSBug
can sometimes be enough to bring your system down. The stack problem is
most acute in interrupt intensive systems (interrupt handlers use the
emulation-mode stack), particularly systems with AppleTalk installed.
Some of the problems with GSBug (this stack problem, the reentrancy
problem with tool breaks, etc.) strike me so often that I have long
planned to write my own debugger. I was actually planning this back in
'87 or '88, but when I heard about GSBug I thought it might be good
enough. It wasn't, but they kept making it better, so I kept waiting.
Sadly, some of the inherent flaws were never fixed (like the
emulation-mode stack handling, which is just a hack to take care of
Apple's original oversight in handling it wrong).
-G.T. Barnabas
(BARNABAS [G.Templeman], CAT5, TOP3, MSG:42/M530)
REQUESTS AND RESOURCE I've written an application that acceptsRequests..
""""""""""""""""""""" do I need to change the "currentResourceApp" when
my request procedure is run as I do with an NDA or FExt? Or does the
system auto-magically know that my application has been accessed so the
resourceApp is appropriately set...
Rick
BTW, I realize that if my application is running it is generally the
curResourceApp, but I'm thinking of things along the lines of running in
the bground under The Manager...
(R.ADAMS48 [Rick], CAT20, TOP7, MSG:14/M530)
<<<<< Yes; when your request procedure is called, you need to save the
""""" current resource app and switch to your own, restoring the
original when you exit.
(POWERPC.PRO [Sheppy], CAT20, TOP7, MSG:15/M530)
WE WANT INFORMATION! (BAR...) I recently went through the TN of the
""""""""""""""""""""""""""""" information bar. At the end of it were
a few suggestions on how to use it. Among it is a hint to use controls in
the bar, but with a claim that this would not possible for whatever
reason. Is this still true?
Going with NewControl2 doesn't do it for me, since the info port
isn't the same as the window port. Am I allowed to create a control in
the window manager's port (as was indicated the info bar is in)??
Alex
(A.CORRIERI [Alex], CAT15, TOP14, MSG:155/M530)
<<<<< Nope, you can't put controls in the info bar. However, it's not
""""" all that difficult to SIMULATE controls in the info bar. Just
draw them in there yourself and track the hits. Rectangular controls
are, obviously, easier to track manually. :)
You could also just not create a real info bar -- simulate it
instead by drawing a line across the window and putting real controls up
above.
(POWERPC.PRO [Sheppy], CAT15, TOP14, MSG:156/M530)
>>>>> Certain types of controls (e.g. Pop-up menu controls) are built
""""" around routines in other tool sets. Therefore, by handling the
control-part of the the interface, you can put things like pop-ups (and
possibly even things like line-edits and text-edits) in infobars. Not
that I've ever used anything but menus and popups in my infobars...
-G.T. Barnabas
(BARNABAS [G.Templeman], CAT15, TOP14, MSG:157/M530)
<<<<< > However, it's not all that difficult to SIMULATE controls
""""" >in the info bar.
It's easier to simulate the info bar.
Jawaid
(PROCYON.INC, CAT15, TOP14, MSG:160/M530)
>>>>> That all depends on what you're doing. If simulating the info bar
""""" means that you end up having to use (and manage) scroll-bar
controls yourself inside the content area of the window (instead of
letting TaskMaster automatically handle all the scrolling/origin stufff,
etc.) then it's easier to put the controls in the info bar. Especially
if it's just things like menus, popups, icons, simple-
button-type-things, etc.
-G.T. Barnabas
(BARNABAS [G.Templeman], CAT15, TOP14, MSG:163/M530)
>>> HOT TOPICS <<<
""""""""""""""""""
[The A2Pro Bulletin Board caught fire in August with
a rather lively discussion regarding preferences
files....we present a smattering of the action--Ed.]
WILD PREFERENCES DEBATE Tim, Sloanie,
"""""""""""""""""""""""
I disagree STRONGLY with your assertion that "you really shouldn't
be saving preferences into a program's resource fork."
This is a technique I feel NEEDS to be used more often. Some
programmers I know used this idea for everything, and, as a result, there
are now multitudes of "xxx.prefs" files for everything under the sun,
most just containing window positions!
It is MUCH nicer for the user to have his program entirely
self-contained (i.e. in a single file) than to have it broken up into
multiple files. It also makes applications easier to write (such as
error handling).
I have some general rules of thumb I use to determine when to use a
prefs file and when to save to my own resource fork. The main one has to
do with the type of preferences being saved: if they are things that are
important to program usability, such that each user really needs his own
copy, they go in a prefs file. If, as in the majority of cases, they are
minor things (read: not set explicitly by the user as preferences, but
just assumed by the application) such as window position, currently
checked menu options, etc., then the benefit to a few network users
doesn't outweigh for me the benefit of keeping all the information in
one file and not glutting up the users folders (especially Desk.Accs and
System.Setup) with extraneous files.
I presume that Apple felt the same way, as they save some
preferences like window position in the program's resource fork in the GS
system software.
-G.T. Barnabas
(BARNABAS [G.Templeman], CAT15, TOP30, MSG:123/M530)
<<<<< The best way, IMO, to handle preferences in an app is as follows:
"""""
1. At the beginning of the program...
a. Call _OpenResourceFile @:MyPrefs
1) If this succeeds
a) Copy the prefs to use as needed
b) Continue the program
2) If this fails
a) Call _CreateResourceFile @:MyPrefs
b) Create a new handle and copy in the default prefs
c) Call _AddResource to put it into the prefs file
d) continue the program
2. When "OK" is clicked in your preferences window...
a. Copy the new prefs into the old prefs handle
b. Call _MarkResourceChange
3. At the end of your program...
a. Call _CloseResourceFile @:MyPrefs
I hear what you're saying, and you may have a point (somewhat),
though it sounds to me like Sully's program is using preferences which
each user on a network might like to customize.
(A2PRO.HELP [ Sloanie ], CAT15, TOP130 MSG:124-125/M530)
>>>>> > I disagree STRONGLY with your assertion that "you really
""""" > shouldn't be saving preferences into a program's resource fork."
I strongly disagree with THIS statement. Storing preferences within
an application's own resource fork is INEXCUSABLE, and when I have a
choice between an app that does this and one that does not, I will use
the one that uses a preferences file.
Eric Shepherd
PPCPro -- Put the POWER in PowerPC
(POWERPC.PRO [Sheppy], CAT15, TOP30, MSG:129/M530)
<<<<< Another point against saving preferences in the program file. It
""""" would be harder for a virus checker to know if the program was
infected if the program can change.
Clay
(C.JUNIEL, CAT15, TOP30, MSG:130/M530)
>>>>> I have to agree, that saving preferences in the program file is
""""" bad.
Not just for the reasons above, but also because it isn't that
AppleShare friendly. Preferences should be saved in the user's folder
(that's the "@:" prefix folks), or if not, inside
"*:System:Preferences:" like on the Macintosh. That way all your
preferences are kept in one place and if you don't want to keep the
preferences, you can simply delete the folder altogether.
Regards,
Richard
(RICHARD.B [Richard], CAT15, TOP30, MSG:131/M530)
<<<<< Just to add another:
"""""
I do what Apple says, use the user path or the "app" path if no user
path exists. This is a good bit more difficult in non-apps, but not too
bad. I also use *:System:Preferences if it already exists. If you don't
like the multitude of .prefs files, putting them all in one place kind
of helps.
Jay
(JAY.KRELL, CAT15, TOP30, MSG:133/M530)
>>>>> I agree that because of AppleShare, virus detection and other
""""" reason, prefs should NOT be stored in the application rFork.
However, in a single user environment, I NEVER liked the idea of a
*:System:Preferences folder. That stuff belongs in the applications
folder. I HATE it when I delete an application and it leaves behind
pieces of it self in my system. That is my biggest objection to most
Windows programs. They leave all kinds of .INI and .DLL files in the
system folder. It is a pain in the ascii to get rid of all the pieces.
In the windows environment it is so out of hand that people are actualy
selling UnInstaller program to help you get rid of all the pieces of an
unwanted program. Now GS programms are starting to do the same type of
thing. Why would you want a programs prefernce files in the system
folder? Keep them with the application!
I would use @:My.Preferences if your are on a net and
9:My.Preferences if not.
_____
James C. Smith
(J.SMITH242 [James Smith], CAT15, TOP30, MSG:134/M530)
<<<<< Doesn't this also cause the dreaded Desktop.Data file bloat.
""""" (Program changes mod date. Desktop.Data gets updated. Old
program data not discarded.)
David
(D.WALLIS2, CAT15, TOP30, MSG:135/M530)
>>>>> Not that @ is that, but many people think it is better. I asked
""""" some beta testers if they prefer System:Preferences and I don't
think anyone said no. What I do is use if it already exists - hopefully
created explicitly by the user, but possibly by another program.
>If you are too lazy to just use @:myapp.prefs, you're _too_ lazy.
It's not that easy for non-apps. They must do something like
FSTSpecific(AppleShare,GetUserPath) and then append their filename, else
DAs and inits have to do like LGetPathname2(MMStartUp), cut off the
filename and append their own. Control Panels and other code resources
have to do something like:
GetRefInfo(GetOpenFileRefNum(MatchResourceHandle(FindHandle)),
cut off the filename and append their own.
The lazy non-app, network hostile method is *:System:Folder:file,
which doesn't even work non-network due to programs like IR. I _think_
Nifty List and GSBug hardcode *:System:Desk.Accs/System.Setup.
Here is a code excerpt for "add-on" prefs. I can put together
something more complete if there is demand for it:
/* here is some real code from AutoMenus
* H is generally Handle (usually to GSString)
* L is locked
* GS is GSString
*
* the AppleShare code has never actually been tested.
*/
#define FREEHandle(h) {FreeHandle(h); h = 0L;}
#define ONERR(x) if (_toolErr) x
/* FreeHandle makes sure the handle is non nil and that its
* id is one of ours and maybe more.
*/
pascal GSStringHndl GetCodeResourcePath(word fileID)
{
GSStringHndl result;
ResultBufHndl bufH = NIL;
word pathlen;
static RefInfoRecGS griParms = {3};
griParms.refNum = GetOpenFileRefNum(fileID);
ONERR(goto err);
pathlen = GetRefPathLength(griParms.refNum);
/* buff too small err cleared, never returned */
ONERR(goto err);
bufH = NewBufLH(pathlen);
ONERR(goto err);
griParms.pathname = *bufH;
GetRefInfoGS(&griParms);
ONERR(goto err_disp);
result= BufToGSH(bufH);
return result;
err_disp:
{
FREEHandle(bufH); /* preserves error */
}
err:
return 0L;
} /* end GetCodeResourcePath */
GSStringHndl GetCodeOMFPath(void)
{
#if 0 /* if'ed out 'cause I know AutoMenus is a control panel */
GSStringHndl result;
/* maybe add error checking */
SetHandID(InitID, (result = FindHandle(LGetPathname2(MMStartUp(), 1))));
/* InitID is an ID allocated by AutoMenus, though most programs don't
* do that. I did 'cause I'm not sure it is OK for a control panel to
* allocate handles with their given id- the Control Panel NDA's id
*/
return result;
#endif
}
void prefs_make_path(void)
{
static struct
{
word resourceType;
longword resourceID;
word fileID;
} foundRec;
longword foundRecPtr= ((longword) &foundRec) | ((longword) 0x80000000);
/* ORCA/C 2.0.2 A1 can't do this initialization statically */
/* hi bit is new in 6.0 */
Handle thisCode;
ResultBufHndl bufH = NIL;
int ashare;
word erro;
GSStringHndl suffixH; /* filename: AutoMenus.prefs */
GSStringHndl sysPrefs; /* *:System:Preferences */
GSStringHndl path;
GSStringHndl codePathHandle;
GSStringPtr codePathPtr;
word codePathLen;
boolean fexists;
if (prefs_path_handle != NIL) {
fexists= HFileExists(prefs_path_handle);
if (fexists) {
prefs_path_ptr = Lock_DerefH(prefs_path_handle);
return;
} else {
prefs_dispose_path();
}
}
suffixH = LoadRes(rC1InputString, rPrefsFile); /* AutoMenus.prefs */
if (_toolErr != 0) goto err;
sysPrefs = LoadRes(rC1InputString, rSysPrefs); /* *:System:Preferences
*/
if (_toolErr != 0) goto err;
thisCode = FindHandle(&prefs_make_path);
MatchResourceHandle((ptr)foundRecPtr, thisCode);
if (_toolErr == 0) {
codePathHandle = GetCodeResourcePath(foundRec.fileID);
}
else if (_toolErr == resNotFound) { /* if we are a load file */
codePathHandle = GetCodeOMFPath();
}
else goto err;
if ( (_toolErr != 0) or (codePathHandle == NIL) ) goto err;
ashare = HFileIsAppleShare(codePathHandle);
LError(); ONERR(goto err);
if (ashare) {
path = HGetAppleShareUserPath();
if (path == NIL)
path = HGetPathFromFull(codePathHandle);
/* if no user path, which can happen, see IR's GetPrefsPath */
}
else if (HFileExists(sysPrefs)) {
path = sysPrefs;
DetachResource(rC1InputString, rSysPrefs);
}
else {
path = HGetPathFromFull(codePathHandle);
}
LError(); if ((_toolErr != 0) or (path == NIL) ) goto err;
FREEHandle(codePathHandle);
prefs_path_handle = ConcatGSLH(path, suffixH); /* locked */
if (_toolErr == 0) HExpandPath(prefs_path_handle);
FREEHandle(path); /* allocated by us or detached resource */
FREEHandle(codePathHandle); /* allocated by us */
/* DO NOT dispose of handles owned by Resource Manager. I accidentally */
/* did this with the rC1InputStrings. The handles were reallocated for */
/* Event Manager and Menu Manager FTP's and then the Resource Manager */
/* freed them, they were again reallocated and overwritten. Nifty List's */
/* call to EMStatus crashed and GSBug crashed over and over. */
IGNErr(ReleaseResource(-1, rC1InputString, rPrefsFile););
done:
prefs_path_ptr = (!_toolErr ? Lock_DerefH(prefs_path_handle) : NIL);
/* bug in ORCA/C makes this necessary */
/* prefs_path_ptr = (_toolErr ? NIL : Lock_DerefH(prefs_path_handle)); */
/* doesn't work but should */
return;
err:
LError();
prefs_path_ptr = NIL;
prefs_path_handle = NIL;
}
Also, Harold's idea has a sound basis- to limit memory and disk
usage, but those things are cheaper these days than a lot of us will
admit. One compromise, which prevents the code from always loading, is
build it into every app (waste disk space) but make it modular such that
once an app loads a copy, it stays in memory for others. But, the init
approach has the advantage...two at least, of being updatable
independently which is important, and the init (or DA or cdev) can have
an interface that lets the user specify *:System:Preferences if they
way, where the interface might be a bit of a pain to put in everyapp.
Anyone is welcome to use the above code in such an init, but there
is a lot to fill in.
-- jay
(JAY.KRELL, CAT15, TOP30, MSG:151/M530)
>>> MESSAGE SPOTLIGHT <<<
"""""""""""""""""""""""""
[this was posted in regard to a question asking about the availability
of C compilers for the //e--Ed.]
This is going to sound like a strange answer, but I'm going to toss
it out anyway.
Hyper-C is free, and in my opinion, you get what you pay for.
Aztec-C is the best compiler I ever saw for the 6502, which is sort
if like saying Papa Doc was the best Haitian dictator I ever heard of.
The 6502 is just too small for full-size compilers, and the code they
generate is just too big for the 6502. Aztec-C does an amazing job with
it's native code generation, but the compiler is slow and the
environment is not very powerful compared to what people expect these
days. The code it generates is also often too large for real projects.
A program in Aztec-C is often 5-10 times the size of the same program in
AppleSoft, and 2-4 times the size of the same program in assembly.
Aztec-C is unique in that it offers the option of p-code. This
trades some run-time speed for space, making the programs small enough
that fairly good size applications are possible.
But there is an alternative. If the issue is that you own a //e,
and not that the programs you want to _create_ must _run_ on a //e, you
should consider getting a GS. They can be found at garage sales and
other second hand sourced for obscene prices. I heard one story of a
fellow who bought two complete GS systems recently for $200. A used GS
lets you continue to do all of the things you do with your //e now, and
you can continue to use your current printers, monitors, and so forth.
It also lets you choose from full size compilers for a variety of
languages, though. Just a thought... but now might be the best time ever
to upgrade from an 8 bit Apple ][ to a GS, simply because of the price
the used ones go for!
Mike Westerfield
(BYTEWORKS, CAT4, TOP12, MSG:24/M530)
[*][*][*]
While on GEnie, do you spend most of your time downloading files?
If so, you may be missing out some excellent information in the Bulletin
Board area. The messages listed above only scratch the surface of
what's available and waiting for you in the bulletin board area.
If you are serious about your Apple II, the GEnieLamp staff strongly
urge you to give the bulletin board area a try. There are literally
thousands of messages posted from people like you from all over the world.
[EOA]
[DEV]//////////////////////////////
DEVELOPER'S CORNER /
/////////////////////////////////
News From The A2Pro Online Developers
"""""""""""""""""""""""""""""""""""""
By Nate C. Trost
[A2PRO.GELAMP]
>>> ONLINE SUPPORT IN A2PRO <<<
"""""""""""""""""""""""""""""""
CAT TOP COMPANY
=== === =======
29 INDEPENDENT DEVELOPERS ONLINE
2 DYA/DigiSoft Innovations Online
8 Simplexity Software Online
14 Quality Computers Q-LABS Online
20 DreamWorld Software Online
26 METAL/FV Software Online
32 Kitchen Sink Software Online
38 EdIt-16 (Bill Tudor)
30 PROCYON, INC.
31 SOFTDISK PUBLISHING
33 GS+ MAGAZINE
34 JEM SOFTWARE
35 PRODEV, INC.
36 THE BYTE WORKS
Each month this column feature highlights and news from various
developers who provide support via A2Pro.
>>> NEWS FROM THE BYTE WORKS <<<
""""""""""""""""""""""""""""""""
NEW SERVICES FROM THE BYTE WORKS
""""""""""""""""""""""""""""""""
Contact:
Mike Westerfield
Byte Works, Inc.
8000 Wagon Mound Dr. NW
Albuquerque, NM 87120
(505) 898-8183
AOL: Send e-mail to MikeW50 or visit us using keyword ByteWorks.
GEnie: Send e-mail to ByteWorks or visit us in A2, Category 45.
Internet: Send e-mail to MikeW50@AOL.COM
The Byte Works, Inc. is now the exclusive distributor of Apple II
APDA products, and is one source of Addison-Wesley books for the Apple
II line of computers.
This price list is a preliminary catalog of the items available
from the Byte Works. This list is subject to change without notice, and
we expect it to change as we order new items from Addison-Wesley and as
some items go out of print.
Apple II APDA Items -------------------
APDA products are produced by the staff of Apple Computer for the
benefit of the programming community. These products range from full
commercial products that are no longer sold in enough numbers to
justify keeping them in retail channels to beta versions of software
and manuals that were never intended for commercial release. Packaging
ranges from slick, four-color manuals to 3 -hole notebook pages. The
underlying idea behind all APDA products, though, is this: Programmers
need them, so Apple makes them available through APDA.
Some of these items are available in stock, and some are reproduced
as people order them. We'd be happy to tell you whether something is in
stock or is printed on demand, but unless you check with us first,
assume any APDA order will take 3-4 weeks to fill.
Here's the (almost) complete list of Apple II APDA products.
Please note that MPW IIGS C is available in limited supply, and cannot
be reprinted once existing stock is sold. MPW IIGS Pascal is
noticeably absent; it is being updated, and will be added to the price
list when it is available.
APDA-01 Apple II Filecard Toolkit $19.00
APDA-02 Apple II System Disk 4.0.2 $14.00
APDA-03 Apple II Desktop Toolkit-Pascal $30.00
APDA-04 Apple II SuperPILOT $69.00
APDA-06 Apple IIGS System 6.0 $24.00
APDA-47 Apple IIGS System 6.0.1 $24.00
APDA-07 Apple IIc Technical Reference 2nd Ed. $30.00
APDA-08 Apple IIc Memory Expansion Card Ref $15.00
APDA-09 Apple II Memory Expansion Card Tech. Ref. $15.00
APDA-10 Apple II High Speed SCSI Card Ref. $15.00
APDA-11 Video Overlay Card Development Kit $19.00
APDA-12 AppleShare Programmer's Guide for the Apple II $30.00
APDA-14 XREF Apple II, Books and Notes $20.00
APDA-15 Apple II GSBug and Debugging Tools Reference $30.00
APDA-16 MPW IIGS Assembler Reference $100.00
APDA-17 MPW IIGS C Reference (Limited Supply!) $150.00
APDA-19 MPW IIGS Tools $50.00
APDA-20 Apple IIGS Source Code Sampler $20.00
APDA-21 Apple II High-Speed SCSI Card Utilities $30.00
APDA-22 DOS 3.3 User's Manual $20.00
APDA-23 DOS 3.3 Programmer's Manual $20.00
APDA-24 Apple II Pascal 1.3 $69.00
APDA-25 Desktop Toolkit (ProDOS) $30.00
APDA-26 IIGS Firmware Reference 1 MB IIGS Update $12.00
APDA-27 GS/OS Device Driver Reference $29.00
APDA-30 HyperMover $15.00
APDA-31 Apple IIGS System 6.0 Release Notes (disk) $4.00
APDA-33 Apple IIGS System Disk 5.0.4 $24.00
APDA-34 HyperCard IIGS Developer's Kit $15.00
APDA-35 Apple II Appleshare Setup $15.00
APDA-37 APW & MPW Interfaces for System 6.0.1 $20.00
APDA-40 File Type Notes $25.00
APDA-41 Classic Apple Notes $20.00
APDA-42 IIGS Notes $30.00
APDA-43 Misc Notes $10.00
APDA-44 Apple II Pascal Notes $4.00
APDA-45 HyperCard IIGS Notes $3.00
APDA-46 Apple II Tech Notes Full Set $65.00
Apple II Addison-Wesley Books -----------------------------
The staff of Apple Computer wrote several programmer and hardware
developer reference books that are published through Addison-Wesley.
Here's a list of the Addison-Wesley books we currently have in stock.
We will be happy to try and order any Addison-Wesley programming
book. If you would like to order a book that is not on this list,
please let us know.
The big items that are currently missing are the toolbox reference
manuals and the GS/OS reference manuals. We are currently ordering
these books, and will add them to our price list as soon as we have
them in stock.
We will be happy to place your name on a list of people to notify
when a book (like the toolbox reference manuals) arrives here at the
Byte Works, but since we cannot anticipate when books might go out of
print, we will not actually accept orders for books that are not in
stock.
AW-04 Apple IIGS Hardware Reference $26.95
AW-08 Apple IIe Technical Reference Manual $24.95
AW-09 Applesoft Tutorial $29.95
AW-05 Programmer's Introduction to the Apple IIGS $32.95
AW-06 Technical Introduction to the Apple IIGS $9.95
AW-10 Applesoft BASIC Programmer's Reference Manual $22.95
AW-07 Apple IIGS Firmware Reference $24.95
AW-11 ProDOS 8 Technical Reference Manual $29.95
AW-12 ImageWriter LQ Reference $22.95
AW-13 LaserWriter Reference $19.95
AW-14 Understanding Computer Networks $9.95
AW-15 Planning and Managing AppleTalk Networks $18.95
The Byte Works --------------
We're the Byte Works, famous for our programming tools for the
Apple II series of computers and now for our productivity tools for the
Apple IIGS, too!
Founded in 1980, we have a long history of serving the Apple II
community. We started with ORCA/M, a macro assembler that is one of two
programs ever to earn a perfect rating from Peelings II magazine. We
went on to write APW, Apple Computer s standard programming environment
for the Apple IIGS. We ve brought you dozens of other programs, too,
like ORCA/C, the award winning C compiler; ORCA/Pascal, the only
commercial object oriented language for the Apple II; and our Toolbox
Programming courses, which have introduced thousands to the world of
Apple IIGS toolbox programming. And don t forget HyperLogo and 3D
Logo, our fun, easy to use programming languages that can actually show
3D pictures on any color Apple IIGS!
Look for more innovative, fun, useful programs for your Apple IIGS
for us in the months to come. We're one company with a long term
commitment to our Apple IIGS customers!
Ordering --------
We accept Visa and MasterCard orders online or by phone, and personal
checks or school purchase orders by mail.
Please include $5 for shipping in the U.S. and Canada. For credit
card orders, we can charge exact shipping for our overseas customers.
If you need to know oversees shipping in advance, send your name,
address, what you are ordering and how you want it shipped (air or
surface), and we'll be happy to calculate the shipping charges.
For a printed copy of our complete product list, send your name, address,
and mention that you want our complete catalog.
Distribution ------------
This price list is designed for electronic distribution. Please
feel free to distribute it as widely as possible. In particular, we
greatly appreciate any efforts to place this catalog on electronic
bulletin boards, online services, club newsletters, and so forth.
(BYTEWORKS, CAT36, TOP2, MSG:5/M530)
ORCA/C BUG ALERT ORCA/C 2.0.2 shipped with a major problem: I left in
"""""""""""""""" some debug code, and missed that during testing because
my debugger runs silently with the debug code unless I tell it not to.
If you have ORCA/C 2.0.2, sit tight. We are currently mailing
ORCA/C 2.0.3 to _everyone_ who got ORCA/C 2.0.2 from us. So unless you
moved since you ordered ORCA/C 2.0.2, you don't have to do anything to
get ORCA/C 2.0.3...except watch your mailbox!
Mike Westerfield
(BYTEWORKS, CAT36, TOP11, MSG:268/M530)
BUFFER ERRORS IN ORCA SHELL I seem to get an error often in the Orca 2.0
""""""""""""""""""""""""""" shell environment. I wonder if anyone else
out there does? When using the "copy" command, I frequently get GS/OS
error, buffer too small, which seams to indicate that Orca shell or the
copy command has issued a GS/OS call with a poorly formed result buffer.
Anyway, this error occurs usually after compiling a number of modules,
and particularly if I use the rez compiler. It never happends if I run
Orca and then issue the copy command. I can look into this further to
better characterize the problem, but I first wanted to mention it here
and see if this is a known bug and if there is a fix or work-around
known as well.
Thanks, Bill {W.TUDOR}
(W.TUDOR, CAT36, TOP16, MSG:55/M530)
<<<<< I get this error a lot, usually after a long compile. Sometimes I
""""" can recompile a dozen times without seeing it. Sometimes it shows
up on the first compile. Sometimes I never see it at all. Like you, I've
only seen it happen while doing a copy after a compile.
- Tony Ward
(A2.TONY [A2 Librarian], CAT36, TOP16, MSG:56/M530)
>>>>> Yes, this was fixed in the July '94 round of updates. The 2.0.3
""""" shell has the fix.
Mike Westerfield
(BYTEWORKS, CAT36, TOP16, MSG:58/M530)
[EOA]
[LIB]//////////////////////////////
LIBRARY BIT BONANZA /
/////////////////////////////////
HOT Files You Can Download
""""""""""""""""""""""""""
By Tim Buchheim
[T.BUCHHEIM]
>>> A2U course - Introduction to Applesoft Basic <<
"""""""""""""""""""""""""""""""""""""""""""""""""""""
File # 4239 ASF108INTRO.BXY (ALL)
Uploaded on 8/2/94 by A2PRO.HELP
About 7K (d/l time approx. 42 seconds @ 2400 baud)
ASF 108 - An Introduction to Applesoft BASIC
This is an archive packed with ShrinkIt which contains the introductory
lesson in this A2 University course.
Unpack with GS-ShrinkIt v1.1 or ShrinkIt v3.4.
File # 4242 ASF108LESS1.BXY (ALL)
Uploaded on 8/5/94 by A2PRO.HELP
About 14K (d/l time approx. 1 minute 24 seconds @ 2400 baud)
Here's lesson #1 of course ASF 108, "An Introduction to Applesoft
BASIC". The RTC for discussion of the course will be Tuesday, August 9,
1994.
File # 4257 ASF108LESS2.BXY (ALL)
Uploaded on 8/15/94 by A2PRO.HELP
About 14K (d/l time approx. 1 minute 24 seconds @ 2400 baud)
Here's lesson #2 (with some cool sample source included) of ASF 108,
An Introduction to Applesoft, with Professor J. Nathaniel Sloan. The
Real Time Conference to discuss this lesson is August 16, 1994.
File # 4266 ASF108LESS3.BXY (ALL)
Uploaded on 8/21/94 by A2PRO.HELP
About 17K (d/l time approx. 1 minute 42 seconds @ 2400 baud)
Here it is. The long-awaited sequel to lesson two, it's.. Lesson
Three!!! of "An Introduction to Applesoft BASIC", ASF 108, an A2
University course with professor J. Nathaniel Sloan. The RTC for
discussion of this lesson is on Tuesday, August 23rd.
>>> Shell Utilities <<<
""""""""""""""""""""""""""
File # 4260 DUMPF.1.0.BXY (GS)
Uploaded on 8/17/94 by JAY.KRELL
About 34K (d/l time approx. 3 minutes 24 seconds @ 2400 baud)
Apple's DumpFile has proven rather useful to me, but I recently
found it very buggy on 64K files. DumpF is a quick, portable clone. It
dumps files in hex and/or ascii; will do resource forks on the IIGS. The
source shows how to read the keyboard almost directly under ORCA and GNO
2.x. Requires a shell. Tested with ORCA.
File # 4255 SETOPENMSG.BXY V1.1 (GS)
Uploaded on 8/15/94 by RICHARD.B
About 4K (d/l time approx. 24 seconds @ 2400 baud)
Allows you to set Message Centre message types $0001 and $0011 to
any number of pathnames (from a LNK file or OA-O) in Merlin-16+. If your
application supports the Message Centre, you can now force it to load
any number of files when it starts up, instead of manually opening them
each time you want to do a quick test.
>>> Bug-hunting Aids <<<
""""""""""""""""""""""""""
File # 4244 TTRAPPER.BXY V1.0 (GS)
Uploaded on 8/6/94 by RICHARD.B
About 4K (d/l time approx. 24 seconds @ 2400 baud)
Traps tool calls YOU select, and breaks into debug with all
registers valid. Allows match criteria for up to 26 bytes of parameter
data pushed before the call, with validity masking at the nibble level.
This CDA is really cool!
File # 4241 NHTRACKER.BXY V1.0 (GS)
Uploaded on 8/5/94 by RICHARD.B
About 4K (d/l time approx. 24 seconds @ 2400 baud)
Tracks _NewHandle calls into a 64K wrap around memory buffer.
Formats the _NewHandle calling parameters in ASCII so the buffer can be
viewed in memory or on disk. This is a quick hack designed to track down
obscure handle allocation bugs. Complete Merlin assembly source code
included.
>>> Miscellaneous <<<
"""""""""""""""""""""""
File # 4268 PUBSUB.BXY (GS)
Uploaded on 8/23/94 by BYTEWORKS
About 19K (d/l time approx. 1 minute 54 seconds @ 2400 baud)
Here's the files that describe Publish & Subscribe as implemented in
Quick Click Calc. These files will be useful to you if you decide to
implement Publish & Subscribe yoursef. We'll also refer to these files
in the conference on 29 Aug 94.
[EOA]
[RTC]//////////////////////////////
RTC WATCH /
/////////////////////////////////
Excerpts from Evening Escapades
"""""""""""""""""""""""""""""""
By Tim Buchheim
[T.BUCHHEIM]
>>> Patching Tools <<<
""""""""""""""""""""""""
<A2PRO.HELP> What can we do for you tonight, Bill?
<W.TUDOR> Nothin'. Unless you wish to explain how to patch a tool
function from a CDev.
Cause the method I used don't work with HI.
<A2PRO.HELP> Bill: Uh, sure!
Make the patch when you get bootMessage.
<W.TUDOR> I was playing around today. No luck.
OK, I do that now.
<A2PRO.HELP> Then, call _GetNewID to get a new $5000 range ID for
yourself.
<W.TUDOR> Let'me load the code. One moment...
<A2PRO.HELP> OK.
Well, actually...
Check out page 100 of Programmer's Reference to System 6.0.
Do what it says, then make a JSL to the code resource you
loaded, which should install the patch.
That's the cleanest way.
<W.TUDOR> That is what I am doing.
<A2PRO.HELP> Hmm.
<W.TUDOR> Exactly. (So far)
<A2PRO.HELP> That should be all you need to do; follow page 100 and
use the loaded code resource to install the patch.
<A2PRO.HELP> Umm... you are calling _LoadOneTool and then
_SetDefaultTPT, aren't you? (Window Manager is a RAM tool
on ROM 01).
<W.TUDOR> Check for sysy 6.0, load a code resource, setHandleID on it
with the new user ID, Oh, one little catch...
Wait, maybe I am not loading the tool. One moment...
Shoot, code resource is a different file...
Oops, just a WindStatus being done. Maybe thats the
problem.
<A2PRO.HELP> Hmm.. That should return FALSE, with the carry flag set.
Well, yeah, you're going to need to load the tool if it's
not loaded.
<W.TUDOR> I am not checking carry flag on that call (bad).
(Wonder how this thing worked at all)
<A2PRO.HELP> Are you pre-initializing the result space to 0?
<W.TUDOR> Anyway, then I do GetTSPtr/SetTSPtr. Is that part correct?
Yes.
<A2PRO.HELP> Then the carry flag shouldn't matter... it would still be 0
if it's not active.
Bill: The Window Manager won't have a TSPtr if it's not
loaded.
<W.TUDOR> I'll have to check out the "smart" macro to answer the
question. I don't check for errors after GetTSPtr.
OK, assuming that I now load the tool (if needed), then I
just do the Get/Set thingee, right?
<A2PRO.HELP> Right, per the technote on tool patching. Make sure you
call _SetDefaultTPT, or your patch will be unloaded when
the Window Manager is reloaded from disk.
<W.TUDOR> (Maybe this is why the code worked when double-clicked from
Finder but not when booting). Yep, ok.
<A2PRO.HELP> That should be everything, then. :-)
<W.TUDOR> Well, I am off. Sloanie Thanks. If you see a new Minimizer
in a few days you'll know why :-) GNite.
>>> Updating Windows When Using _DoModalWindow From NDAs <<<
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
<A2.TONY> TBR is not very specific about UpdateWindow. What _exactly_
does it do? I mean, it says it's "roughly" equivilant to
BeginUpdate, StartDrawing, EndUpdate.
<T.BUCHHEIM> Exactly? well, I don't know, I haven't disassembled it ;)
<A2.TONY> I'm still hacking away at DoModalWindow and I want to use
UpdateWindow to update background windows while the
Resource Manager is active inside an NDA. Ack!!! I know
it's ugly, but I'm hacking away to get it to work :)
<SNAKEBYTES> Tony- have you gotten DoModalWindow to work at all yet??
<A2.TONY> Yes, but only if I put the window in the data fork (or load
it from the resource then shutdown the Resource Manager
first)
<T.BUCHHEIM> UpdateWindow will only work with windows which DON'T need
to call GS/OS (or resource manager) as I understood it
(and have bits set to say that)
<A2.TONY> Right Tim, I've played with those bits :)
<T.BUCHHEIM> ahh...okay :)
<A2.TONY> DoModalWindow was definitely not meant for NDAs to use. But
since ShadowWrite does it, _I_ want to do it too :)
Errr, I mean it wasn't meant for NDAs that use the Resource
Manager.
<SNAKEBYTES> hmm...I could never get DMW to work....keeps blowing up the
system for me :(
<T.MYERS4> err....you're not supposed to use them in nda's....hmmmm
<T.BUCHHEIM> well, you can use it, but not have background windows
update, or at least not always
<SNAKEBYTES> thusly I have to keep using my nasty pre-System 6 "Virtual
Modal Window" routines :)
<A2.TONY> Right, background window's cannot be allowed to update
within an NDA that has the Resource Manager started.
<A2.TONY> That's what the technotes say...I don't believe it :)
<T.MYERS4> I was using DoModalWindow() for all my 'modal/non_moving'
windows in a couple of my nda's, Tony.
<A2.TONY> Yes Todd, but did you have the Resource Manager open?
<T.MYERS4> wide open :)
<A2.TONY> Oh, non-moving windows? Mine moves.
<T.BUCHHEIM> then background windows won't update in most cases
<A2.TONY> Then you probably had the bit set to NOT update other
windows.
<T.MYERS4> I didn't know what would happen...so I set the bits to
ignore background updates.
<T.BUCHHEIM> (system windows will update, and probably windows with that
bit set which tells the window manager that the content
draw proc doesn't care about the current environment)
<A2.TONY> I want a moveable modal window, and access to the menu bar
:)
<T.BUCHHEIM> umm...how you handling dimming menus?
<A2.TONY> Yes, system windows update automatically regardless of the
Resource Manager status. That's why I think it must be
possible to update application windows too.
<T.BUCHHEIM> (or are you putting your own menubar there during the modal
window? :)
<A2.TONY> I don't Tim, not yet anyway. It's ugly so far.
But having access to the Apple menu while a modal window is
in front is pretty neat. And you can activate other NDA
windows too :)
<T.BUCHHEIM> Tony: that's because the desk manager is smart enough to
set the resource manager so the system windows can access
their resource forks...Update window doesn't do it, I don't
think..
<T.BUCHHEIM> Tony: yep!
<A2.TONY> Right Tim, but if the system can do that for system
windows, I can surely find a way to do it for application
windows.
<T.BUCHHEIM> yep
<A2.TONY> I don't really have a good reason for wanting to do it, I
just want to see if it can be done :)
<T.BUCHHEIM> I'd get the userID of the memory the content draw proc is
in, and set the resource app from that hmm...I think my
idea will work...
I don't see any problems with it, and it's legal
<A2.TONY> funky, but legal. Probably close to how the system does it.
Actually, the system probably keeps a list of IDs for
active system windows, right?
<T.BUCHHEIM> it's in the aux window record thingie
>>> Deciphering C <<<
""""""""""""""""""""""
<T.MORALES> Question. Any of ya good at pre-ANSI C?
I need to find out what ** means, and I can't find it in
any of my ANSI references.
<JUST.DAVE> ** is a pointer to a pointer.
<W.TUDOR> Same as *, but 1 more time
<JUST.DAVE> just like a handle... kind of.
<T.MORALES> Ptr to Ptr, why would you ever need this, and isn't this
like a Handle?
<W.TUDOR> In a declaration, two ** mean that the variables is a
pointer to a pointer. (Which is a handle in Apple speak.
<JUST.DAVE> That's exactly why you'd need it.
It's an instant dereference. :)
<W.TUDOR> When you use ** to dereference a handle, you get the value.
<T.MORALES> I've seen some source code that does, "Char **argv," right
after the main function.
<W.TUDOR> You can also have ******* BTW.
<T.MORALES> And I thought Argv should be declared at, "*Argv[]".
<W.TUDOR> Same thing.
<T.MORALES> How is it the same?
*Argv[] is an array.
<W.TUDOR> This is because array[0] = *array, and array[5] =
*(array+5). Get it?
The array name is a _pointer_. And agrv is an array of
pointers!
<T.MORALES> I see.
<W.TUDOR> therefore, well, now you know why some people don't like C
<T.MORALES> Well, I learned it the
"int main(int argc, char *argv[])" way,
and seeing the other well, kind of shocked me.
I prefer to include the types with the function name, not
on the line below.
<W.TUDOR> Some people like playing with pointers only, and never
arrays. Does not really matter.
<T.MORALES> Not I. But then again, before last May, I knew nothing of
C.
Only problem with C, for me, is the many different ways
people use it.
<JUST.DAVE> C is TOO flexible...
[EOA]
[CAM]//////////////////////////////
CAMPUS GREEN /
/////////////////////////////////
Latest on Current Courses
"""""""""""""""""""""""""
By Nate Trost
[A2PRO.GELAMP]
The A2U 'Introduction to Applesoft BASIC' course continues! Here
are the current lessons available for download in the A2Pro library:
#4239: Course Introduction
#4242: Lesson 1
#4257: Lesson 2
#4266: Lesson 3
The final lesson, Lesson 4, should be uploaded in early September,
remember, while the course is going on, you can talk with course
professor, Nathaniel Sloan, every Tuesday evening at 9:30 Eastern.
[EOA]
[PUB]//////////////////////////////
PUBLISH AND SUBSCRIBE /
/////////////////////////////////
An A2Pro RTC Transcript
"""""""""""""""""""""""
With Mike Westerfield
[BYTEWORKS]
<JUST.DAVE> I'd like to welcome everyone here tonight! And I'd
especially like to welcome Mike Westerfield.
<BYTEWORKS> Thanks!
<JUST.DAVE> He'll be talking about his Publish and Subscribe
techniques tonight, and probably a little about Quick Click
Calc, too, I imagine...
<BYTEWORKS> I'd like to start with a _very_ brief intro, mostly
vocalulary. Feel free to start queuing up questions as we
go...
Publish & Subscribe is a way for documents to communicate
automatically. It works like, and... ...to a large degree
is implemented as, automated copy & paste. Here's how it
works, with the terms that will help tonight: The
Publisher is a document that contains information which
is selected and
published. The edition, or edition file,
is the file written by the publisher. The subscriber
(there can be more than one) uses the edition file. When
a publisher document is saved, any edition files are
updated. (This can be done manually, too.) When a
subscriber document is opened, it scans all of the
edition files it uses, updating any editions with new
information. And that's it, in a nutshell.
Hopefully you all got the file formats & so forth from the
files I uploaded or from KFest. If not, they are in the library.
Well, while you're trying to think of some questions, I'll
mention some of the other stuff in the download. It also
has the source code used to read & write atomic files,
which is the file format used both for editions and for
the Quick Click Calc spreadsheet file. In addition (not
edition!) you'll find the code used to encrypt/decrypt
QCCalc files.
<JUST.DAVE> OK, first up is Sheppy.
<POWERPC.PRO> How does a subscriber know where to put the information
in the edition? If the edition data is a spreadsheet
fragment,... and the subscriber is a word processor, how
does the word processor application know where to insert
the spreadsheet fragment in the WP doc?
<BYTEWORKS> In general, a WP would have imbedded or parallel commands
for things like rulers, pictures, and so forth. One of
those imbedded commands would be a command that identified
the location, and perhaps size, of an edition. It would
also have the file name for the edition. When the WP
opened the document, it would load the information &
"paste" it. In the SS, there is a linked list of edition
information which contains the cell of the top/left corner
and the file name. All of the other information is in the
edition itself.
<POWERPC.PRO> Okay, but if more stuff were added to the edition, how
does the subscriber avoid losing track of information?
If a new atom is added to the edition, in other words,
how does the word processor keep track of the right one to
use?
<BYTEWORKS> The subscriber only updates the information when the file
is loaded or when the user specifically asks for an
update. That keeps it from happening while the document
is just sitting there with a blinking cursor. And, since
each edition contains a single thing (read a single
scrap), there is never an additional atom to read--you
always read just one.
<POWERPC.PRO> Say the spreadsheet is publishing four sections of a
document into an edition and the WP only wants one of them.
How does the WP get the right one?
Okay... each edition contains a single item. Got it; I
thought an edition contained multiple scraps.
<JUST.DAVE> OK. Next up is Jawaid.
<PROCYON.INC> Blammo, Dave. :-)
What exactly is an atomic file? Can you give an example
from something I might be familiar with?
<BYTEWORKS> Sure. An atomic file is an organization for files that
allows the addition of new or extra information, yet
doesn't break the application that doesn't know or care
about the other information. The edition file is a
typcial example of an atomic file. It contains a single
paster atom. (Each atom consists of a 4 letter atom name
& a 4 byte length, followed by data). This main atom
contains other atoms for things like the publisher
document name, the publishing application, and one atom
each for each of the scrap types that the publisher
created.
So, for example, the SS opens an atoand looks for an atom
with a name indiacting it's a SS scrap (SS =
spreadsheet), then does the same thing it would do for a
paste. It doesn't know, or care, if there is a Paint
style scrap there. A word processor looks for a text
scrap, not knowing, caring, or getting confused by the SS
scrap.
<PROCYON.INC> Okay, interesting. I guess TIFF files are atomic as
well. Got it.
<BYTEWORKS> As are ASIF files.
<JUST.DAVE> OK, that's me. :) I had a question going on from
what Sheppy was saying. If, for example, several cells
from the same spreadsheet were published, would there be a
seperate edition file for each cell, or do they all go in
the same edition file?
<BYTEWORKS> If you publish a range of cells, say by selecting cells
A1:F10, they would all go in one edition. If you
published two disjoint selectinos of cells, say C5 and
B7:F10, they would go in two separate editions. You can
think of them exactly as you would two scraps in a
scrapbook: each scrapbook entry would correspond to one
edition file.
<JUST.DAVE> OK, so in Sheppy's example, where a Word Processor
only wanted one item from a SS publisher, you would have
to make sure that the item in question was published by
itself...
<BYTEWORKS> If he only wanted one cell, yes. What would be more
likely is that he would want a range of cells for, say a
financial summary. In that case, the WP would probably
use the tabs separating a SS text scrap as formatting
clues, and show a formatted range of cells. Once cell
would work, though.
<JUST.DAVE> One other thing while we're waiting for more questions...
in QCCalc, can you publish the same cell to more than one
edition? (like once in a range, and once by itself for
example)
<BYTEWORKS> Yes. You can also subscribe to an edition by formula or
by value, just like you can paste two ways.
I'll also be happy to discuss the encryption routines in
QCCalc, which are also in the source code I uploaded. If
you have any questions on that, go for it.
<POWERPC.PRO> Editions published by QCCalc... is style and color
information included?
<BYTEWORKS> Yes. You get two scraps. One contains everything normally
handled by a copy/paste inside the SS itself. In fact,
the same code handles both copy/paste and
publish/subscribe. The other scrap is a text scrap.
<JUST.DAVE> OK, go ahead, Harold.
<H.HISLOP> Speaking of the encryption (yes, I'll be snagging the
source, thanks) Does your routine permit an external
"noise" file (random number) for these routines?
<BYTEWORKS> The encryption is a password encryption method. The
password is used as the seed to a random number generator.
Random numbers are generated and EORed with successive
bytes of the file. It's definitely breakable, but due to
the rather long typical period of the random number
generator (up to 1.8e19 numbers before repeating) it's
not succeptable to brute force, trial and error methods.
<H.HISLOP> Ok, so you are totally reliant on your own random number
generator then, thats what I figured (nothing wrong with
this :) How random is the generator? (eg: does it produce
the same pattern for the same seed each time?)
<BYTEWORKS> It does produce the same pattern for the same seed each
time. That's sort of important when it comes time to
_decrypt_ the file. :) As for how good it is, it passes
all of the normal tests for randomness with flying
colors. In fact, Glen Bredon and I got into a discussion
about people who write their own random number generators
and how they are tested here on AOL a few years back. He
went so far ]as to use some tests I still don't think are
fair for this generator, and it still passed.
<BYTEWORKS> Oops Here in A2Pro, not AOL.
<H.HISLOP> Ah, the generator has "Glens Blessings", that tells me a
lot :) Thanks.
<B.WELLS5> I just got here and missed a bunch, but could you tell me
what is the benefit of writing for P&S in my applications?
<BYTEWORKS> It depends on the application. What did you have in mind?
Basically, P&S makes sense for any document designed to
use the Scrap Manager that will typically use, or produce
information for use by, another document.
<B.WELLS5> So P&S goes beyond the simple 'clipboard' and allows you
to do things like?
<BYTEWORKS> Basically, P&S is copy and paste between documents, but
the copy is done every time the publsihing document is
saved, and the subscribing is done every time the
subscribing document is opened. So, for example,
publishing from a spreadsheet and subscribing from a word
processor or page layout program is a no-brainer: it's
great. Publish & Subscribe would be pretty worthless in
an arcade game.
<B.WELLS5> Well, when I do write something other than utilities,
(like a WP or something :) I'll be sure to use P&S.. How
much is it, BTW?
<BYTEWORKS> QCCalc is $60. The documentation is free; you can get it
in the A2Pro library. No license fees or anything,
either. There is a requirement for a copyright notice if
you actually use my code, but not if you just use the
ideas.
(documentation -=> P&S description, not the QCCalc book)
<B.WELLS5> Sounds good. I'll d/l the information in my next GEM sweep
:)
<H.HISLOP> So.. I have a SS that publishes, and lets say a SS that
subscribes... On sucessive openings of the subscribing SS,
how does it know that it has already "updated" from the
publication (which is still hanging around in it's
original... form for a WP to use). Or does the
subscribing SS "update" every time it's opened, even if
the publication hasn't changed? (haven't read any docs
yet, so this may be moot)
<BYTEWORKS> You could do either: Update every time you open or look at
the Mod date. The only thing to keep in mind is that the
subscriber should remember the old information, so if the
edition is missing or busy, it can display the last known
edition.
<H.HISLOP> ummm... didn't quite hit the mark... let me expand some...
The subscribing SS "updates" from the publication the
first time it's opened. What about the second time it's
opened? (with the publication not having changed). Or ar
you saying that the subscriber should keep track of the
mod date / time of the last used publication (which could
get sticky in a hurry...)
<BYTEWORKS> The subscriber has the option of doing either: It can keep
track of the mod date and only update the subscription if
it changes, or it can just update the subscription all
the time. It depends a little on the cost of updating.
That's not high in the SS, so it just rereads the edition
each time. ga Ok (re-reads the edition each time if low
overhead) That's what I was suspecting. Done (I think.
Maybe that's not right... One moment.) Yes, it's updating
every time.
[*][*][*]
[EOA]
[LOG]//////////////////////////////
LOG OFF /
/////////////////////////////////
GEnieLamp Information
"""""""""""""""""""""
o COMMENTS: Contacting GEnieLamp
o GEnieLamp STAFF: Who Are We?
GEnieLamp Information GEnieLamp is published on the 1st of every month
""""""""""""""""""""" on GEnie page 515. You can also find GEnieLamp on
the main menus in the following computing RoundTables.
RoundTable Keyword GEnie Page RoundTable Keyword GEnie Page
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
DigiPub DIGIPUB 1395 Atari ST ST 475
Macintosh MAC 605 IBM PC IBMPC 615
Apple II A2 645 Apple II Dev. A2PRO 530
Macintosh Dev. MACPRO 480 Geoworks GEOWORKS 1050
BBS BBS 610 CE Software CESOFTWARE 1005
Mini/Mainframe MAINFRAME 1145 Programming PROGRAMMING 1445
Data Comm. DATACOMM 1450 Windows WINDOWS 1335
GEnieLamp is also distributed on CrossNet and many public and
commercial BBS systems worldwide.
o To reach GEnieLamp on Internet send mail to genielamp@genie.geis.com
o Current issues of all versions of GEnieLamp are File Requestable
(FREQable) via FidoNet (Zones 1 through 6) from 1:128/51 and via
OURNet (Zone 65) from 65:8130/3. SysOps should use the following
"magic names" to request the current issue of the indicated
GEnieLamp platform (FREQ FILES for names of back issues of GEnieLamp
IBM):
Platform Magic Name To Use
"""""""" """""""""""""""""
GEnieLamp IBM .................. GLIBM
GEnieLamp ST ................... GLST
GEnieLamp A2Pro ................ GLA2PRO
GEnieLamp Macintosh ............ GLMAC
GEnieLamp TX2 .................. GLTX2
GEnieLamp A2 ................... GLA2
GEnieLamp Windows .............. GLWIN
o Back issues of GEnieLamp are available in the DigiPub RoundTable
Library #2 on page 1395 (M1395;3).
o GEnieLamp pays for articles submitted and published with online
GEnie credit time. Upload submissions in ASCII format to library
#42 in the DigiPub RoundTable on page 1395 (M1395;3) or Email it to
GENIELAMP. On Internet send it to: genielamp@genie.geis.com
o We welcome and respond to all E-Mail. To leave comments, suggestions
or just to say hi, you can contact us in the DigiPub RoundTable
(M1395) or send GE Mail to John Peters at [GENIELAMP] on page 200.
o If you would like to meet the GEnieLamp staff "live" we meet every
Wednesday night in the Digi*Pub Real-Time Conference at 9:00 EDT
(M1395;2).
o The Digital Publishing RoundTable is for people who are interested
in pursuing publication of their work electronically on GEnie or via
disk-based media. For those looking for online publications, the
DigiPub Software Libraries offer online magazines, newsletters,
short-stories, poetry and other various text oriented articles for
downloading to your computer. Also available are writers' tools and
'Hyper-utilties' for text presentation on most computer systems. In
the DigiPub Bulletin Board you can converse with people in the
digital publishing industry, meet editors from some of the top
electronic publications and get hints and tips on how to go about
publishing your own digital book. The DigiPub RoundTable is the
official online service for the Digital Publishing Association. To
get there type DIGIPUB or M1395 at any GEnie prompt.
>>> GEnieLamp STAFF <<<
"""""""""""""""""""""""
GEnieLamp o John Peters [GENIELAMP] Publisher/Editor
"""""""""
IBM o Bob Connors [DR.BOB] IBM EDITOR
""" o Nancy Thomas [N.NOWINSON] MultiMedia Editor/Writer
o Brad Biondo [B.BIONDO] IBM Staff Writer
o Tika Carr [T.CARR4] IBM Staff Writer
o Dave Nienow [D.NIENOW] IBM Staff Writer
o Don Lokke [D.LOKKE] Cartoonist
o Sandy Wolf [S.WOLF4] Contributing Columnist
WINDOWS o Tippy Martinez [WIN.LAMP] WINDOWS EDITOR
""""""" o John Osarczuk [J.OSARCZUK] Asst Editor/Columnist
o Rick Ruhl [RICKER] Windows Sysop/Columnist
o Brad Biondo [B.BIONDO] Windows Staff Writer
o Rick Pitonyak [R.PITONYAK] Windows Staff Writer
o Ed Williams [E.WILLIAMS24] Windows Staff Writer
o Dave Nienow [D.NIENOW] Windows Staff Writer
MACINTOSH o Richard Vega [GELAMP.MAC] MACINTOSH EDITOR
""""""""" o Tom Trinko [T.TRINKO] Mac Staff Writer
o Bret Fledderjohn [FLEDDERJOHN] Mac Staff Writer
o Ricky J. Vega [GELAMP.MAC] Mac Staff Writer
ATARI ST o John Gniewkowski [GENIELAMP.ST] ATARI ST EDITOR
"""""""" o Mel Motogawa [M.MOTOGAWA] ST Staff Writer
o Sheldon Winick [S.WINICK] ST Staff Writer
o Terry Quinn [TQUINN] ST Staff Writer
o Richard Brown [R.BROWN30] ST Staff Writer
o Al Fasoldt [A.FASOLDT] ST Staff Writer
o Fred Koch [F.KOCH] ST Staff Writer
ATARI ST/TX2 o Cliff Allen [C.ALLEN17] EDITOR/TX2
""""""""""""
ATARI [PR] o Bruce Faulkner [R.FAULKNER4] EDITOR/GEnieLamp [PR]
""""""""""
APPLE II o Doug Cuff [EDITOR.A2] EDITOR
"""""""" o Phil Shapiro [P.SHAPIRO1] A2 Staff Writer
o Darrel Raines [D.RAINES] A2 Staff Writer
o Gina E. Saikin [A2.GENA] A2 Staff Writer
o Charlie Hartley [C.HARTLEY3] A2 Staff Writer
A2Pro o Nate C. Trost [A2PRO.GELAMP] EDITOR
""""" o Tim Buchheim [T.BUCHHEIM] Co-Editor
ETC. o Jim Lubin [J.LUBIN] Add Aladdin Scripts
"""" o Scott Garrigus [S.GARRIGUS] Search-ME!
o Mike White [MWHITE] (oo) / DigiPub SysOp
o Susie Oviatt [SUSIE] ASCII Artist
o Al Fasoldt [A.FASOLDT] Contributing Columnist
o Phil Shapiro [P.SHAPIRO1] Contributing Columnist
o Sandy Wolf [S.WOLF4] Contributing Columnist
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
Bulletin board messages are reprinted verbatim, and are included in
this publication with permission from GEnie and the source RoundTable.
GEnie, GEnieLamp Online Magazines, and T/TalkNet Online Publishing do
not guarantee the accuracy or suitability of any information included
herein. Opinions expressed are those of the individual, and do not
represent opinions of GEnie, GEnielamp Online Magazines, or T/TalkNet
Online Publishing.
Material published in this edition may be reprinted under the follow-
ing terms only. Reprint permission granted, unless otherwise noted,
to registered computer user groups and not for profit publications.
All articles must remain unedited and include the issue number and
author at the top of each article reprinted. Opinions present herein
are those of the individual authors and do not necessarily reflect
those of the publisher or staff of GEnieLamp. We reserve the right to
edit all letters and copy. Please include the following at the end or
the beginning of all reprints:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
(c) Copyright 1994 T/TalkNET Online Publishing and GEnie. To join
GEnie, set your modem to 2400 baud (or less) and half duplex (local
echo). Have the modem dial 1-800-638-8369. When you get a CONNECT
message, type HHH. At the U#= prompt, type: JOINGENIE and hit the
[return] key. When you get the prompt asking for the signup code, type
DSD524 and hit RETURN. The system will then prompt you for your
sign-up information. Call (voice) 1-800-638-9636 for more information.
////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
[EOF]
