When dealing with files (reading or writing) you MUST ALWAYS return a STATUS CODE.
RETURN-CODE may will return this status code, but is OMITTED, just because the very same file (if it exists) may be locked (for whatever reason). Call me pessimist, but I've seen things.
Anyway, I belive that you'd not forget that !
And don't forget to do the math. Savefiles are 8K (at minimum, depending the windows size which is not always 80x25). It may reach much bigger sizes.
The minimum size will be 80x25x4=8K
Where:
80 - # columns
25 - # lines
4 - 'chtype' size used in GnuCOBOL (32bits)
So, 8,000 bytes (8Kb) must be provided (at least)
For a Window with 135x52x4 it will need 28,080 bytes (Aprox. 28Kb).
I can do that with "win32a" easly..
JUST WONDERING, FOR WHAT I SAW.
And I'm NOT "talking" about the non-standard 'chtypes' with 8 bytes, which are DOUBLE size.
Cheers,
MM
Conclusion:
Perhaps the ending has not yet been written (from MYST).
Last edit: Mário Matos 2016-10-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You'll have to be more specific :-)
I'm very outdated right now.
When did those CALLs were first introduced ? I mean, version
major+minor+patch.
To which compiler should I refer to ? Arnold's ?
MM
Last edit: Simon Sobisch 2020-06-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We discussed these end of 2016 and came up with a "design" for those (see the discussion board link), I'm asking you to implement those now in C and test them - I'll take then the work to polish them a bit and include these in GnuCOBOL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Simon
I would suggest not to use scr_dump and scr_restore which save the whole screen to file.
I think it would be more efficient and even faster to save only a rectangular area of the screen (row and column to be specified from time to time) by reading the individual characters and attributes of the screen with a loop.
This can be done with the pdcurses mvinch () library function.
I had already done so many tests for this with a cobol program that makes a call to the mvinch () function. unfortunately this function returns incorrect values to me in some cases.
In a previous post I had published all the cobol source and sample screenshots.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've meant to upload a "separate" (not TUI-tools using) mouse test program in the contrib/samples containing some notes about the settings and how to query the mouse.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been playing around with the notions put forth on this thread ... some of it works, some not. I do have a small question: why am I getting these warning messages during the compile:
The test program uses 'scr_dump' and 'scr_restore' which seem to work. However 'inch' does not even if I include a buffer purge loop before trying to acquire a single character. That is not a problem but I am curious about the warnings.
Thanks for your time.
Gregory
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume these method does NOT work when running under Linux or am I wrong?
Downloaded the contrib for this but compiles fail heavily but not using the latest version only at 1115. Too much to change code in call.c & config every time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The methods for saving/restoring a curses window should work everywhere.
Vince, you accomplished that I've dropped my release plan for rc-2 for the next minutes. Congratulations!
I'll postpone the rc2 a little bit and add [feature-requests:#101] before (I'm away the next days, maybe get it in on Sunday). This issue is what you referred to, didn't you?
Can you post the link to the last discussion we had about this issue? I think we raised the maximum call numbers even more...
I am using 192 which hopefully is above any table I will be building and here is an example of one for 160 fields and it is only needed for the Fetch as insert/update just builds a long string containing the entire SQL entry pity cant do the same with fetch.
I'm working on a menu per profile and the screen is saved (scr_dump) at each choice and restored when returning to the previous item (scr_restore).
However, after returning (when a restore is performed) and after choosing a new item, there is a problem rendering the screen.
This problem only happens on windows (-lpdcurses), on linux using ncurses (-lncursesw) the problem does not happen.
Any suggestion?
Hi Marcos,
I'm glad you're using the TUI-TOOLS from the repository.
If you have problems or suggestions for improvement, feel free to write in this forum!
I have been doing some pdcursesmod programming in C as a learning experience.
it appears that on pdcursesmod, that scr_restore only updates the virtual screen, this does not affect the physical screen until a doupdate() function is executed (which is done by the refresh() function under the covers).
So if you could repeat your test and add a static call the the pdcursesmod refresh() function immediately after calling scr_restore() function and see if that changes the behavior..
also I would advise checking the return code after the cobol calls as pdcursesmod does return an integer which can be used to detect if pdcursesmod encountered an error or the function was executed successfully.
Note...
The user must use doupdate() to refresh the physical screen.
Description
getwin() reads window-related data previously stored in a file by putwin(). It then creates and initialises a new window using that data.
also if you could create a very small program which encounters this issue I could try to test it with GDB...
Chuck Haatvedt
putwin() writes all data associated with a window into a file, using an unspecified format. This information can be retrieved later using getwin().
scr_dump() writes the current contents of the virtual screen to the file named by filename in an unspecified format.
scr_restore() function sets the virtual screen to the contents of the file named by filename, which must have been written using scr_dump(). The next refresh operation restores the screen to the way it looked in the dump file.
In PDCurses, scr_init() does nothing, and scr_set() is a synonym for scr_restore(). Also, scr_dump() and scr_restore() save and load from curscr. This differs from some other implementations, where scr_init() works with curscr, and scr_restore() works with newscr; but the effect should be the same. (PDCurses has no newscr.)
Description
wrefresh() copies the named window to the physical terminal screen, taking into account what is already there in order to optimize cursor movement. refresh() does the same, using stdscr. These routines must be called to get any output on the terminal, as other routines only manipulate data structures. Unless leaveok() has been enabled, the physical cursor of the terminal is left at the location of the window's cursor.
wnoutrefresh() and doupdate() allow multiple updates with more efficiency than wrefresh() alone. wrefresh() works by first calling wnoutrefresh(), which copies the named window to the virtual screen. It then calls doupdate(), which compares the virtual screen to the physical screen and does the actual update. A series of calls to wrefresh() will result in alternating calls to wnoutrefresh() and doupdate(), causing several bursts of output to the screen. By first calling wnoutrefresh() for each window, it is then possible to call doupdate() only once.
In PDCurses, redrawwin() is equivalent to touchwin(), and wredrawln() is the same as touchline(). In some other curses implementations, there's a subtle distinction, but it has no meaning in PDCurses.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm in for that move.
As long as we don't break anything. ;-) ;-)
Cheers,
Brian
Simon,
You know? You are such a person!
When dealing with files (reading or writing) you MUST ALWAYS return a STATUS CODE.
RETURN-CODE may will return this status code, but is OMITTED, just because the very same file (if it exists) may be locked (for whatever reason). Call me pessimist, but I've seen things.
Anyway, I belive that you'd not forget that !
And don't forget to do the math. Savefiles are 8K (at minimum, depending the windows size which is not always 80x25). It may reach much bigger sizes.
The minimum size will be 80x25x4=8K
Where:
80 - # columns
25 - # lines
4 - 'chtype' size used in GnuCOBOL (32bits)
So, 8,000 bytes (8Kb) must be provided (at least)
For a Window with 135x52x4 it will need 28,080 bytes (Aprox. 28Kb).
I can do that with "win32a" easly..
JUST WONDERING, FOR WHAT I SAW.
And I'm NOT "talking" about the non-standard 'chtypes' with 8 bytes, which are DOUBLE size.
Cheers,
MM
Conclusion:
Perhaps the ending has not yet been written (from MYST).
Last edit: Mário Matos 2016-10-26
@matosma It's been a while, but can you provide the code for
CBL_GC_SCR_DUMPandCBL_GC_SCR_RESTOREin C?You'll have to be more specific :-)
I'm very outdated right now.
When did those CALLs were first introduced ? I mean, version
major+minor+patch.
To which compiler should I refer to ? Arnold's ?
MM
Last edit: Simon Sobisch 2020-06-10
We discussed these end of 2016 and came up with a "design" for those (see the discussion board link), I'm asking you to implement those now in C and test them - I'll take then the work to polish them a bit and include these in GnuCOBOL.
Hi Simon
I would suggest not to use scr_dump and scr_restore which save the whole screen to file.
I think it would be more efficient and even faster to save only a rectangular area of the screen (row and column to be specified from time to time) by reading the individual characters and attributes of the screen with a loop.
This can be done with the pdcurses mvinch () library function.
I had already done so many tests for this with a cobol program that makes a call to the mvinch () function. unfortunately this function returns incorrect values to me in some cases.
In a previous post I had published all the cobol source and sample screenshots.
I've meant to upload a "separate" (not TUI-tools using) mouse test program in the contrib/samples containing some notes about the settings and how to query the mouse.
Hi, Klaus
Please see:
http://man7.org/linux/man-pages/man3/curs_scr_dump.3x.html
Just to be sure... :-)
Cheers,
MM
I have been playing around with the notions put forth on this thread ... some of it works, some not. I do have a small question: why am I getting these warning messages during the compile:
The test program uses 'scr_dump' and 'scr_restore' which seem to work. However 'inch' does not even if I include a buffer purge loop before trying to acquire a single character. That is not a problem but I am curious about the warnings.
Thanks for your time.
Gregory
The C compiler warnings are fixed in the current svn version.
I assume these method does NOT work when running under Linux or am I wrong?
Downloaded the contrib for this but compiles fail heavily but not using the latest version only at 1115. Too much to change code in call.c & config every time.
The methods for saving/restoring a curses window should work everywhere.
Vince, you accomplished that I've dropped my release plan for rc-2 for the next minutes. Congratulations!
I'll postpone the rc2 a little bit and add [feature-requests:#101] before (I'm away the next days, maybe get it in on Sunday). This issue is what you referred to, didn't you?
Can you post the link to the last discussion we had about this issue? I think we raised the maximum call numbers even more...
Related
Wish List:
#101Found it here :
https://sourceforge.net/p/open-cobol/discussion/cobol/thread/66de2539/?limit=25#d2b7
I am using 192 which hopefully is above any table I will be building and here is an example of one for 160 fields and it is only needed for the Fetch as insert/update just builds a long string containing the entire SQL entry pity cant do the same with fetch.
*> /MYSQL FETCH\ *> *> Fetch next record *> *> TABLE=SYSTEM-REC MOVE TP-SYSTEM-REC TO WS-MYSQL-RESULT CALL "MySQL_fetch_record" USING WS-MYSQL-RESULT HV-SYSTEM-REC-KEY HV-SYSTEM-RECORD-VERSION-PRIME HV-SYSTEM-RECORD-VERSION-SECON HV-VAT-RATE-1 HV-VAT-RATE-2 HV-VAT-RATE-3 HV-VAT-RATE-4 HV-VAT-RATE-5 HV-CYCLEA HV-PERIOD HV-PAGE-LINES HV-NEXT-INVOICE HV-RUN-DAT HV-START-DAT HV-END-DAT HV-SUSER HV-USER-CODE HV-ADDRESS-1 HV-ADDRESS-2 HV-ADDRESS-3 HV-ADDRESS-4 HV-POST-CODE HV-COUNTRY HV-PRINT-SPOOL-NAME HV-FILE-STATUSES HV-PASS-VALUE HV-LEVEL-1 HV-LEVEL-2 HV-LEVEL-3 HV-LEVEL-4 HV-LEVEL-5 HV-LEVEL-6 HV-PASS-WORD HV-HOST HV-OP-SYSTEM HV-CURRENT-QUARTER HV-FILE-SYSTEM-USED HV-FILE-DUPLICATES-IN-USE HV-MAPS-SER HV-DATE-FORM HV-DATA-CAPTURE-USED HV-RDBMS-DB-NAME HV-RDBMS-USER HV-RDBMS-PASSWD HV-RDBMS-PORT HV-RDBMS-HOST HV-RDBMS-SOCKET HV-VAT-REG-NUMBER HV-PARAM-RESTRICT HV-P-C HV-P-C-GROUPED HV-P-C-LEVEL HV-COMPS HV-COMPS-ACTIVE HV-M-V HV-ARCH HV-TRANS-PRINT HV-TRANS-PRINTED HV-HEADER-LEVEL HV-SALES-RANGE HV-PURCHASE-RANGE HV-VAT HV-BATCH-ID HV-LEDGER-2ND-INDEX HV-IRS-INSTEAD HV-LEDGER-SEC HV-UPDATES HV-POSTINGS HV-NEXT-BATCH HV-EXTRA-CHARGE-AC HV-VAT-AC HV-PRINT-SPOOL-NAME2 HV-NEXT-FOLIO HV-BL-PAY-AC HV-P-CREDITORS HV-BL-PURCH-AC HV-BL-END-CYCLE-DAT HV-BL-NEXT-BATCH HV-AGE-TO-PAY HV-PURCHASE-LEDGER HV-PL-DELIM HV-ENTRY-LEVEL HV-P-FLAG-A HV-P-FLAG-I HV-P-FLAG-P HV-PL-STOCK-LINK HV-PRINT-SPOOL-NAME3 HV-SALES-LEDGER HV-SL-DELIM HV-OI-3-FLAG HV-CUST-FLAG HV-OI-5-FLAG HV-S-FLAG-OI-3 HV-FULL-INVOICING HV-S-FLAG-A HV-S-FLAG-I HV-S-FLAG-P HV-SL-DUNNING HV-SL-CHARGES HV-SL-OWN-NOS HV-SL-STATS-RUN HV-SL-DAY-BOOK HV-INVOICER HV-EXTRA-DESC HV-EXTRA-TYPE HV-EXTRA-PRINT HV-SL-STOCK-LINK HV-SL-STOCK-AUDIT HV-SL-LATE-PER HV-SL-DISC HV-EXTRA-RATE HV-SL-DAYS-1 HV-SL-DAYS-2 HV-SL-DAYS-3 HV-SL-CREDIT HV-SL-MIN HV-SL-MAX HV-PF-RETENTION HV-FIRST-SL-BATCH HV-FIRST-SL-INV HV-SL-LIMIT HV-SL-PAY-AC HV-S-DEBTORS HV-SL-SALES-AC HV-S-END-CYCLE-DAT HV-SL-COMP-HEAD-PICK HV-SL-COMP-HEAD-INV HV-SL-COMP-HEAD-STAT HV-SL-COMP-HEAD-LETS HV-SL-VAT-PRINTED HV-STK-ABREV-REF HV-STK-DEBUG HV-STK-MANU-USED HV-STK-OE-USED HV-STK-AUDIT-USED HV-STK-MOV-AUDIT HV-STK-PERIOD-CUR HV-STK-PERIOD-DAT HV-STOCK-CONTROL HV-STK-AVERAGING HV-STK-ACTIVITY-REP-RUN HV-STK-PAGE-LINES HV-STK-AUDIT-NO HV-CLIENT HV-FN-1 HV-FN-2 HV-FN-3 HV-FN-4 HV-FN-5 HV-SYSTEM-OPS HV-NEXT-POST HV-VAT1 HV-VAT2 HV-VAT3 HV-IRS-PASS-VALUE HV-SAVE-SEQU HV-SYSTEM-WORK-GROUP HV-PL-APP-CREATED HV-PL-APPROP-AC HV-1ST-TIME-FLAG *> /MYSQL-END\ end-callVince
Hey!
I'm working on a menu per profile and the screen is saved (scr_dump) at each choice and restored when returning to the previous item (scr_restore).
However, after returning (when a restore is performed) and after choosing a new item, there is a problem rendering the screen.
This problem only happens on windows (-lpdcurses), on linux using ncurses (-lncursesw) the problem does not happen.
Any suggestion?
Sorry for the bad english
(code based on Prof. Eugenio's TUI)
The texts on the screens are in Portuguese.
Hi Marcos,
I'm glad you're using the TUI-TOOLS from the repository.
If you have problems or suggestions for improvement, feel free to write in this forum!
You have the same problem that I reported with this post a while ago:
https://sourceforge.net/p/gnucobol/discussion/contrib/thread/f5934f0f/?limit=50#fd9f
Unfortunately, so far the problem also applies to me.
So far I haven't had any solution how to fix it!
Marcos & Eugenio,
I have been doing some pdcursesmod programming in C as a learning experience.
it appears that on pdcursesmod, that scr_restore only updates the virtual screen, this does not affect the physical screen until a doupdate() function is executed (which is done by the refresh() function under the covers).
So if you could repeat your test and add a static call the the pdcursesmod refresh() function immediately after calling scr_restore() function and see if that changes the behavior..
also I would advise checking the return code after the cobol calls as pdcursesmod does return an integer which can be used to detect if pdcursesmod encountered an error or the function was executed successfully.
Note...
The user must use doupdate() to refresh the physical screen.
Description
getwin() reads window-related data previously stored in a file by putwin(). It then creates and initialises a new window using that data.
===================================================
also if you could create a very small program which encounters this issue I could try to test it with GDB...
Chuck Haatvedt
putwin() writes all data associated with a window into a file, using an unspecified format. This information can be retrieved later using getwin().
scr_dump() writes the current contents of the virtual screen to the file named by filename in an unspecified format.
scr_restore() function sets the virtual screen to the contents of the file named by filename, which must have been written using scr_dump(). The next refresh operation restores the screen to the way it looked in the dump file.
In PDCurses, scr_init() does nothing, and scr_set() is a synonym for scr_restore(). Also, scr_dump() and scr_restore() save and load from curscr. This differs from some other implementations, where scr_init() works with curscr, and scr_restore() works with newscr; but the effect should be the same. (PDCurses has no newscr.)
Description
wrefresh() copies the named window to the physical terminal screen, taking into account what is already there in order to optimize cursor movement. refresh() does the same, using stdscr. These routines must be called to get any output on the terminal, as other routines only manipulate data structures. Unless leaveok() has been enabled, the physical cursor of the terminal is left at the location of the window's cursor.
wnoutrefresh() and doupdate() allow multiple updates with more efficiency than wrefresh() alone. wrefresh() works by first calling wnoutrefresh(), which copies the named window to the virtual screen. It then calls doupdate(), which compares the virtual screen to the physical screen and does the actual update. A series of calls to wrefresh() will result in alternating calls to wnoutrefresh() and doupdate(), causing several bursts of output to the screen. By first calling wnoutrefresh() for each window, it is then possible to call doupdate() only once.
In PDCurses, redrawwin() is equivalent to touchwin(), and wredrawln() is the same as touchline(). In some other curses implementations, there's a subtle distinction, but it has no meaning in PDCurses.