yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) (07/08/89)
I'm having problems maintaining a configuration file for my
application. It lives in the System Folder and is a file w/a
resource fork containing some data that gets read in when I
open a certain type of document window in my app, and then gets
written out when I close the window.
My problem is when I re-open the window in the same session,
and try to reread the resource, the GetResource call goofs up.
Below are two code fragments, ReadConfig() gets called when I
open my document, the first time it's called it works fine,
GetResource returns a handle that points to my data, and
dataLen is correct. Then when I close the document I call
WriteConfig. The data that I'm maintaining may have changed and
the config file data would therefore be out of date, so I
automatically clear it, create a new handle, stream my data
into the handle, and add the resource. If I quit my app at this
point and examine my config file w/ResEdit, the data looks
hunky-dory. But if I instead try to reopen my document window,
thereby calling ReadConfig again, the GetResource mysteriously
returns some bogus handle (I think) that points to nothing
significant, and dataLen is bad as well.
ResError() never returns a bad value, to the best of my
knowledge. The value of CurResFile() never changes when I check
it a various locations around this code. The config file is
opened at the program start by a call to OpenResFile, which is
set to look in the System Folder. I'm not doing anything
significant, I guess, between opening, closing, and then
opening my document.
Any ideas/comments?
ReadConfig()
{ Handle dataHdl;
long dataLen;
dataHdl = GetResource('DATA', 128);
dataLen = SizeResource(dataHdl);
/* At this point I stream the data into
* a application maintained structure. This
* data may change as the user interacts
* w/the app.
*/
}
WriteConfig()
{ Handle dataHdl;
Handle aHdl;
/* Zap the old data as it is most likely out of date */
dataHdl = GetResource('DATA', 128);
RmveResource(dataHdl);
WriteResource(dataHdl);
DisposHandle(dataHdl);
aHdl = NewHandle(DATA_SIZE);
/* At this point I init aHdl w/the data structure
* that I've maintained, in preparation for
* writing it back out.
*/
AddResource(aHdl, 'DATA', 128, "");
WriteResource(aHdl);
DisposHandle(aHdl);
}
////////////////////////////////////////////////////////////
Internet: yahnke@macc.wisc.edu
Phonenet: 608.262.8626
Mailnet: 1210 W. Dayton St., Madison WI, 53706
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\netnews@caen.engin.umich.edu (netnews) (07/08/89)
In article <2002@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: >I'm having problems maintaining a configuration file for my >application. It lives in the System Folder and is a file w/a >resource fork containing some data that gets read in when I >open a certain type of document window in my app, and then gets >written out when I close the window. > >My problem is when I re-open the window in the same session, >and try to reread the resource, the GetResource call goofs up. > >Below are two code fragments, ReadConfig() gets called when I >open my document, the first time it's called it works fine, >GetResource returns a handle that points to my data, and >dataLen is correct. Then when I close the document I call >WriteConfig. The data that I'm maintaining may have changed and >the config file data would therefore be out of date, so I >automatically clear it, create a new handle, stream my data >into the handle, and add the resource. If I quit my app at this >point and examine my config file w/ResEdit, the data looks >hunky-dory. But if I instead try to reopen my document window, >thereby calling ReadConfig again, the GetResource mysteriously >returns some bogus handle (I think) that points to nothing >significant, and dataLen is bad as well. > >ResError() never returns a bad value, to the best of my >knowledge. The value of CurResFile() never changes when I check >it a various locations around this code. The config file is >opened at the program start by a call to OpenResFile, which is >set to look in the System Folder. I'm not doing anything >significant, I guess, between opening, closing, and then >opening my document. > >Any ideas/comments? > >ReadConfig() >{ Handle dataHdl; > long dataLen; > > dataHdl = GetResource('DATA', 128); > dataLen = SizeResource(dataHdl); > > /* At this point I stream the data into > * a application maintained structure. This > * data may change as the user interacts > * w/the app. > */ >} > >WriteConfig() >{ Handle dataHdl; > Handle aHdl; > > /* Zap the old data as it is most likely out of date */ > dataHdl = GetResource('DATA', 128); > RmveResource(dataHdl); > WriteResource(dataHdl); > DisposHandle(dataHdl); ^^^^^^^^^^^^^^^^^^^^^^ > > aHdl = NewHandle(DATA_SIZE); > /* At this point I init aHdl w/the data structure > * that I've maintained, in preparation for > * writing it back out. > */ > AddResource(aHdl, 'DATA', 128, ""); > WriteResource(aHdl); > DisposHandle(aHdl); ^^^^^^^^^^^^^^^^^^^ >} Never, ever call DisposHandle for a resource! Use ReleaseResource to de-allocate the memory that a resource is using. _______________________________________________________________________________ Dean Yu | E-mail: mystone@{sol,caen}.engin.umich.edu University of Michigan | Real-mail: Dean Yu Computer Aided Engineering Network | 909 Church St | Apt C ===================================| Ann Arbor, MI 48104 | Phone: Given on a need to know basis, and "I am the Merit Host. I speak for | only if you're going to offer me a the bitstream." (In other words, | job... these are my very own opinions; | my employer wants to have nothing |=========================================== to do with them, or me.) | This space available for rent -------------------------------------------------------------------------------
tim@hoptoad.uucp (Tim Maroney) (07/09/89)
In article <2002@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: > /* Zap the old data as it is most likely out of date */ > dataHdl = GetResource('DATA', 128); > RmveResource(dataHdl); > WriteResource(dataHdl); > DisposHandle(dataHdl); You shouldn't call WriteResource after calling RmveResource. However, according to Inside Mac, WriteResource will do nothing if the handle isn't a resource, so this should not cause you any problems. Still, you ought to realize that after you call RmveResource, dataHdl is no longer a resource handle -- it's just an ordinary handle. However, as you can see from reading the description of RmveResource, you are right to call DisposHandle. (Sorry, Dean. If he calls ReleaseResource at this point, he's asking for trouble.) > aHdl = NewHandle(DATA_SIZE); > /* At this point I init aHdl w/the data structure > * that I've maintained, in preparation for > * writing it back out. > */ > AddResource(aHdl, 'DATA', 128, ""); > WriteResource(aHdl); > DisposHandle(aHdl); Here Dean Yu is correct to point out that you should not use DisposHandle. The actual handle that you pass to AddResource is inserted in the resource map; if you dispose of it, the resource map becomes bad. Future calls to GetResource will attempt to retrieve this handle, which is no longer valid after the DisposHandle. I want to point out that this is a very ineficient way of doing things. There's no need to remove and re-add the resource; you can just change it and call ChangedResource. This would reduce the memory operations involved in removing and re-adding (which can be quite significant, leading the entire resource map to be resized in RAM) and reduce the size and complexity of your routine. Your whole update routine would be just: aHdl = GetResource('DATA', 128); /* At this point I init aHdl w/the data structure * that I've maintained, in preparation for * writing it back out. */ ChangedResource(aHdl); WriteResource(aHdl); /* optional */ -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Those Mayas were sacrificing not only pagan children, but baptized Christian children, for crying out loud! And they were carrying out those sacrifices, those barbarities, with great savagery, without giving the victims the benefit of the humane types of death that the European Church accorded even to heretics and witches during that century, such as burning at the stake." -- Matthew Rosenblatt, rec.arts.books
yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) (07/10/89)
}I want to point out that this is a very ineficient way of doing }things. There's no need to remove and re-add the resource; you can }just change it and call ChangedResource. This would reduce the memory }operations involved in removing and re-adding (which can be quite }significant, leading the entire resource map to be resized in RAM) and }reduce the size and complexity of your routine. Your whole update }routine would be just: } } aHdl = GetResource('DATA', 128); } /* At this point I init aHdl w/the data structure } * that I've maintained, in preparation for } * writing it back out. } */ } ChangedResource(aHdl); } WriteResource(aHdl); /* optional */ This looks good. My only statement is that my DATA will more than likely change size between reading it and writing it. In which case I would have to do a SetHandleSize, correct? //////////////////////////////////////////////////////////// Internet: yahnke@macc.wisc.edu Phonenet: 608.262.8626 Mailnet: 1210 W. Dayton St., Madison WI, 53706 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
tim@hoptoad.uucp (Tim Maroney) (07/10/89)
In article <2013@dogie.macc.wisc.edu> yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: > >This looks good. My only statement is that my DATA will more than >likely change size between reading it and writing it. In which >case I would have to do a SetHandleSize, correct? Yes, exactly. Sorry for not mentioning this; since your posted code said "aHdl = NewHandle(DATA_SIZE);" I assumed that DATA_SIZE was a constant and the resource would not be changing size between incarnations. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Those Mayas were sacrificing not only pagan children, but baptized Christian children, for crying out loud! And they were carrying out those sacrifices, those barbarities, with great savagery, without giving the victims the benefit of the humane types of death that the European Church accorded even to heretics and witches during that century, such as burning at the stake." -- Matthew Rosenblatt, rec.arts.books
amanda@intercon.uu.net (Amanda Walker) (07/11/89)
In article <2013@dogie.macc.wisc.edu>, yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) writes: > This looks good. My only statement is that my DATA will more than > likely change size between reading it and writing it. In which > case I would have to do a SetHandleSize, correct? There's another approach, which I use and have never had any problems with, and goes something like this: read_settings: OpenResFile // open the settings file GetResource // get settings resource DetachResource // detach it from the resource map CloseResFile // close the settings file at this point, my settings resource is just another handle, which I can dispose of after I'm done with it. write_settings: CreateResFile (if it's not already there) OpenResFile // open the settings file if (GetResource) // if there's an old setting resource, RmveResource // remove it AddResource // add the current settings as a resource CloseResFile // close the settings file This way, I don't have to worry about the resource changing size, or whatever. As another trick, you can put a default settings resource in your application, so that you don't have to worry about the settings file not being there the first time. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
tim@hoptoad.uucp (Tim Maroney) (07/11/89)
In article <1165@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >write_settings: > CreateResFile (if it's not already there) > OpenResFile // open the settings file > if (GetResource) // if there's an old setting resource, > RmveResource // remove it > AddResource // add the current settings as a resource > CloseResFile // close the settings file Amanda, this is exactly the approach Ross Yahnke described in his message! What are you contributing by reading it right back to him? As I pointed out, this approach is terribly inefficient in terms of memory usage, since the whole resource map is getting resized and reshuffled twice. >As another trick, you can put a default settings resource in >your application, so that you don't have to worry about the settings file >not being there the first time. Except that if you do this using your pseudocode, the default settings resource in the application file will be removed. Do I have to explain why it's a no-no to write to your application file? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "The time is gone, the song is over. Thought I'd something more to say." - Roger Waters, Time
Greg@AppleLink.Apple.Com (Greggy) (07/11/89)
In article <1165@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > There's another approach, which I use and have never had any problems > with, and goes something like this: > > read_settings: > OpenResFile // open the settings file > GetResource // get settings resource > DetachResource // detach it from the resource map > CloseResFile // close the settings file > > at this point, my settings resource is just another handle, which I can > dispose of after I'm done with it. > > write_settings: > CreateResFile (if it's not already there) > OpenResFile // open the settings file > if (GetResource) // if there's an old setting resource, > RmveResource // remove it > AddResource // add the current settings as a resource > CloseResFile // close the settings file > > This way, I don't have to worry about the resource changing size, or > whatever. As another trick, you can put a default settings resource in > your application, so that you don't have to worry about the settings file > not being there the first time. You could even SetResLoad( FALSE ) before the GetResource call in write_settings to prevent the old settings from needing some of your precious heap space right before you nuke them! > -- > Amanda Walker > InterCon Systems Corporation > amanda@intercon.uu.net | ...!uunet!intercon!amanda > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Greg Marriott + AppleLink: Greg + + Just Some Guy + + + "My phone is always busy" + Internet: Greg@AppleLink.Apple.Com + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Apple Computer, Inc. + + 20525 Mariani Ave, MS-46z, Cupertino, CA 95014 + + (408)974-busy + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
stores@unix.SRI.COM (Matt Mora) (07/11/89)
In article <7930@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <1165@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > >>As another trick, you can put a default settings resource in >>your application, so that you don't have to worry about the settings file >>not being there the first time. > >Except that if you do this using your pseudocode, the default settings >resource in the application file will be removed. Do I have to explain >why it's a no-no to write to your application file? >-- >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com >Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 Tim, I don't think Amanda ment to write to the application resource, (I hope not) I think she ment to have the defaults available in the application so that if the pref file was removed you wont get a stupid dialog saying "Can't find pref file exiting to the finder" (ala superpaint). Also Tom Lippincott in another article said: "On a slightly related issue, does it bother anyone else that most programs will put a preferences file in the system folder even when the user hasn't given any preferences? I think that if there's been no change from the default, there's no reason to make the file." I think that is an excellent point. About the "remebering the state of things" I would like to see some sort of standard about text file resources. It would be wonderful for my appliction to be able to read a text file and get the font, font size, window size/position and cursor location no matter what application created it. I would also like to be able to tell the finder a default text editor so that if the appliction that created it is not around, the finder will open the document with the default editor. I would also like to see all word processing documents save the text undecoded. (maybe they all do that now) so if i want I could have a text editor open the plain text. I know, I want way too much -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
amanda@intercon.uu.net (Amanda Walker) (07/12/89)
In article <7930@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > Amanda, this is exactly the approach Ross Yahnke described in his > message! What are you contributing by reading it right back to him? Hmm. You're right. Oops. My apologies. I seem to have missed the original article. Our machine was dropping incoming news on the floor for a while recently. > this approach is terribly inefficient in terms of > memory usage, since the whole resource map is getting resized and > reshuffled twice. That makes sense, although I tend to regard worrying about memory efficiency while writing to resource files to be on the order of tilting at windmills :-). In particular, I would think that resource maps for a settings files wouldn't be that big (if Ross described using huge numbers of resources in his settings file, I take back that remark,, but I'd argue he's doing something the hard way...). > Except that if you do this using your pseudocode, the default settings > resource in the application file will be removed. Do I have to explain > why it's a no-no to write to your application file? No. What I was referring to was putting a default config resource into the application *at build time*. This way the read_settings routine doesn't have to care whether or not the settings file already exists. The write_settings routine always creates the settings file if it doesn't already exist, so the application never writes to itself. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
tim@hoptoad.uucp (Tim Maroney) (07/12/89)
In article <1168@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >Hmm. You're right. Oops. My apologies. I seem to have missed the original >article. Our machine was dropping incoming news on the floor for a while >recently. I sympathize. Dropped messages are pandemic on the network, and they can be very frustrating. >That makes sense, although I tend to regard worrying about memory efficiency >while writing to resource files to be on the order of tilting at windmills >:-). In particular, I would think that resource maps for a settings files >wouldn't be that big (if Ross described using huge numbers of resources in >his settings file, I take back that remark,, but I'd argue he's doing something >the hard way...). True, most configuration resource files can be expected to be small. However, many others have no real limit on size except for the limits of the Resource Manager itself. For instance, suppose that information on computer accounts for a terminal emulator are stored in the file. The user may add any number of resources. This is the kind of file I'm more accustomed to dealing with. You are quite right that if the file size is known to be small, then resizing the resource map is no strong objection. >No. What I was referring to was putting a default config resource into >the application *at build time*. This way the read_settings routine >doesn't have to care whether or not the settings file already exists. >The write_settings routine always creates the settings file if it doesn't >already exist, so the application never writes to itself. I didn't make my point clearly enough. I understood that you meant at build time. Your pseudocode did a GetResource, then a RmveResource if the GetResource succeeded, then an AddResource, when things were being updated. Look at what this does if there is no resource in the configuration file so you're using the default in the application file. The GetResource will return the application file copy and the RmveResource will remove it from the application file. This can be gotten around in a number of ways. Probably the best is to use a Get1Resource rather than a GetResource. Instead, one could also copy the default resource to the configuration file when the file is first created, or check with HomeResFile on the result of GetResource to make sure it's from the configuration file. For all I know your actual code may take care of this problem, but your pseudocode didn't address it. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "God must be a Boogie Man." -- Joni Mitchell
amanda@intercon.uu.net (Amanda Walker) (07/12/89)
In article <7953@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > True, most configuration resource files can be expected to be small. > However, many others have no real limit on size except for the limits > of the Resource Manager itself. For instance, suppose that information > on computer accounts for a terminal emulator are stored in the file. > The user may add any number of resources. This is the kind of file I'm > more accustomed to dealing with. That's a reasonable point, and I have in fact used similar techniques myself from time to time, using a resource file as a sort of quick-and-dirty tagged data file. However, once it gets to any real size, I'd say it's time to use a different approach to the problem, either by splitting things into more than one file (say, a settings file and a "Accounts" file for your example) or not using the Resource Manager at all. One of the problems with doing quick-and-dirty stuff is that users then take the program and stretch it until it breaks. As Apple says, the Resource Manager is not a database. The Finder Desktop file is a prime example :-). Great on 400K floppies, but then people insisted on using it on big hard disks... I tend to be paranoid--I figure if users can add an infinite number of custom resources, they will :-). I'm very glad that Apple is putting a standard, supported B-tree manager into System 7.0. It's about time! > [accidental writing into application resource fork] > This can be gotten around in a number of ways. Probably the best is to > use a Get1Resource rather than a GetResource. [...] For all I know your > actual code may take care of this problem, but your pseudocode didn't > address it. Quite true, as a couple people have pointed out in mail. My actual code does indeed use Get1Resource for just this reason, but I forgot to put that into my posting. That'll teach me to post an outline instead of pasting in known working code :-)... -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
lippin@wheatena.berkeley.edu (The Apathist) (07/12/89)
Recently stores@unix.UUCP (Matt Mora) wrote: >About the "remebering the state of things" I would like to see some sort of >standard about text file resources. It would be wonderful for my appliction >to be able to read a text file and get the font, font size, window >size/position and cursor location no matter what application created it. A fine idea. How about if we all use whatever MPW uses? It's got to be the most commonly used editor that does this, and I'll bet (or at least hope) that it isn't too badly hacked. >I would also like to see all word processing documents save the text >undecoded. (maybe they all do that now) so if i want I could have a >text editor open the plain text. I doubt that this is practical for really large documents. The formatting info has to go somewhere, and, as we all know, the resource manager is not a database. Plus, it's speedier to put the formatting near the text it affects. Of course, there are compromises like RTF, but they're bulky. --Tom Lippincott lippin@math.berkeley.edu "Thank you for observing all saftey precautions." --Dark Star
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/12/89)
In article <26241@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes: >Recently stores@unix.UUCP (Matt Mora) wrote: >>About the "remebering the state of things" I would like to see some sort of >>standard about text file resources. It would be wonderful for my appliction >>to be able to read a text file and get the font, font size, window >>size/position and cursor location no matter what application created it. > >A fine idea. How about if we all use whatever MPW uses? It's got to >be the most commonly used editor that does this, and I'll bet (or at >least hope) that it isn't too badly hacked. The 'MPSR' resource which is used to store this information is undocumented (read: subject to change). You can access this information from tools that you write, but only by going through the MPW library routine faccess(). The information is not available to standalone applications using this method. I agree that a standard for this sort of thing would be real nice to have, and that it would be even better if supported by Apple. Earle R. Horton "People forget how fast you did a job, but they remember how well you did it." Salada Tag Lines
yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) (07/12/89)
In article <7953@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes... >Look at what this does if there is no resource in the >configuration file so you're using the default in the application >file. The GetResource will return the application file copy and the >RmveResource will remove it from the application file. This is a worthwhile point, as I discovered. If the config file resources are damaged/missing, the application file's resources will get overwritten, which is rather undesirable. I've scuttled this approach in favor of the ChangedResource call, which works fine. Thanks to all for your comments. //////////////////////////////////////////////////////////// Internet: yahnke@macc.wisc.edu Phonenet: 608.262.8626 Mailnet: 1210 W. Dayton St., Madison WI, 53706 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
uucibg@sw1e.UUCP (3929]) (07/29/89)
In article <14355@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: +In article <26241@agate.BERKELEY.EDU> lippin@math.berkeley.edu writes: ++Recently stores@unix.UUCP (Matt Mora) wrote: +++About the "remebering the state of things" I would like to see some sort of +++standard about text file resources. It would be wonderful for my appliction +++to be able to read a text file and get the font, font size, window +++size/position and cursor location no matter what application created it. ++A fine idea. How about if we all use whatever MPW uses? It's got to ++be the most commonly used editor that does this, and I'll bet (or at ++least hope) that it isn't too badly hacked. + The 'MPSR' resource which is used to store this information is +undocumented (read: subject to change). You can access this +information from tools that you write, but only by going through the +MPW library routine faccess(). The information is not available to +standalone applications using this method. I agree that a standard +for this sort of thing would be real nice to have, and that it would +be even better if supported by Apple. Okay, I'll bite :-), why don't we just come up with a resource format and use it? Of course, I imagine everyone will argue about it for several months before coming to a conclusion (if that ever does happen :-) but, hey, I'm learning lots about the Mac from these discussions, so I won't complain. On the off chance that this'll actually become a discussion, I'll start it off with: Stated above, you'd want: + font + font size + window size + window position + cursor location (within the text). The cursor location seems to present some definite problems. My non-display- able character may be someone else's display-able character. I suppose the cursor location could be kept in the case of text only files. What does one do when one gets a file that was last used on a mac with a larger monitor than the current one? Move off-screen windows barely on screen? Leave windows the same even if they are partly off-screen? Also, is RFT really that bulky? (I've never had a chance to look at it... speaking of which, where can I get a description?) -------------------------------------------------------------------------------- Brian R. Gilstrap ...!{ bellcore!texbell, uunet }!swbatl!sw1e!uucibg One Bell Center +---------------------------------------------------------- Rm 17-G-4 | "Winnie-the-Pooh read the two notices very carefully, St. Louis, MO 63101 | first from left to right, and afterwards, in case he had (314) 235-3929 | missed some of it, from right to left." -- A. A. Milne -------------------------------------------------------------------------------- Disclaimer: Me, speak for my company? You must be joking. I'm just speaking my mind.
jakob@nada.kth.se (Jakob Cederlund) (08/01/89)
In a text editor you should save, with each buffer/document font font size window size window position cursor (selection) location AND how much the text is scrolled and all other flags ass-d with the buffer such as auto-saving, window-splitted, path to backup directory, etc /Jakob Cederlund jakob@nada.kth.se Computer Science Dept. Royal Institute of Technology, Stockholm, Sweden
jakob@nada.kth.se (Jakob Cederlund) (08/01/89)
In article <1359@draken.nada.kth.se> jakob@nada.kth.se (Jakob Cederlund) writes: >and all other flags ass-d with the buffer such as should, of course, read: and all other flags associated with the buffer such as (possible pun not intended)