I specifically don't like commas for delimiters for two reasons. Users often can enter comma's on the keyboards of portable keyboards and I like to stay away from any characters the user can enter for obvious reasons. Only very complicated keyboards provide the ability to enter the verticle bar. I also find it useful during debugging to able to look at a transaction file with an editor. The vertical bar shows up pretty well as a field separator. (I also make it a point to put a carriage return and a line feed at the end of every transaction so it makes an editable file.)
I've never had to use subfields but it might be a good idea for some future application. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roger Stringer Sent: Friday, November 07, 2003 8:49 AM To: Palm Developer Forum Subject: RE: Do you have any handy functions/libraries you would like to donate? >Subject: RE: Do you have any handy functions/libraries you would like to >donate? >From: "Dave Mottorn" <[EMAIL PROTECTED]> >Date: Thu, 6 Nov 2003 09:10:40 -0500 >X-Message-Number: 16 > >I'll Email this so you can be the judge of whether this is worth while or >not. I use a standard format to structure transactions when I'm developing >applications that are transaction-oriented. A typical transaction might >look something like this: FMOVE|W0123|LA|D03/11/06/09:45:07|E555|. This >transaction reflects that employee 555 moved work order 0123 to location A >at the time indicated. The vertical bar separates the fields and the first >letter of every field is a prefix code which makes the data >position-independent in the transaction. Why didn't you use a comma separated format, with careful use of quotes? Much more standardized..... FMOVE,W0123,LA,D03/11/06/09:45:07,E555,"ZSmith, John" (Of course, having said this, I use a CSV data format, and then use the pipe separator as a sub-field separator when necessary) >This technique has been around for decades and I didn't invent it. I've >used it to develop dozens of systems and the only problem I've run into is >I've run short of printable characters and had to use noseeums from the >upper ascii 128. Yes, using a fixed single byte field identifier is restrictive, so you might want to use the pipe to split up the data from the field ID and then use a numeric field ID: FMOVE,23|0123,12|A,4|03/11/06/09:45:07,5|555,"26|Smith, John" The core code would then be: const Char * ParseQuotedField (Int16 *id, Char *dest, Int16 max, const Char* src); // returns ptr to start of next field, or NULL Int16 ProcessData (const Char * src) { Int16 iFieldID, i, iCount = 0; Char field[MAX_FIELD_SIZE + 2], action[12]; const Char *cptr = ParseQuotedField (&iFieldID, action, sizeof(action) - 2, src); if (!*action) return 0; while (cptr != NULL && *cptr) { iCount++; if (*cptr == ',') {cptr++; continue;} // skip over empty field cptr = ParseQuotedField (&iFieldID, field, sizeof(field) - 2, cptr); if (*field && iFieldID) { // process field .............. } } return iCount; } Roger Stringer Marietta Systems, Inc. (www.mariettasystems.com) -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
