|
Short Description
|
FindNextBold doesn't return -1 if none
|
|
Entered
|
By:
PeteL
When: 1998-06-03 13:08:26 Build: 1.03.13b
|
|
Categories
|
Type:
Problem
Department: Product
Category:
SurferScript
|
Description
|
in my testing, after numerous endless loops, it seems to me that if there are no bold fields on the screen, FindNextBold returns 1920 - if there is one bold on the screen, it returns the offset, then after adding 1 to "offset", next time returns 1920, then add 1 and get initial field offset again. I don't think it should ever wrap the screen, and it should return -1 as specified of there are no "next" bolds. this could be some sort of bug in my code, or maybe there really is some silly bold attribute at the last byte of this screen, but that's what I see.
|
|
|
|
Append
|
By: WindSurfer When: 1998-06-03 17:32:13 New Status:
Accepted
|
|
Comment
|
We'll check into it and hopefully get it into 1.3.14 (this is a rogue entry that for some reason is always showing at the bottom of this ticket!)
|
|
|
|
Append
|
By: WindSurfer When: 1998-06-09 15:34:33 New Status:
Pending Customer
|
|
Comment
|
Fixed and available at ftp://ftp.ieinc2.com/pub/surfer/T1.3.14.zip. All Findxxx() functions were going through the same base function that had this bug in it.
Question: did you know that these functions are all returning the offset of the attribute byte (not the data in the field itself)--how many places are you using this, and should the offset returned be left alone, or should it return the offset of the first data byte (current return value +1).
|
|
|
|
Append
|
By: PeteL When: 1998-06-11 10:11:56 New Status:
Pending IE
|
|
Comment
|
this is in status "waiting cust" - is it in 1.3.14?
|
|
|
|
Append
|
By: WindSurfer When: 1998-06-11 11:41:31 New Status:
Accepted
|
|
Comment
|
It IS in 1.3.14, and there is an apparent bug in MS Access that is revealing itself in this ticket, as the SQL clearly states order by the entered date, yet you can see that 1998-06-03 17:32:13 is appearing AFTER 1998-06-11 10:11:56. Oh joy.
|
|
|
|
Append
|
By: PeteL When: 1998-06-16 14:44:07 New Status:
Pending IE
|
|
Comment
|
now that i've read the updates in the wrong order, I see that there's an outstanding question! I'm using FindNext.... in only 1 place, but i'm using it to findnextbold, then checking for entry, and using the returned offset to do a SETCURSOR, so if the setcursor works OK being set to an attribute byte, then i guess it doesn't matter. otherwise, it would be best to set the offset to the data byte. (also, that "1 place" is used on every single page - it just happens to be common code for setting cursor to first bold entry field, if there is one on the screen)
|
|
|
|
Append
|
By: WindSurfer When: 1998-06-16 21:00:46 New Status:
Pending Customer
|
|
Comment
|
Yes, the comments were out of order, but not due to a bug in Access, but to a bug in my SQL statement definition in Screensurfer--had the closing quote BEFORE the ORDER BY...so my order by never worked anyway, but testing never revealed a problem since before the table got too full, natural order was prevailing...
That is fixed now--I'll fixe the returned value to be the data byte.
|
|
|
|
Append
|
By: PeteL When: 1998-06-19 09:29:52 New Status:
Pending IE
|
|
Comment
|
is this fix in 1.3.14?
|
|
|
|
Append
|
By: WindSurfer When: 1998-06-19 11:01:14 New Status:
Pending Customer
|
|
Comment
|
Yes- Will check this afternoon to verify FTP version is up-to-date.
|
|
|
|
Append
|
By: PeteL When: 1998-06-30 08:01:03 New Status:
Closed
|
|
Comment
|
seems to be working in the build i am running with now
|