 Home |
 Content |
| Purchase |
| Ready-to-use samples |
| Online resources |
| Forum |
| Links |
| Happy readers |
Anonymous
A problem (and solution) with OSLockObject (by James Joyce, 02/27/2004 11:14:49 PM) |  |
Normunds,
Congratulations on a wonderful book; it's been very helpful to me. I have, however, found a problem and solution, that I'd like to share with you.
I've been interested in tracking changed attachments (in R5.0.10), so I've been doing calls to NSFItemInfo, NSFItemQuery, OSLockObject and NSFItemInfoNext to fetch the file name, file size and last modified date.
During my development, things were going fine, but when I got to the point of testing against some production data, I started getting inconsistent results--sometimes right, but other times wildly wrong. With some mucking around, I discovered that in the problem cases, the document was always unreasonably large and theBlockID.block value was always negative. Having convinced myself that this was the problem, I began reading my code again, and found the equivalent of
pBuff = OSLockObject(theBlockID.pool) theBlockID.block
With some thought I realized that signed arithmetic was causing my problem and with that in mind, I went back to your book and found the discussion on page 125
' to simulate OSLockBlock macro — for small offsets it's OK
pBuff = OSLockObject(theBlockID.pool) theBlockID.block
' in order to take in account the fact that Block is actually unsigned we may use
pBuff = OSLockObject(theBlockID.pool) (CLng(theBlockID.block) And &h0FFFF)
' in this way we accommodate also Block values >32K
This was great, since it confirmed my suspicion, and even better because it showed a solution. The solution, however, did not work. Some additional fiddling, involving 65535 (the decimal version of 0x0FFFF) and careful reading of the Designer Help file showed why. In the "Literal number construction rules" topic, I found
A hexadecimal number is expressible in 1 to 8 significant hexadecimal
digits (excluding leading zeroes). If the number falls within the
range for Integer values, its data type is Integer; otherwise, its
data type is Long.
With some thought, I realized that &h0FFFF did, indeed, "fall within the range for Integer values", and so was an integer. When it came time to do the And, LotusScript promoted the Integer to a Long, with, of course, sign extension, so it became 0xFFFFFFFF, yielding the same result as the signed arithmetic.
The next column in the table in the Help topic provides the answer:
% forces Integer & forces Long
So what really works in this situation is:
pBuff = OSLockObject(theBlockID.pool) (CLng(theBlockID.block) And &h0FFFF&)
with the final & forcing the value to be a Long, that is 0x0000FFFF, so the masking works as intended. This has resolved my immediate problem, but, of course, I'm now worrying about the original pointer returned by OSLockObject being negative, as you discuss on pp. 125 & 126.
Using 65535 in place of &h0FFFF& works fine, too, but the intention of the code is not very clear; it seems to me that LS is drawing a very fine line in saying that 65535 doesn't "fall within the range for Integer values" but &h0FFFF does, after all, the 0 would seem to require 4 bits. On the other hand, I've learned not to argue with compilers, as they win all too often.
I'm parsing out the FILEOBJECT using Rod Whiteley's code in the R4 & R5 Forum at http://www-10.lotus.com/ldd/46dom.nsf/c21908baf7e06eb085256a39006eae9f/9c111e79a8b75c9380256adc005e6a9e?OpenDocument. I appreciate your discussion of FILEOBJECT, but didn't have much luck with Cmovmem--Red Boxed--and I had found his code first and adapted it to my use. Since development is alway Just In Time, I went with what worked (and there was the question of how to get the filename out of memory with a FILEOBJECT Type.)
Also, while I'm on about things, thanks for the PDF. Not only was it useful while I was waiting for the Latvian stamps (worth the wait), but I also frequently use it to search for where something is in the book and then go to the hard copy to read it.