Yes this has been my plan in some ways. ATM, the offsets are stored in an INI file, but only for ONE device type. I have about 10 diff. lines of data from diff. devices and I will build up a DB of these offsets for each device, but the problem is there is more than one line that can come out of each device, and there is not always anything to uniquely identify the device, but when the software is setup, we know what device it is so thats ok. The problem is, so do thinks like if there is a * beside one number, then that number and another number are swaped, and another item is set to blank. its weired data at times, that needs a lot of configuration. I CAN get away from using classes but you can imagine what the functions would look like !! This is also not very scalable. Where as with a class, even if it is part of the EXE and for a new device I have to release a new version of the EXE, the functions will be device specific, still have the same names like, "DetermineDate" or "DetermineTime" etc.
I just wondered if there was a nice way to do this, and the only way is like Dennis said to put them into a package, but if I did use a package, I would put all the classes in the one DPK rather than one per device. Jeremy -----Original Message----- From: Kurt at DBC <[EMAIL PROTECTED]> To: Multiple recipients of list delphi <[EMAIL PROTECTED]> Date: Wed, 06 Aug 2003 10:39:23 +1200 Subject: Re: [DUG]: What is the best way > Jeremy Coulter wrote: > > Hi All. > > I have got an app. that gets data from devices via the comport. > > 60% if not more of the data from these devices is similar or easy to > > deal with, like dates and times, but other info can be specific to a > > device, and i have to normalize it into a format that I want. > > > > Could you somehow specify all your known interfaces, > then determine whether you can detect the device based on that? > > So in a data file you'd have : > > devicetype=thingy > char1=X > dataformat: > char2-11=date > char12-16=currenttemp > char17-19=unused > ... > devicetype=widget > char1=Y > ... > devicetype=acme widget > char2=0 > > Then you could do: > > if Str[1] = 'X' then // this is a thingy > // so we know : > // first 10 chars are date > // next 5 chars are current temperature > // next 3 chars are meaningless > // .... > if Str[1] = 'Y' then // this is a widget > if Str[2] = '0' then // this is an ACME brand widget > > In effect, building up your own language for defining comport > interfaces? > Then upgrading your app would mean only updating the definition > file. > > Actually, you could even go further in that file include what happens > to each segment of the string ie: > > devicetype=thingy > char1=X > dataformat > char2-11=date > dataformat: > char2-11=insert into device_table.date_of_access > char12-16=insert into device_table.current_temp > > > Or have I gone way off track? > > Cheers, Kurt. > > ----------------------------------------------------------------------- > ---- > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
