forums.silverfrost.com

[Little-Acorn]

I've got an edit box set up with a string CSTRNG2 displayed in it. The user can edit the string as usual within an edit box. I'd like the system to call an extra function when the window with the edit box, loses focus (I have three windows actually, the edit box is only one of the, if the user clicks in another window I'd like that extra function to be called). The extra function will do some brief calculations and then the program can go back to what it was doing.

The Help files describe the %eb and mention callback functions. But I'm not sure how to implement a callback that happens when the window loses focus. (Or is a "callback" something different from what I'm asking here?) I have a hunch it has something to do with using the caret (^) as a modifier, something like i=winio@('%^80.20eb',CSTRNG2,4096) but I can't figure out how to use it, if that's the right thing to use at all.

Can anybody give me a hint?

Sorry for the silly beginner question, but I just can't figure this one out from the Help files.

[LitusSaxonicum]

What about:

[Little-Acorn]

This has helped a lot, Eddie, thank you!

One difference possibly between my program and yours, is that when I call my KALLBACK function, I want to hand it a variable. Specifically, I want to hand it a string that has previously been defined with the statement:

CHARACTER*32000 CHMEM

The string CHMEM is a collection of text, actually English sentences, separated by CR/LF codes and terminated with a CHAR(0). The CHAR(0) usually occurs a few thousand characters after the beginning of the string.

I actually couldn't get the callback from the %eb statement to work, probably did something else wrong. So I chickened out for now, and backed off. Now the winio@ statement that sets up the edit box %eb, does not have a callback function. Instead, I put a new button just below the edit box labelled Save Changes. That button has a callback function. And lo and behold, I am having just as much trouble with that.

At first I set up the callback function with no argument, as follows:

i=winio@('%^10bt[&Save Changes]&',sav_chg0)

Obviously, sav_chg0 is the callback function, which I want to get called every time that button is clicked. sav_chg0 is declared as EXTERNAL earlier in the program, and near the end, it is defined as:

INTEGER FUNCTION sav_chg0()

It takes no arguments, obviously. For now, it is a dummy function with just a few lines. It prints the words "Function sav_chg0 called.", assigns a value of 1 to sav_chg0, returns and ends.

This works! When I compile/run the program and click the button, a generic window appears with that text in it. That is what I wanted from this dummy program.

The trouble started when I tried to make the fuction sav_chg0 take an argument. The argument is the CHMEM string I described above.

I changed the button statement to:

i=winio@('%^10bt[&Save Changes]&',sav_chg0(CHMEM))

and changed the definition statement to:

INTEGER FUNCTION sav_chg0(CSTRG55)

Later in the function definition is the statement:

CHARACTER*(*) CSTRG55

...where I want CSTRG55 to assume the length of the CHMEM string, which is 32000.

Those two statements are the only ones I changed. Now when I try to compile it, I get a compile-time error saying:

F:\Micros\Old\Test6809\SIM09Wae.FOR(528) : error 140 - WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2)

The (528) is the line number of the button statement (listed here above), that I just changed by inserting the argument (CHMEM) to the callback function sav_chg0.

Earlier when I did not have this argument in the callback function, the program compiled and ran without error. Now, with that change and no other, I get this compile-time error. The callback function is still declared as an EXTERNAL earlier in the main program (as it was before), and is still defined as an INTEGER FUNCTION near the bottom of the file (as it was before). Even the newly-added argument (CHMEM in the calling button-statement and CSTRG55 in the function definition) is properly (I think) defined as a CHARACTER variable, as I described above.

I don't understand why the compiler is complaining about a REAL(KIND=1) argument. There isn't one!

I'm probably missing something that's well known to experienced people on this compiler - another newbie mistake. Can you help me out here?

[Little-Acorn]

Well, after writing the above, I tried the obvious thing, and changed all occurances of sav_chg0 to isav_chg0. Now the compile-time error is gone. It compiles and begins running, putting up the first window I designed (the edit-box window should be the second window to come up).

