Re: [fpc-pascal] TSortedCollection dupes ordering
2014-02-07 waldo kitty wkitt...@windstream.net: On 2/6/2014 1:47 PM, Jim Leonard wrote: On 2/6/2014 11:04 AM, waldo kitty wrote: ahh... i see what you are doing... you are passing the pointer to the whole record instead of just the needed key... hummm... i'll have to think about that and how to do it in my app... right now i'm only passing the necessary key because the record is 'large'... but then again... some thought and meditation is necessary ;) Not much thought required -- a pointer to the record is 4 bytes, no matter how large the record is. yep! i realized this when i was going back thru the code cleaning it up and letting the other side of my brain wander about in its own world ;) In fact, it's probably faster than what you're doing, and more flexible. i was sending the pointer to field's contents ;) [time passes] well, i thought i was... my KeyOf routine does a cast using PTLERec(Item)^.catnbr but my (TLE) compare is apparently only sending the pointer to the catnbr string because the cast there is simply PString(Key1)^ and PString(Key2)^ the only place i understand that my (TTLEColl) compare is in play is in If NOT Search(KeyOf(Item), I) OR Duplicates Then // Item valid from the TTLEColl.Insert routine override that i posted previously... that Insert routine is taking a pointer to an entire record... 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. 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. 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. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
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
Re: [fpc-pascal] TSortedCollection dupes ordering
2014-02-06 waldo kitty wkitt...@windstream.net: On 2/5/2014 3:57 AM, Frederic Da Vitoria wrote: [...] Once again I did not test this, but it seems to me that if Compare returned -1 instead of 0, any duplicate would be inserted after because it would never be considered as equal to any other. But since you still want your collection to be able to choose between skipping duplicates or keeping them, the Compare modification would have to be slightly more subtle, something like: if result = 0 and Duplicates then result := -1 at the end of the Compare function. i tried this and it kinda works... it keeps the entries in their original order but... 1. the final logging of each item's record number (position in the collection) is -1 2. it doesn't help to sort them in order by a different field i'm unsure what to do or how to handle this so that there is a secondary (sub) sorting order so that the main key is the master sort and then a secondary key is used when duplicates are allowed... ideally, the secondary key would retain the original order in the case that the secondary key is exactly the same as a previous secondary key... but this is also problematic... to try to clarify: sometimes there are records released with exactly the same time stamp (epoch in my code i posted) but slightly different data within the record... there is another field that might be used to differentiate those BUT the records come from numerous locations... they may or may not use this tertiary key and if they do, their numbering in this tertiary key may not be the same as any other system's count for this tertiary key... this is a problem i don't know how to solve as there is no coordination between locations and no master coordinator for this tertiary key... it becomes even more apparent because my flow doesn't take any certain record containers before any others... they are read and processed as they appear (OS ordering actually) which may cause newer records with an identical time stamp to be processed after others... in my current design, i'm using first come, first served meaning that the first record processed is the one that is retained... with dupes, this doesn't matter so much but it does all still come into play... Then my trick does not work for you because it hides the fact that the records are identical. You need to give to someone the responsibility of giving the secondary key. If I understand what you wrote correctly, there is already something which could be used as a tertiary key, but it doesn't really work because the way it is filled is not consistent across the different sources. If I were you, I'd keep this tertiary key data (I guess it is meaningful, so you can't remove it), and I'd create my own secondary key inside the TSortedCollection descendant. I'd use 2 compare functions, - one which works as your current one but wouldn't be declared as a compare function (you could call it CheckPrimaryExists) and which would return 0 if the primary key already exists - and one which uses both the primary and the secondary key as Jim suggested. The algo (when duplicates are allowed) would be something like: if primary key exists then set secondary key to a number insert the data Note that depending on the total number of rows, you could use a general counter for the secondary key, no need to fetch the value of the last secondary key for the same primary key. You'd get something like (primary key / secondary key) A / 0 B / 0 B / 1 (duplicate detected, first secondary key generated) C / 0 C / 2 (duplicate detected, second secondary key generated, note that there is no C1) ... ... and now that I think of it, you don't need 2 compare functions, the second one should work for both usages. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/5/2014 7:48 PM, Jim Leonard wrote: On 2/5/2014 5:24 PM, waldo kitty wrote: i'm unsure what to do or how to handle this so that there is a secondary (sub) sorting order so that the main key is the master sort and then a secondary key is used when duplicates are allowed... You put both key comparisons in the same .Compare function. interesting... In one of my Turbo Pascal projects, I used this: PSystems=^TSystems; TSystems=object(TSortedCollection) function Compare(Key1, Key2: Pointer): Integer; virtual; function GetSize:longint; end; ... Function TSystems.Compare; begin if PSystem(Key1)^.score PSystem(Key2)^.score then Compare := -1 ahh... i see what you are doing... you are passing the pointer to the whole record instead of just the needed key... hummm... i'll have to think about that and how to do it in my app... right now i'm only passing the necessary key because the record is 'large'... but then again... some thought and meditation is necessary ;) -- 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
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/6/2014 4:23 AM, Frederic Da Vitoria wrote:
Then my trick does not work for you because it hides the fact that the records
are identical.
actually, the problem comes when referencing the IndexOf() the record...
IndexOf(Item) is passed (unmodified) thru a couple of routines to finally end up
here as 'idx'... IndexOf() being the TSortedCollection IndexOf() routine...
Procedure LogTLEPerApo(tleRecord: PTLERec; idx: sw_integer; var oFile: text);
begin
WriteLogLine(AppLogFile,0,
PadLeft(IntToStr(idx),5)
+ ' ' + PadRight(tleRecord^.catnbr^,5)
+ ' ' + PadRight(tleRecord^.cospar^,8)
+ ' ' + PadRight(tleRecord^.satname^,27)
+ ' ' +
PadRight(AddChar('0',FloatToStrF(tleRecord^.epoch,ffFixed,15,8),14),15)
+ PadRight(displayEpochString(tleRecord^.epoch),19)
+ ' ' + PadLeft(FloatToStrF(tleRecord^.Perigee,ffFixed,15,8),16)
+ ' x ' + PadLeft(FloatToStrF(tleRecord^.Apogee,ffFixed,15,8),16)
+ ' x ' + PadLeft(FloatToStrF(tleRecord^.Inclination,ffFixed,15,8),16)
+ ' ' + PadLeft(FloatToStrF(tleRecord^.SMajAxisKM,ffFixed,15,8),16)
+ ' ' + PadLeft(FloatToStrF(tleRecord^.MMPeriod,ffFixed,15,8),16)
+ ' ' + PadLeft(FloatToStrF(tleRecord^.SMAPeriodC,ffFixed,15,8),16)
+ ' ' + PadLeft(FloatToStrF(tleRecord^.SMAPeriodP,ffFixed,15,8),16)
);
WriteOUTFile(tleRecord,oFile);
inc(tot_TLEs_written);
end;
You need to give to someone the responsibility of giving the secondary key.
that's not going to happen... anyone can generate these records and make them
available to others for use... i'm aware of at least 5 different groups and
several owners of the objects who are generating these...
If I understand what you wrote correctly, there is already
something which could be used as a tertiary key, but it doesn't really work
because the way it is filled is not consistent across the different sources.
right... for the same reason as above...
If I were you, I'd keep this tertiary key data (I guess it is meaningful, so
you can't remove it),
right... it is part of the format... some records don't even have this tertiary
key filled in...
and I'd create my own secondary key inside the TSortedCollection descendant.
hummm... one group does something similar but i currently don't have any method
of doing this... in all actuality i should probably be doing this in a sql
database but the overhead of processing speed and storage space is more than i
want to deal with... especially since a full processing run using all options
takes less than a minute for ~4 records and a previous tool (limited to 64k)
takes almost 30 minutes...
I'd use 2 compare functions,
- one which works as your current one but wouldn't be declared as a compare
function (you could call it CheckPrimaryExists) and which would return 0 if the
primary key already exists
- and one which uses both the primary and the secondary key as Jim suggested.
The algo (when duplicates are allowed) would be something like:
if primary key exists
then set secondary key to a number
insert the data
definitely something for me to contemplate on...
Note that depending on the total number of rows, you could use a general counter
for the secondary key, no need to fetch the value of the last secondary key for
the same primary key.
You'd get something like (primary key / secondary key)
A / 0
B / 0
B / 1 (duplicate detected, first secondary key generated)
C / 0
C / 2 (duplicate detected, second secondary key generated, note that there is
no C1)
...
... and now that I think of it, you don't need 2 compare functions, the second
one should work for both usages.
this is one of the things i like about talking about problems... while others
may not be fully aware of the data, they can still come up with ideas on how to
handle situations... one of the things i used to do was to talk to a mechanic
friend... i'd convert my tasks and problems to something vehicle related so that
he could see it from his mechanic's point of view and then he'd ask about doing
it like this in vehical mechanic terms which i'd convert back to programming
and suddenly have a workable solution... he helped me solve more problems in
this way than i can count and he barely knew where the big red switch was on
the computers ;) ;) ;)
--
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
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/6/2014 11:04 AM, waldo kitty wrote: ahh... i see what you are doing... you are passing the pointer to the whole record instead of just the needed key... hummm... i'll have to think about that and how to do it in my app... right now i'm only passing the necessary key because the record is 'large'... but then again... some thought and meditation is necessary ;) Not much thought required -- a pointer to the record is 4 bytes, no matter how large the record is. In fact, it's probably faster than what you're doing, and more flexible. -- Jim Leonard (trix...@oldskool.org) Check out some trippy MindCandy: http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.oldskool.org/ You're all insane and trying to steal my magic bag! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/6/2014 1:47 PM, Jim Leonard wrote: On 2/6/2014 11:04 AM, waldo kitty wrote: ahh... i see what you are doing... you are passing the pointer to the whole record instead of just the needed key... hummm... i'll have to think about that and how to do it in my app... right now i'm only passing the necessary key because the record is 'large'... but then again... some thought and meditation is necessary ;) Not much thought required -- a pointer to the record is 4 bytes, no matter how large the record is. yep! i realized this when i was going back thru the code cleaning it up and letting the other side of my brain wander about in its own world ;) In fact, it's probably faster than what you're doing, and more flexible. i was sending the pointer to field's contents ;) [time passes] well, i thought i was... my KeyOf routine does a cast using PTLERec(Item)^.catnbr but my (TLE) compare is apparently only sending the pointer to the catnbr string because the cast there is simply PString(Key1)^ and PString(Key2)^ the only place i understand that my (TTLEColl) compare is in play is in If NOT Search(KeyOf(Item), I) OR Duplicates Then // Item valid from the TTLEColl.Insert routine override that i posted previously... that Insert routine is taking a pointer to an entire record... so now i'm a bit confused but it has been a long day... again... :/ -- 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
Re: [fpc-pascal] TSortedCollection dupes ordering
2014-02-05 waldo kitty wkitt...@windstream.net: On 2/4/2014 5:16 PM, Frederic Da Vitoria wrote: 2014-02-04 waldo kitty wkitt...@windstream.net mailto: wkitt...@windstream.net: [...] i kinda thought about that earlier when i was digging thru the code... IIRC, insert was overridden because there are cases where the existing record needs to be replaced (because the new record is newer) using AtPut and the non-added records must be logged and their reason for not being added (older or same)... Just a quick idea which could be completely wrong, but wouldn't it solve your issue if Compare always returned -1 instead of 0? no, because i lose (at least) the logging of why the record was tossed out... see below... Hm, yes, you don't always want to keep duplicates. it wouldn't help with the duplicate keys being inserted in reverse order... Once again I did not test this, but it seems to me that if Compare returned -1 instead of 0, any duplicate would be inserted after because it would never be considered as equal to any other. But since you still want your collection to be able to choose between skipping duplicates or keeping them, the Compare modification would have to be slightly more subtle, something like: if result = 0 and Duplicates then result := -1 at the end of the Compare function. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/5/2014 3:57 AM, Frederic Da Vitoria wrote: [...] Once again I did not test this, but it seems to me that if Compare returned -1 instead of 0, any duplicate would be inserted after because it would never be considered as equal to any other. But since you still want your collection to be able to choose between skipping duplicates or keeping them, the Compare modification would have to be slightly more subtle, something like: if result = 0 and Duplicates then result := -1 at the end of the Compare function. i tried this and it kinda works... it keeps the entries in their original order but... 1. the final logging of each item's record number (position in the collection) is -1 2. it doesn't help to sort them in order by a different field i'm unsure what to do or how to handle this so that there is a secondary (sub) sorting order so that the main key is the master sort and then a secondary key is used when duplicates are allowed... ideally, the secondary key would retain the original order in the case that the secondary key is exactly the same as a previous secondary key... but this is also problematic... to try to clarify: sometimes there are records released with exactly the same time stamp (epoch in my code i posted) but slightly different data within the record... there is another field that might be used to differentiate those BUT the records come from numerous locations... they may or may not use this tertiary key and if they do, their numbering in this tertiary key may not be the same as any other system's count for this tertiary key... this is a problem i don't know how to solve as there is no coordination between locations and no master coordinator for this tertiary key... it becomes even more apparent because my flow doesn't take any certain record containers before any others... they are read and processed as they appear (OS ordering actually) which may cause newer records with an identical time stamp to be processed after others... in my current design, i'm using first come, first served meaning that the first record processed is the one that is retained... with dupes, this doesn't matter so much but it does all still come into play... -- 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
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/5/2014 5:24 PM, waldo kitty wrote:
i'm unsure what to do or how to handle this so that there is a secondary
(sub) sorting order so that the main key is the master sort and then a
secondary key is used when duplicates are allowed...
You put both key comparisons in the same .Compare function.
In one of my Turbo Pascal projects, I used this:
PSystems=^TSystems;
TSystems=object(TSortedCollection)
function Compare(Key1, Key2: Pointer): Integer; virtual;
function GetSize:longint;
end;
...
Function TSystems.Compare;
begin
if PSystem(Key1)^.score PSystem(Key2)^.score
then Compare := -1
else if PSystem(Key1)^.score PSystem(Key2)^.score
then Compare := 1
{Score is the same. Second search key (larger numbers are worse:}
else if usectotal(Key1) usectotal(Key2)
then Compare := -1
else if usectotal(Key1) usectotal(Key2)
then Compare := 1
{usec totals same. Third search key:}
else if PSystem(Key1)^.BIOSCRC16 PSystem(Key2)^.BIOSCRC16
then Compare := -1
else if PSystem(Key1)^.BIOSCRC16 PSystem(Key2)^.BIOSCRC16
then Compare := 1
else Compare := 0;
end;
--
Jim Leonard (trix...@oldskool.org)
Check out some trippy MindCandy: http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.oldskool.org/
You're all insane and trying to steal my magic bag!
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/4/2014 1:40 PM, waldo kitty wrote: i have a TSortedCollection that i'm allowing duplicate keys to be inserted in... the problem that i'm having is that the duplicate keys are in reverse order from how they were inserted... Sounds like your TSortedCollection.Compare() needs additional logic. It isn't doing enough comparisons internally to order things properly. i am overriding MyCollection^.Insert because i have additional tasks that need to be done at the time of insertion... without duplicate keys, Wouldn't it be better to perform your additional tasks before the insertion, then call a normal .Insert? Why overload something if there isn't really a need to? -- Jim Leonard (trix...@oldskool.org) Check out some trippy MindCandy: http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.oldskool.org/ You're all insane and trying to steal my magic bag! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/4/2014 3:28 PM, Jim Leonard wrote: On 2/4/2014 1:40 PM, waldo kitty wrote: i have a TSortedCollection that i'm allowing duplicate keys to be inserted in... the problem that i'm having is that the duplicate keys are in reverse order from how they were inserted... Sounds like your TSortedCollection.Compare() needs additional logic. It isn't doing enough comparisons internally to order things properly. possibly... i dunno... currently it compares the (pstring) keys only... i thought about trying to also include a second field (a double) which is used for the time stamp but i don't know how to do that without having to use the key and this time stamp field every time i do anything with the records... i am overriding MyCollection^.Insert because i have additional tasks that need to be done at the time of insertion... without duplicate keys, Wouldn't it be better to perform your additional tasks before the insertion, then call a normal .Insert? Why overload something if there isn't really a need to? i kinda thought about that earlier when i was digging thru the code... IIRC, insert was overridden because there are cases where the existing record needs to be replaced (because the new record is newer) using AtPut and the non-added records must be logged and their reason for not being added (older or same)... -- 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
Re: [fpc-pascal] TSortedCollection dupes ordering
2014-02-04 waldo kitty wkitt...@windstream.net: On 2/4/2014 3:28 PM, Jim Leonard wrote: On 2/4/2014 1:40 PM, waldo kitty wrote: i have a TSortedCollection that i'm allowing duplicate keys to be inserted in... the problem that i'm having is that the duplicate keys are in reverse order from how they were inserted... Sounds like your TSortedCollection.Compare() needs additional logic. It isn't doing enough comparisons internally to order things properly. possibly... i dunno... currently it compares the (pstring) keys only... i thought about trying to also include a second field (a double) which is used for the time stamp but i don't know how to do that without having to use the key and this time stamp field every time i do anything with the records... i am overriding MyCollection^.Insert because i have additional tasks that need to be done at the time of insertion... without duplicate keys, Wouldn't it be better to perform your additional tasks before the insertion, then call a normal .Insert? Why overload something if there isn't really a need to? i kinda thought about that earlier when i was digging thru the code... IIRC, insert was overridden because there are cases where the existing record needs to be replaced (because the new record is newer) using AtPut and the non-added records must be logged and their reason for not being added (older or same)... Just a quick idea which could be completely wrong, but wouldn't it solve your issue if Compare always returned -1 instead of 0? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSortedCollection dupes ordering
On 2/4/2014 5:16 PM, Frederic Da Vitoria wrote:
2014-02-04 waldo kitty wkitt...@windstream.net
mailto:wkitt...@windstream.net:
[...]
i kinda thought about that earlier when i was digging thru the code... IIRC,
insert was overridden because there are cases where the existing record
needs to be replaced (because the new record is newer) using AtPut and the
non-added records must be logged and their reason for not being added (older
or same)...
Just a quick idea which could be completely wrong, but wouldn't it solve your
issue if Compare always returned -1 instead of 0?
no, because i lose (at least) the logging of why the record was tossed out...
see below... it wouldn't help with the duplicate keys being inserted in reverse
order...
Procedure TTLEColl.Insert(Item: Pointer);
var
I : Sw_Integer = 0;
old : Pointer;
foo : integer = 0;
begin
I := 0;
If NOT Search(KeyOf(Item), I) OR Duplicates Then // Item valid
begin
logTLEEntryType('M'); // MERGE this TLE
AtInsert(I, Item);// Insert the item
// Insert(Item); // Insert the item
inc(cur_TLEs_added); // increment the add counter
end
else // otherwise
begin
foo := CompareReal(PTLERec(At(i))^.epoch,PTLERec(Item)^.epoch); //
compare the epochs
case foo of
-1 : begin // replace existing record
logTLEEntryType('U');// UPDATE this entry
old := At(i);// save existing pointer
first!
AtPut(i, Item); // now put in the new record
dispose(PTLERec(old),done); // dispose old one
inc(cur_TLEs_updtd); // increment the updated
counter
end;
0 : begin // we're tossing this one
out
logTLEEntryType('S');// this entry is the SAME
dispose(PTLERec(Item),done); // dispose the item
inc(cur_TLEs_same); // increment the same
counter
end;
1 : begin // we're tossing this one
out
logTLEEntryType('N');// the existing entry is
NEWER
dispose(PTLERec(Item),done); // dispose the item
inc(cur_TLEs_old); // increment the old counter
end;
end; // case
end;
end;
--
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
