Eddie, no problem at all, you and the others are giving me tremendous amounts of help here.
I guess the text I put on that new button is a little misleading, 'Save Changes'. Such a thing usually means to save whatever changes one made in the text in the window, to a file. But in my application that's not what it does: It saves the changes made in the text window, to an array of integers.
Eventually, I hope to get rid of the 'Save Changes' button, and have the text saved to the integer array automatically when the window loses focus.
An explanation for such a bizarre act is in order here.
Twenty-five years ago when FORTRAN was king, I wrote a series of microprocessor assemblers and simulators. 'Windows' meant flat glass, C was a letter in the alphabet, and FORTRAN didn't have string variables. In fact, the FORTRAN-66 compilers I was used to, were the most common ones around, and they didn't have the CHARACTER data type at all. If you wanted to store characters, you had to read them into an integer (or real) variable or an array of such integers. Depending on how the compiler was set up, and what machine it was running on, an integer variable might hold four characters max, or might just hold two. And some got a little weird when signs were extended... whether you wanted the sign extended or not. The only universal way to store characters, was to store one character per integer variable. So a 120-character sentence, usually took an array like INTEGER MYSENT(120). And a simulated memory block that was, say, 8K long, got stored as INTEGER MYMEM(8192), even though each entry was only eight bits wide.
So all the characters in my old programs are stored that way. Same deal for bytes in memory: An 8K 'memory' is an array like INTEGER MYMEM(8192). I know, there were more efficient ways to do it, but I was selling these programs as source code to people running everything from PDP-11s to IBM 360s to those newfangled VAXes. The only way I could be sure to please everybody, was to store one character (or byte) per integer location.
So that's how these programs are. And now I'm trying to adapt them to Windows for their controls, displays, file manipulations etc. Most of those functions are canned routines in Windows, thank goodness because that makes them far easier and they are still pretty versatile.
The bad news is, Windows (at least in Salford FTN95 with Clearwin) uses strings almost entirely for manipulating large amounts of text, and my programs nevah hoid of 'em.
So rather than totally rewriting my programs to take advantage of now-common string variables, I've left the cores of the programs as they were, and changed the I/Os and displays only. And written lotsa routines to convert from one to the other and back.
Long story short, one of my windows is a memory display, that shows the contents of segments of that MYMEM(8192) as hex addresses and hex bytes (and ASCII characters too, looks somewhat like an MS-DOS 'Debug' display for you old-timers). But the memory is still an integer array. So when the user wants to open one of these windows, I wrote a program to convert the integer array values to strings of hex digits to display addresses and bytes, and then use an edit box to display them.
An example of Memory Display box contents:
4000 FF FF FF FF FF FF FF FF 34 35 48 65 6C 6C 6F 2C ........45Hello,
4010 20 77 6F 72 6C 64 21 20 32 2B 33 3D 35 FF FF FF world! 2+3=5...
4020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
(etc.)
(The above looks better with a fixed-pitch font like COURIER NEW)
And when the user wants to change the contents of memory, he changes the contents of the edit box... but that's not the integer array, it's the string representation of it. (No, EQUIVALENCE statements won't work, take my word for it). He may think he's changing memory, but he's only changing the string in the edit box.
So I wrote another code segment that takes what's in the string of hex addresses and bytes in the edit box, and converts the info back into integer values and put them back into the integer array as appropriate. It is this code I would like to execute when the edit box window loses focus. Presently, I am executing it when the user clicks the new Save Changes button.
So, that's the long, sordid story. I want the callback function of the Edit Box, to take the string in the box, and extract the addresses and hex byte values it shows, and plug the VALUES of the bytes back into the appropriate locations of the integer array MYMEM(8192).
The user will probably have more than one memory display window open: One to display a RAM at location $4000-$7FFF, another to display a ROM at $E000-$FFFF, and perhaps other windows for other memory blocks, etc. When he changes text in (say) the second of those Memory Display boxes, and vlcicks that box's 'Save Changes' button, the callback function of the button will take the string from te FIRST box and translate it back to integers, placing it in memory; but won't take the changes the user made in the second box.
Passing the name of the string in the box being clicked, would help a lot. But it seems that's not possible.
