GUI ScreenIO for Windows |
Listview controls are more complex than other controls, and users often have a little trouble understanding how they work. This covers the more common problems people have when beginning to use listviews.
These problems can be avoided by following the rules for listview loading.
One of the best ways to get a good understanding of listviews is to play with the demonstration program that we provide. It not only provides a good framework that you could modify for your own listview program, but it also displays the events, keys, and other information that are returned by the listview in response to various situations.
If a listview asks you for data, you must provide it. If you don't handle the three mandatory listview events correctly, your program will loop (but GUI ScreenIO will detect this condition and tell you about it).
It's very common for programmers to miscalculate the percentages, or incorrectly specify the first and/or last record in the list.
GUI ScreenIO infers the size of the file by the difference between the percentages of the first and last records in the cache. If the file is very large, the scrollbar thumb will be small; if it's a small file, the scrollbar thumb will occupy most of the scrollbar.
If your program isn't loading the listview correctly, use your interactive debugger to verify that it's loading the percentages correctly; particularly the first and last (end-of-file) records.
If a list has only one record, you load it with 100%.
Upon feeding the listview successive buffers, the first record that you load to your new listview buffer, must match the last record in the prior listview buffer. That is, you must reload the record with the key returned in listview-GET-FROM-KEY when you respond to this event. Don't forget to give it exactly the same data, percent, key, and columns.
If you do NOT load 100 percent to the last record in the list, the listview will continue to return listview-GET-NEXT events. This results in a loop because your program will be unable to provide any more data.
More than one developer has made the simple mistake of loading 100 percent to a record when their PERFORMed loop reaches listview-MAX, instead of when they reach end-of-file. If you do this, the listview will no longer return listview-GET-NEXT events because you told it you gave it the last record in the list!
This is a good example of when your interactive COBOL debugger would help you identify the problem in a hurry.
This is caused by having the same --KEY value on many records (or missing --KEY values). Keys must be unique.
Each record must have data in column 1. Column 1 must not be be blank or low-values.
This can happen if
In every case, there is something wrong with the date you are trying to feed into the listview. We recommend you use your compiler's debugger and pay close attention to the data sent in, and compare it to what the listview requested.
The listview will eventually give up and send you a pop-up message telling you that you ignored X consecutive start-at requests. Often this is caused by you trying to out-smart the listview and feed it what you thought it would want rather than what it asked for.
When using a Preload Cache listview or an Accumulate Cache you assume that the only event the listview will send back is a GET-NEXT. Normally this is true, but if you violate one of the rules of listview loading, the listview can be come confused and lose its position. It then asks you to start-at. This is common if you attempt to load a listview but fail to feed it the zero percent record, or cause a listview reset while loading, or you fail to overlap reads etc.
© 2000-2019 Norcom, all rights reserved |