maa@clinet.FI (Miika Asunta) (07/18/89)
I have some questions considering use of handles with Mac Applications. 1) What is the best way to allocate a chain without fragmenting the memory? Using handles is not as simple as you might think at first - You need to allocate master pointers with MOREMASTERS for all your handles in the main datasegment (#1), and you won't know the amount of handles in a chain forehand. I know that when all of them are in use system calls moremasters again to allocate more pointers, but it can fragment memory! 2) How can I store a TEstylehandle entirely into a file? Is the following (written in pseudo-code) enough: ... ... FSWrite n bytes , pointer (TEstylehandle^) ... ... Quite rough code, but - I hope - understandable! The idea is that I can edit several pieces of text having only one TEHandle allocated! Are there any technical notes considering the questions? -- ************************************************************************* * Miika Asunta * Double Basist * * internet: maa@clinet.fi * Macintosh Programmer * * UUCP: mcvax!santra!clinet!maa * *
tim@hoptoad.uucp (Tim Maroney) (07/19/89)
In article <1044@clinet.FI> maa@clinet.FI (Miika Asunta) writes: >1) What is the best way to allocate a chain without fragmenting the > memory? Using handles is not as simple as you might think at first > - You need to allocate master pointers with MOREMASTERS for all your > handles in the main datasegment (#1), and you won't know the amount > of handles in a chain forehand. I know that when all of them are > in use system calls moremasters again to allocate more pointers, but > it can fragment memory! The recommended way to do this is to determine your master pointer requirements empirically. This is described in Tech Note #53. Briefly, exercise your program thoroughly, then break into MacsBug and count the number of master pointer blocks. These are the NON-relocatable blocks of size $108, $10c, or $110 bytes. Then add calls to MoreMasters in The initialization code in CODE 1 to create this many master pointer blocks plus 20%. It would probably also be wise to scale this number according to the amount of available memory. The Tech Note used to have a note about a dynamic master pointer allocation technique used by ResEdit that was better, which was supposed to be the subject of a future Tech Note, but this comment is no longer present in the current Tech Note #53. Presumably, it wasn't that great a technique after all. >2) How can I store a TEstylehandle entirely into a file? Is > the following (written in pseudo-code) enough: > FSWrite n bytes , pointer (TEstylehandle^) That's just about correct, yes. In C, actual code would be: FSWrite(refnum, (long)(*te)->teLength, *((*te)->hText)); and if my Pascal hasn't gotten too rusty, that would be: FSWrite(refnum, te^^.teLength, (te^^.hText)^); You can do much the same to read a small text file into a text edit buffer. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Philosophy is the talk on a cereal box Religion is the smile on a dog" -- Edie Brickell, "What I Am"
stores@unix.SRI.COM (Matt Mora) (07/19/89)
In article <8043@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <1044@clinet.FI> maa@clinet.FI (Miika Asunta) writes: > >>2) How can I store a TEstylehandle entirely into a file? Is >> the following (written in pseudo-code) enough: >> FSWrite n bytes , pointer (TEstylehandle^) > ^^^^^ Tim, think he wants to save the style information not just the text. >That's just about correct, yes. In C, actual code would be: >FSWrite(refnum, (long)(*te)->teLength, *((*te)->hText)); >and if my Pascal hasn't gotten too rusty, that would be: >FSWrite(refnum, te^^.teLength, (te^^.hText)^); > I haven't used the new TE styles yet butI read the chapter awhile ago and i think it mentions somthing about a new scrap type 'styl' that you might be able to save in the resource fork. Haven't tried it just guessing. -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
tim@hoptoad.uucp (Tim Maroney) (07/20/89)
In article <1044@clinet.FI> maa@clinet.FI (Miika Asunta) writes: >2) How can I store a TEstylehandle entirely into a file? Is > the following (written in pseudo-code) enough: > FSWrite n bytes , pointer (TEstylehandle^) In article <1409@unix.SRI.COM> stores@unix.UUCP (Matt Mora) writes: >Tim, think he wants to save the style information not just the text. Oops, look like you're right. I haven't used the styled textEdit yet (it seems pretty pointless until they get rid of the length limits, frankly) and so I just read right over that. >I haven't used the new TE styles yet butI read the chapter awhile ago >and i think it mentions somthing about a new scrap type 'styl' that >you might be able to save in the resource fork. I suppose that could work, but I just did a little looking and it appears that Miika was correct. All the style information is stored in a single handle which could be written out to a file by a single FSWrite call. However, as you imply, it might be better to write it to a resource instead. That way you can have a plain text file in the data fork with associated style information in the resource fork. But again, this would only be really useful if Apple eliminated the size limitations, both tacit and overt. The 32K limit is bad enough, but in practice, handle resizing overhead (and, I suppose, line array maintenance) makes text edit records impossibly slow at lengths as small as 2K. Yech. TextEdit does a lot of really nice stuff, and I just wish they'd make it useful for something other than the Dialog Manager. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Those who restrain desire, do so because theirs is weak enough to be restrained..." - Blake, "The Marriage of Heaven and Hell"
amanda@intercon.uu.net (Amanda Walker) (07/21/89)
In article <8071@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > TextEdit does a lot of really nice stuff, and I > just wish they'd make it useful for something other than the Dialog > Manager. Yup. It's funny sometimes. Apple provides this nice Toolbox so that no one has to reinvent the wheel for the user interface, but everybody still has to reinvent (incompatible) wheels for: Non-trivial text editing Indexed files / simple databases Scrolling selection lists and tables And so on. I realize that Apple can't be all things to all people, but sometimes I wish that they did as complete a job on some of these things as they did on Quickdraw or MacApp. I guess you can tell what things are more fun to work on... Grumble. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (07/21/89)
In article <1294@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > >Yup. It's funny sometimes. Apple provides this nice Toolbox so that >no one has to reinvent the wheel for the user interface, but everybody >still has to reinvent (incompatible) wheels for: >... > Scrolling selection lists and tables Hmm. I haven't found the List Manager to be all that difficult to use, or that it lacks much critical versatility. Its worst flaw is that it doesn't support variable column or row sizes. But a simple scrolling list takes only, say, 50 lines of code to implement as a module, more if you add frills like arrow key scrolling, etc. (Your code length may vary.) And LDEFs have to be easier to write and get working than any other piece of code of the form xDEF ... One hint ... it's a lot simpler to use the List Manager for these purposes if you avoid mixing it with the Dialog Manager. Implement your "dialog" with your own window and controls and avoid the userItem ... you'd be amazed how much easier the code is to read, among other things.
lsr@Apple.COM (Larry Rosenstein) (07/22/89)
In article <8043@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > The Tech Note used to have a note about a dynamic master pointer > allocation technique used by ResEdit that was better, which was > supposed to be the subject of a future Tech Note, but this comment is I think the technique was to check the number of free master pointers in your main event loop and call MoreMasters there if the number was low. This was important in 64K ROM days because code segments could be taking up space at the low end of the heap, where master pointer blocks are allocated. This technique helps ensure that only the main segment was loaded at the time MoreMasters was called. The 128K ROMs and beyond move code segments to the top of memory so that the low end of the heap is usually clear for nonrelocatable blocks. (Note that the same technique would apply to allocating data for new windows.) Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
tim@hoptoad.uucp (Tim Maroney) (07/23/89)
In article <8071@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > TextEdit does a lot of really nice stuff, and I > just wish they'd make it useful for something other than the Dialog > Manager. In article <1294@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >Yup. It's funny sometimes. Apple provides this nice Toolbox so that >no one has to reinvent the wheel for the user interface, but everybody >still has to reinvent (incompatible) wheels for: > > Non-trivial text editing Yep, not to mention just ordinary text display. TextEdit isn't even powerful enough to be used for off-the-top capture capabilities with the new Communications Toolbox. > Indexed files / simple databases Yes. As some of us have discussed in e-mail already, the new B-Tree Manager looks amazingly inflexible, with incredibly small limits on the size of data and keys, only one tree per file, and no apparent interface to the new remote database handling capabilities. A special purpose tool which is really useful only to HFS internals is being foisted off on us as if it were a general purpose tool. This is a remarkably close analogy to TextEdit, which is really useful only for the Dialog Manager, but which Apple pretends is a general-purpose text editing support layer. > Scrolling selection lists and tables Yep. The List Manager won't even draw lines between the cells for you. Much less will it cope with variable-width and variable-height cells, an absolute requirement for any serious database interface or spreadsheet front-end. I believe it also has some serious weaknesses in the area of horizontal scrolling, allowing only whole-cell scrolling, though I can't say for sure. It's not like there are any serious technical obstacles to providing these kinds of services, either. The problem seems to be that Apple insists on rushing out half-baked software support layers. The multiple revisions of the Script Manager and Sound Manager are good examples. But at least Apple is working to improve those. TextEdit was released half-baked and has only been enhanced in ways that do nothing to alleviate its fundamental flaws for any real application. The supposedly more powerful CoreEdit was quietly killed off, reportedly for political reasons. The List Manager has never been improved except for bug fixes and is less powerful than its forerunner, the list management in Standard File, in a number of significant ways (such as the lack of keyboard handling and the inferior "end of list" handling). >And so on. I realize that Apple can't be all things to all people, but >sometimes I wish that they did as complete a job on some of these things >as they did on Quickdraw or MacApp. I guess you can tell what things are >more fun to work on... So it would seem. Quickdraw is a good example of doing a support layer right. It really is quite clean and powerful. Windows, menus, controls -- these are all done pretty well. But when are we going to see the serious support that we would expect from an OS that requires two megabytes of memory just to run? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Every year, thousands of new Randoids join the ranks. Most tend to be either too-rich self-made tycoons or picked-on computer nerds (the romantic, heroic individualism of Rand's novels flatters the former and fuels the latter's revenge fantasies)." -- Bob Mack, SPY, July 1989