Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!pyrdc!pyrnj!mirror!billc From: billc@mirror.UUCP (Bill Callahan) Newsgroups: comp.windows.ms Subject: Re: using far segments ? Message-ID: <28588@mirror.UUCP> Date: 14 Jul 89 15:14:46 GMT References: <2081@erix.ericsson.se> Reply-To: billc@prism.TMC.COM (Bill Callahan) Organization: Mirror Systems, Cambridge Mass. Lines: 78 In article <2081@erix.ericsson.se> euantd@euas1e.ericsson.se (Wojtek Chudoba) writes: =>Hello, => =>I try to write a Windows application that could present two files simultanously =>on the screen. The problem is that the files are rather large (30-60K), so they =>don't fit in the default data segment (not both of them anyway). But when you =>send a message 'EM_SETHANDLE' you must supply a *local* handle. => =>Is there a way to get around this problem ? Nope. The edit control always stores its buffer in the applications data segment. That's your limitation. But it's not hopeless. Read on. => =>I noticed that even Microsoft's Write opens only one file at a time. Could it =>be the same reason ? => =>I tried to allocate space on the global heap and copy just the one I need to =>the local heap but it didn't seem to work. (I'm not sure there were no bugs in =>this part, though.) => =>BTW, can you edit files larger than 64K ? If so, how do you do it? Ah, now you're getting close. Here's one way to do it: The idea is that edit controls use the local heap, and that space is limited. The way around it is to only put a reasonable sized chunk of text in an edit control. "Reasonable" is a judgement call, but basically, if the chunks are too big, you'll run out of local heap space, and if the the chunks are too small, you'll be doing a lot of scrambling to move chunks in and out of the editor's buffer. Come up with a scheme to only display a chunk of text at a time. The user is only interested in what s/he can see, and some space at either end, most of the time, so try to have that stuff be in your chunk, or at least easily accessible. When the user pages close to one end of the chunk, get the next chunk ready. When the user needs to see a different chunk, swap it into the buffer. This is tricky, but this is the approach you need. The file itself can be treated in several ways. You can either have it all in global memory in once piece (probably not useful, but conceptionally easy to deal with) or have it in global memory broken up into chunks in a linked list data structure. That's probably the way to go. (If the file is truly huge, some of the chunks can actually be out of main memory on a real or RAM disk, but let's not consider that.) You are probably saying to yourself, "Arrgh! Why do have to do all this?" The reason is that an edit control is not a true editor. It's too small. It can, however, be used to make a real editor, by using smart data structures to actually hold the text, and using the control just as an interface. "Real" editors do tend to use linked list data structures. If MS had been very nice, that could have made edit controls powerful, making them mini-editors using real data structures in global memory, but that's not what an edit control is. It's simply an editor-like interface to a local memory buffer. I don't know what your requirements are, but if you only need to display the two files, you shouldn't have too much trouble. Real editing can get messy, unless you study up on data structures and how to manipulate them. As far as multiple files go, as long as you have a scheme of keeping track of which is which, it's quite possible to do it. In fact, once you do the design work to have two, you've basically designed a way to have many, but one is easier to deal with. Good luck. --------------------------------------------------------------------------- Bill Callahan billc@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billc Mirror Systems 2067 Massachusetts Ave. 617\661-0777 x149 Cambridge, MA 02140