euantd@euas1e.ericsson.se (Tord Nilsson) (07/13/89)
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 ? 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? And, finally, is it possible for a Windows application to start another instance of itself, or to start another application ? OK, those were the questions, hope you have some answers now. Wojtek ______________________________________________________________________________ Disclaimer: It's only a summer job, you'll find me at: Royal Institute of Technology, Stockholm,Sweden d87-wch@nada.kth.se
billc@mirror.UUCP (Bill Callahan) (07/14/89)
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 02140bturner@hpcvlx.HP.COM (Bill Turner) (07/15/89)
> 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 ? Not if you want to use EDIT children to do editing. > I noticed that even Microsoft's Write opens only one file at a time. Could it > be the same reason ? No, Write doesn't do its editing with the EDIT children. They have their own window class definition. If you write the code for the window yourself, you can make it do anything you want (including using GLOBAL heap for data storage, or [a better solution] virtualizing the file and reading in only part at a time). > And, finally, is it possible for a Windows application to start another > instance of itself, or to start another application ? Yes, you can use the DOS INT 21h function 4Hh (EXEC) call. I don't have details on it, but Microsoft has a tech note on its use (including an example program). --Bill Turner (bturner@hp-pcd.hp.com) HP Corvallis Information Systems
mms00786@uxa.cso.uiuc.edu (07/17/89)
Probably a silly question, but wouldn't having the user start two instances of your program, one for each file, have the same effect? In which case, all you have to do is be able to handle one large file in your program. I thought that was one of the big advantages of Windows, but I am only a student, and I am a couple of years away from being omniscient. I would, however, like to know the advantage of a program handling multiple files as opposed to multiple instances of the same program each handling one file. Thanks, Milan mms00786@uxa.cso.uiuc.edu