glassmann@ccavax.camb.com (03/16/90)
The following program does a wierd thing. If you just press ctrl-end while the
cursor is in the first field, the numbers "1,2,3" from the SAY loop are
displayed using 2 columns, as expected. However, if you go into the second
field (the one with the multiple choice), the numbers are displayed in column
10, as if there was no picture clause. Anyone have any insight into this?
set talk off
homeprice = 0
magazine = space(8)
clear
@ 14,13 GET homeprice PICTURE "@Z$ 99999999"
@ 16,13 GET magazine PICTURE "@M NONE,TIME,NEWSWEEK"
read
tmp = 1
do while tmp <= 3
@ tmp + 4, 1 say tmp picture "99"
tmp = tmp + 1
enddo
set talk on
return
--
Lenny Glassmann lenny@ccavax.camb.com
...uunet!ccavax!lennymikelly@ac.dal.ca (03/17/90)
In article <19664.25ffd528@ccavax.camb.com>, glassmann@ccavax.camb.com writes: > The following program does a wierd thing. If you just press ctrl-end while the > cursor is in the first field, the numbers "1,2,3" from the SAY loop are > displayed using 2 columns, as expected. However, if you go into the second > field (the one with the multiple choice), the numbers are displayed in column > 10, as if there was no picture clause. Anyone have any insight into this? This is one that has been around for a while: If the last get field in a read statement is a multiple choice all picture/ function formating is disabled. Very annoying, and the easiest way I have found around it is to re-order the @gets so that the last one is NOT a multiple choice. A-T could suggest no other solution when I called the support line in June last year about it. (maybe there is a better fix available now ...) -Mike Kelly
awd@dbase.A-T.COM (Alastair Dallas) (03/18/90)
I have no idea why dBASE IV behaves that way, and I don't know the history of how it was fixed, but your program behaves incorrectly (just as you say) on the release 1.0 version of dBASE IV and behaves correctly on the current beta release 1.1 version. The 1.0 release was internal build 322 and the build I checked it on is 455--we've been busy around here. It's an understatement to say that there are a lot of little things to worry about in a program as complex as dBASE IV. It's about 600,000 lines of source code and it's very hard to test for conditions such as the one you found--imagine the matrix you build when you want to test every permutation of each command and then test every subsequent command against each permutation of the first command? I think it's fair to say that Ashton-Tate is currently "pushing the envelope" of what's considered reasonable software quality assurance--we have a wide variety of automated and human testing going on, including several hundred beta test sites. I'd like to say that I'm shocked that a bug found it's way into 1.0, but I can honestly say that I would have been very surprised to find such a problem in the almost-ready 1.1. I'm sorry if this problem caused you any trouble. One workaround for now would be to insert the lines: @ 5,1 get homeprice clear gets @ 5,1 say space(12) before the DO WHILE loop. It seems that Ctrl-End causes the GET code to return without completely cleaning up the PICTure processing variables. The workaround goes into GET and leaves cleanly. Maybe our new motto should be: We're working on it. /alastair/ Disclaimer> The usual; these are my opinions, not those of my employer and if I've said anything that violates my trade secrecy agreement then I didn't mean to and may I be struck by lightning and legal stuff like that.