Claus I've been writing client/server apps using Delphi, VB and UniObjects since - well basically the day each one came out. It is a very powerful combination and works well, so long as you take the right approach.
Server Logic: Make sure all of your server logic is built into subroutines: that way you can test them independently of the front end - I would recommend building a test rig as the first step. TThe biggest problem with developing C/S apps is debugging across the divide, and by verifying the server logic first you sidestep any finger-pointing issues. Delphi: I would echo Chuck's advice on using a VCL based approach. The problems with ActiveX and/or DLLs are a) ActiveX depends too much on system DLLs, If you have a single Windows platform to which to deploy this is not a problem but developing products like uvCase and mvQuery we spent a huge amount of time just testing installations for various different windows platforms, service packs etc. It really eats into the timescales, and can be very frustrating. B) there are some issues with string handling between the ActiveX BSTR and Delphi strings, especially if you need to work with large strings. They get copied in memory, encoded in and out of Unicode strings, and you can end up with 7 or 8 copies in memory if you are not careful. I've also encountered issues where successive reallocations of memory (eg. building up large strings from data packets) can fail to free correctly if they are done repeatedly in a short timeslice - it doesn't make sense but I've hit that a couple of times and had e.g. a 1MB string using up > 200MB memory. (Putting delays into the process fixes that.) C) If you use native Delphi DLLs there are some issues with their shared memory manager (required to pass Delphi strings between DLLs) being incompatible between different versions of Delphi. So if you install an app that uses the ShareMem unit on a PC that already has a Delphi app running, that app may well break. Mixing Platforms: On the plus side, you can mix and match Delphi and VB by writing activex components and DLLs in Delphi. I have used this approach quite often, building an initial framework (a kind of working prototype) in VB and then replacing the VB code over a period with Delphi. This gets a project up and running very quickly - VB is faster to customize particularly in terms of presentation - and the project can be cut at successive stages as the more powerful Delphi capabilities are back-built into the project. It also allows you to leverage a wider skills base - Delphi is a more professional solution but finding VB resource is a lot easier. Brian ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
