Found that the leading \0 was the cause/reason-to-blame for the cbo's
misbehavior. Retooled the CreateKey method by adding this before the
return:
IF LEFT(lcKey,1) = '\' THEN && try again..don't like those as it caused
issue with cboJobType
lcKey = this.CreateKey(tiLevel)
ENDIF
On 2014-06-10 16:17, [email protected] wrote:
On 2014-06-10 16:15, [email protected] wrote:
I had a record where the primary key was '\0|±ß pM•wÑ©9†‚' (without
the beginning/ending quotes) and the cbo to which it was tied didn't
like it. I'm not sure if it was the leading \0 or the , near the end.
Thoughts? I'm gonna have to retool my key generation routine to
reseed it if detects either character, methinks.
Here's the routine I use:
FUNCTION CreateKey(tiLevel as Integer) as String
* Returns newly created GUID using class from VFP2C32.
LOCAL lcKey as String
* 0 = ansi human readable (38 wide)
* 1 = unicode (76 wide)
* 2 = binary (16 wide)
IF VARTYPE(tiLevel) <> "N" THEN
tiLevel = this.iDefaultKeyLevel
ENDIF
IF NOT ("vfp2c32.fll" $ SET("Library")) THEN && mjb 04-16-14 minor
tweak. Happy birthday, Bob! :-)
SET LIBRARY TO vfp2c32.fll && mjb 05-17-14 took out LOCFILE
ENDIF
lcKey = CreateGUID(tiLevel)
RETURN lcKey
ENDFUNC && CreateKey() as String
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
