Re: Mixing 4GL with Curses Screen Handling

When porting a 4GL solution from an HP UX environment to a RH Linux environment I had some small troubles with libs, mostly because the code has been around for a while and new standards has arrived. However, I have a major problem with curses.h (ncurses.h). The program is linked and ready and opening the initial forms goes fine. The first window opened is supposed to return a curses window pointer in the "win" variable of the _efwindow structure, but this window gets a very mysterious relocation to the upper left corner. I do a file dump to see that the coordinates used as parameters to the _efwopenWindow call are correct. I also tried ibm_efm_openWindow with the same result. The new window is supposed to work as an editor. Moving text etc works as it did before, except that the whole window is displaced! Code snippet follows: new_stdtext(n) int n; { int x,y,xlen,ylen,ram,no_update,t_rownbrs; struct wnode *winptr; int win_id; popint(&t_rownbrs); popint(&no_update); if(no_update != 0) no_update = 1; popint(&ram); if(ram != 0) ram = 1; popint(&xlen); popint(&ylen); popint(&x); popint(&y); for(win_id=1;win_id<10;win_id++){ if(winarr[win_id] == NULL || winarr[win_id] == 0) break; } if(win_id == 10){ retint(0); return(1); winptr = (struct wnode*) malloc(sizeof(struct wnode)); // Comprises efwindow pointer, curses window pointer and local edit coordinates winarr[win_id] = winptr; winptr->ww = Wwarr[win_id]; // efwindow pointer storage _efwopen(&(winptr->ww), (char*)0,y,x,ylen+1,xlen+1,ram,-1,-1,-1,-1,0); winptr->winptr = (WINDOW *) winptr->ww->win; // curses window pointer All handling in the editor is done with waddch() etc. It should not know anything about the rest of the screen, right? Yet it will not stay in its fence..

On Wed, Mar 21, 2012 at 08:46, Anders Molander < anders.molander@learningwell.se> wrote: > When porting a 4GL solution from an HP UX environment to a RH Linux > environment I had some small troubles with libs, mostly because the code > has been around for a while and new standards has arrived. However, I have > a major problem with curses.h (ncurses.h). > Although I4GL uses curses, I4GL uses its own variant of curses (an archaic one, to boot), and you cannot use the system curses header or the system curses library. I4GL uses the subset it thinks it needs of the ancient (pre-X/Open standard) version of curses, then modifies it to do things like handle multi-byte characters, etc. So, do not attempt to use curses.h or ncurses.h; that will lead to disaster or frustration (or both). > The program is linked and ready and opening the initial forms goes fine. > The first window opened is supposed to return a curses window pointer in > the "win" variable of the _efwindow structure, but this window gets a very > mysterious relocation to the upper left corner. I do a file dump to see > that the coordinates used as parameters to the _efwopenWindow call are > correct. I also tried ibm_efm_openWindow with the same result. > This might be a window vs sub-window issue; what you get may be a sub-window but then it is being mistreated as the main window? Not absolutely sure about that, but if the (sub-)window appears top-left instead of somewhere else, it sure sounds like that's the problem. > The new window is supposed to work as an editor. Moving text etc works as > it did before, except that the whole window is displaced! > > Code snippet follows: > > new_stdtext(n) > int n; > { > int x,y,xlen,ylen,ram,no_update,t_rownbrs; > struct wnode *winptr; > int win_id; > popint(&t_rownbrs); > popint(&no_update); > if(no_update != 0) > no_update = 1; > popint(&ram); > if(ram != 0) > ram = 1; > popint(&xlen); > popint(&ylen); > popint(&x); > popint(&y); > > for(win_id=1;win_id<10;win_id++){ > if(winarr[win_id] == NULL || winarr[win_id] == 0) > break; > } > I'm not sure what winarr[] is; I'm moderately sure it is not in I4GL curses. > if(win_id == 10){ > retint(0); > return(1); > > winptr = (struct wnode*) malloc(sizeof(struct wnode)); // Comprises > efwindow pointer, curses window pointer and local edit coordinates > winarr[win_id] = winptr; > winptr->ww = Wwarr[win_id]; // efwindow pointer storage > > _efwopen(&(winptr->ww), (char*)0,y,x,ylen+1,xlen+1,ram,-1,-1,-1,-1,0); > winptr->winptr = (WINDOW *) winptr->ww->win; // curses window pointer > > All handling in the editor is done with waddch() etc. It should not know > anything about the rest of the screen, right? Yet it will not stay in its > fence.. > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."