But now it produces a run-time error. After putting up the first window (which comes up perfectly without error, as it has for many weeks), it apparently starts executing the code to put up the second window, which is the edit-box window in question. It then puts up a generic window and prints "Function isav_chg0 has been called", which is the simple trace statement I put in the mostly-dummy callback function. So apparently the callback function is being called (this itself is odd, I haven't seen or clicked the new "Save Changes" button yet). Then it crashes and produces a Run-Time Error saying "Argument no 2 of winio(continuation 7) should be a call-back function". It provides a line number which is the button statement above - the statement where I just changed sav_chg0(CHMEM) to isav_chg0(CHMEM).

That button statement is, in full:

i=winio@('%^10bt[&Save Changes]&',isav_chg0(CHMEM))

The first argument of this winio statement is the '%^10bt[&Save Changes]&' ...is it not? And the second argument is isav_chg0(CHMEM) ...correct?

So, the second argument IS a callback function! I don't see how to make it any clearer or more "correct". Unless, of course, callback functions simply aren't allowed to have arguments.

To reiterate, I had this code working perfectly - compiling and running without error, and producing exactly the results I intended. That was when the callback function had no argument. But when I put an argument into the callback function, I started getting various errors that didn't make a lot of sense to me... and still don't. I'm 90% sure that putting the argument into the callback function, is the source, and possibly the cause, of the problem.

Am I anywhere close?

[Little-Acorn]

P.P.S. I thought of putting the variable I wanted to pass (the string CHMEM) into a COMMON block and passing it that way, instead of in the callback function header. But that might not work because I eventually want the program to put up more than one of these edit boxes at a time, to have multiple displays, and each edit box would have a different string.

Then thought of assigning the current CHMEM string into a temporary variable called CTEMPBUF which is a CHARACTER*32000 like CHMEM, and putting CTEMPBUF into a COMMON block to pass it. But that might not work either. The edit box might change the contents of CHMEM, and then the Save Changes button get pressed, and I wouldn't have a chance to assign the changed CHMEM into CTEMPBUF before the button is clicked. So the callback function isav_chg0 would get called, and it would find an old version of CTEMPBUF in the COMMON block, that has not been updated with the latest changes to CHMEM.

(sigh)

It would be really nice if I could simply pass CHMEM in the header of the callback function isav_chg0 when the Save Changes button is clicked. But this system seems bound and determined not to let me do that... unless I find the right command or format or whatever, that it wants.

[IanLambley]

Hi,

Try letting the program allocate the buffer itself, here is aprogram to open two files test1.txt & test2.txt, which you should create first. It can be extended to 100 files and allows the focused %eb to be printed.

I hope it helps.

Ian

[IanLambley]

[IanLambley]

[LitusSaxonicum]

First of all, apologies for not seeing your 6th July posting.

Ian has given a thorough solution to some of the problem. However, there's something fundamental at issue here, and that is the nature of a callback function.

When I started programming fortran, functions had strict rules. A function returned a single value (like sin, cos etc) and could/should not do i/o. Then I got introduced to functions that returned an error code, but otherwise did things that subroutines did. I have to say that I don't much like this form. A callback function is a more extreme version of this, in that it has no parameters either.

If you want to pass a parameter to a callback function, you have to do it through COMMON (in pre-fortran-90 style) or through the use of MODULES and/or USES to make the variable have a scope that encompasses the calling routine as well as the callback function. As far as I can tell, callback functions only need to be declared EXTERNAL, they do not need to be explicitly or implicitly given type integer in the calling program (although they need to be declared as INTEGER FUNCTION.

As I'm comparatively old, and fixed in my ways, and dislike new-fangled innovations, I've gone for lots of named COMMON blocks.

As far as saying "I might have a number of 32k byte blocks of text" is concerned, then don't forget that a gigabyte of RAM can hold 32,000 of them, and there must be a realistic limit to how many you want to open at the same time, say 10 - and this is a drop in the ocean of memory of a modern PC - so just go ahead and declare lots of them to start with. It may not be such a big ocean if you are doing some forms of numerical analysis, and in this case, you have to consider ALLOCATE and DEALLOCATE to create the array and release the memory respectively.

It's a far cry from the 16k I started out with, although to be fair they were words, not bytes, but it still wasn't very much.

Eddie

[IanLambley]

Eddie,

I used the '*' buffer definition, because it seemed that the "Save changes" function described in Little-Acorn's post could easily be achieved by the standard callback "EDIT_FILE_SAVE", although I didn't put that bit in.

Of course if the data is to be held internally within the program, then, a couple of changes can be made (which I haven't tried but are probably something like):

place this in main program & "review" function and wherever the data is to be used
character*32000 CHMEM
common/working_text/CHMEM(100)


initialisation in main program
chmem = char(0)

in "review"change the %eb to

I=WINIO@('%ww[no_border]%pv%fn[Courier New]'//
& '%ts%126.30^eb[vscrollbar,hscrollbar,hook_focus]&'
& ,0.9d0,CHMEM(current_eb),32000,ihook_focus)


This does not address the printing function which was for demo only, reading the file data would require to be replaced by something that handled the CRLF returned from the %eb, or simply save the character data to a temporary file and read that as normal.

Ian

[LitusSaxonicum]

And the simplest way to get an editor to appear:

[Little-Acorn]

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 byt

[Little-Acorn]

(continued)

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.

[IanLambley]

Hi,

Sounds a familiar problem changing from integer stored characters to character stored characters. The easiest way that I have found is to replace

integer string_array(32000)

with

character*1 string_array(32000)

Then all the array subscripts remain identical and the storage shrinks, but as you were only using one byte from a two or four byte integer anyway, it probably doesn't matter. By the way, I seem to think that a DEC10/DEC20 used a 36bit word and could store 5 seven bit characters, so work that one out!

Equivalence of the character*1 and character*32000 will now work if necessary, but you can probably still pass the character*1 array to %eb as long as you specify its size to be 32000. Use of equivalence will allow the following:

[Little-Acorn]

Thanks, Ian, but it's not going to happen. "If it works, don't fix it." I've got enough on my plate without what could be an extensive rewrite of a core program that basically works well. A few entries in these various integer arrays, ARE treated as larger-than-eight-bits-each, so a lot of detective work and surgery would be needed.

Anybody know if a callback function can take an argument?

Eddie, you seemed to be saying that it couldn't. But the examples you gave of other functions (SIN, COS) *do* take an argument, and of course return a value. I guess I need final clarification before I give up and just update ALL strings in ALL Memory Display boxes when any one fof them loses focus.

If I put a callback function that takes an argument, into an %eb statement (or a button statement) where all other parameters, options etc. are correctly specified, am I going to get an error no matter what?