On 2/7/2014 4:06 AM, Frederic Da Vitoria wrote:
2014-02-07 waldo kitty <wkitt...@windstream.net
<mailto:wkitt...@windstream.net>>:
[...]
so now i'm a bit confused but it has been a long day... again... :/
This makes sense... at least in your previous version: I guess catnbr is a
string.
yes...
Compare uses whatever KeyOf returns, and since KeyOf returns the address
of a string, Compare handles the keys as such. To compare more than 1 field, the
simplest way would be for KeyOf to return the address of the TLERec, which is
the behavior of TSortedCollection.KeyOf
http://lazarus-ccr.sourceforge.net/docs/rtl/objects/tsortedcollection.keyof.html
.
i've read that numerous times but...
So IMO you should simply remove your implementation of KeyOf and edit Compare
so that it receives PTLERec and uses the relevant fields instead of a simple
string.
seriously? [/rhetorical] son of squidly! i don't know why but i've always
overridden keyof as well as compare and at least one other that i can't think of
at the moment... now that i've completed converting my "decision tree" to using
two bits per option instead of the three-state format i was using (the exe was
reduced by a few 10's of k's) i will see about working on this aspect...
while my app is in production and operating 24x7 on my systems, i still consider
it to be no more than beta stage... personally, alpha but then again, i have
pretty high testing standards for my code... while it might work, there's no way
that i would allow it out in a commercial operation without a lot more testing
and evaluation...
anecdote: some years back i wrote a messaging app to the specs for the use it
was to be placed in... those specs stated that a message identifier would not be
used within a three year period... testing of that code took just over three
years to ensure that it was to spec... running mathematical algorithms showed
that the code was up to spec but i preferred to use actual testing to make
sure... i'm my own worst critic ;)
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
