Thanks Richard, It would not be possible for ABC to exist in Person1 and Person2 in the same row, but its no harm using the syntax you describe to circumvent it in case it were to happen.

Yeah i suppose it make the code more flexible going forward but does add a level of complexity that may make it harder for a newbie to just jump in to the code base.

Folks, Question about my design so far, I am wondering if i am going about this the right way? I have a COM Library created in C#, with COMVisible set to true. This library talks to a 3rd party WebService calling various methods depending on the task at hand. For each Request / Response class exposed by the 3rd party DLL I have a Request / Response Pair (Class and Interface) to Marshal variables specifically for a VC6 application. Mainly using: MarshalAs(UnmanagedType.LPStr)] So with that in my i have added a C# project to the solution to test this code, see test method below: static void Main(string[] args) { ICOMReq iReq = new CCOMReq(); ICOMRsp iRsp = new CCOMRsp(); Link l = new Link(); iReq.Date\_Time = DateTime.UtcNow; iReq.Var2 = "1023758145865"; l.DoMethod1(iReq, out iRsp); //Handle COM Response here } The link class looks like so at the moment be but will have all the methods created once the design is correct: public class Link { public bool DoMethod1(ICOMReq _COMReq, out ICOMRsp COMRsp) { Method1 WebServiceMethod = new Method1(new Method1Request(), new Method1Response(), (CCOMReq)_COMReq, new CCOMRsp()); WebServiceMethod.Process(); //Just test code at the moment COMRsp = null; return true; } } Each DoMethod(N) that will be in the link class will look the same performing its task with identical code to the other DoMethods. The key differences between the methods is the Param Types Passed in and the Method1 (Method1Request/Method1Response) type will vary depending on the webmethod to be called. Class Method1 (There will be one of these for every method I need to implement on the WebService) looks like so: public class Method1 : WebServiceInterfaceBridge { public Method1(Method1Request WEB\_Req, Method1Response WEB\_Rsp, CCOMReq COM\_Req, ICOMRsp COM\_Rsp) : base(WEB\_Req, WEB\_Rsp, CBE\_Req, CBE\_Rsp) { WEB\_Req.SOME\_DATE\_TIME = COM\_Req.Date\_Time; } public new void Process() { base.Process(); } public override void LOG() { Console.WriteLine(this.WebMethod\_Request.MEMBER\_VAR\_HERE);

You could implement the IComparable interface in your class, and then define the CompareTo function. Put your comparison logic in this CompareTo function. Then all you would need to do is call the Sort method on your collection. MyNewCol.Sort() Roy.

Wow, couldn't have said it better myself! :) :) Thanks Alan! April Comm100 - Leading Live Chat Software Provider

Anybody?

Hi Keith, KeithF wrote: Am I on the right tracks here? yes, well, maybe. I did not study your code in much detail, I do see a state-machine-like approach, which could be fine; however I have issues in several aspects: 1. I'm not sure I know enough about your "protocol" to judge the approach. As I said, what you need as an implementation heavily depends on your protocol. e.g. what should happen when an unexpected response is received (say you send an ENQ and then receive an ETX where it "should" have been an ACK) 2. I didn't see your actual transmit and receive operations; is your receiver operating asynchronously (i.e. using a completion event)? or blocking (i.e. just read-and-wait-till-done)? 3. You seem to somewhat merge, then split, inbound and outbound messages; not sure why. 4. Whatever the goals and needs, I'm pretty sure my code would look quite differently, but that is a matter of style. In particular I'm not fond of methods that need data, don't get it as a parameter, and then go fetch it somehow (as your SendMsg-MessageToSend pair is doing). Here is what I might consider doing if your protocol is somewhat close to what I think you intend: - I would opt for (pseudo)synchronous transmit and asynchronous receive; - so I would transmit using SP.Write() and act as if the data is gone instantly (if necessary just include a sleep period that corresponds to the normal transmission time, probably not necessary at all); - and I would not read except inside the DataReceived handler. - that would halve the number of states I need, as each state typically would be an "awaiting" state, say "waiting for ACK0";       DataReceived should check the next inbound message;       if it is an ACK0, send a new message (synchronously!), adapt the state (say "waiting for "ACK1"), and return;       if it isn't, send a new message ("aborting"), set state="IDLE" (=waiting for anything), and return; - so that boils down to a big switch inside DataReceived, switching to the current state (what am I expecting?), then looking at what actually was received, react (probably by sending something) and adapt the state, so the next DataReceived switch will go to another case. That would work for simple cases; it would not cope well with slow transmission conditions: if you want overlaps (comparable to overlapped file I/O in Windows) or if your state actions are too large

Well i was a bit fast with saying that it will not be 12 bytes. Of course it depends on the compiler. I just wanted to state that its not allways 12 bytes.

Great stuff. I see that you also got some help from Ian, and Luc who knows far more about this than I do. I must get a clever new signature for 2011.

Nope. The only other thing is to check the integrity of the databases themselves. A guide to posting questions on CodeProject[^] Dave Kreskowiak

Cheers Luc, I Knew it was something simple just could not put my finger on it, i found the following code will work: Dim tst As Double Dim tst1 As Double tst = -8.4 tst1 = 8.45 tst = tst + tst1 tst = Round(tst, 2) MsgBox tst

Why go through the hassle of using regex? Just use DateTime.ParseExact, and handle the bool return value. "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

va_arg is a macro and the current code is depending on an implementation specific side effect. Somewhere in the back of mind, I recall this macro changing between 16 and 32-bit. If you have a bunch of code depending on Arg1 being a pointer to a pointer, you can do the following: char* tmpArg1; char** Arg1; tmpArg1 = va_arg( arglist, char *); Arg1 = &tmpArg1; The alternative is to bag the pointer to a pointer stuff and just use Arg1 as a char*. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

Thanks J4amieC, that looks to be what i'm looking for.

Thanks Luc Keith