Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Mon, 17 Nov 2008 15:39:01 +1100, "Arthur Barrett" <arthur.barrett at march-hare.com> wrote: >Tony, > >> It's a lot more than a couple of days work.. most of the API >> is C++ and has all sorts of dependencies. >> > >I was thinking of a very very basic implementation of just >CGlobalSettings and CLibraryAccess, not the whole API. > >Besides I didn't say I'd finish it in a couple of days, but that it'd >give Bo something to work with, eg: if Bo can see what pattern I'm >following then maybe he or someone else can offer to finish it off >themselves... Don't put too much weight on my interest. I cannot promise to do a lot because I still have only limited time free.... I hate to see you lose time over this just because I started commenting on this subject. I think I will first make a simple approach and build on the code supplied by Ronaldo Capaverde after converting it to MSSQL and also making it more configurable for other ADO database connections. The original code has (in my view) put too much into designtime component properties. I will most probably change that into regular objects instead. If that works out OK I may look at the database end via the audit API calls. So first test using the parsing of RCS files from Ronaldo Capaverde but towards a MSSQL database. Next I will probably test it using ODBC against a SQLite database. Then switching to getting the info via regular cvs calls rather than direct access to the RCS files. Have to figure out how to do that in a good way though. Any ideas how ViewVC did it when they switched from GNU rcs calls to using the cvsnt cvs.exe? Finally trying to get the database stuff going via audit API calls (if at all possible for me). THis would decouple the database knowledge from the importer. >COM is an interesting suggestion, but I wouldn't spare more than a >couple of minutes thinking about it until someone confirmed that things >like Delphi really play well with it. I know from experience that even >though Uniface supports COM there are many COM types that it doesn't >support and I wouldn't be at all surprised to learn that other languages >have similar limits on the COM support. Secondly many developers 'need' >to learn how to call Win32 'C' functions but never bother to learn how >to call COM functions. At least any effort put into a 'C' API (for want >of a better term) will benefit the largest possible base of users >(windows/hp/solaris etc). > COM is a pig! We use COM (or rather DCOM) in our automation software since 2002. It has caused a lot of grief concerning the handling of the type libraries and the evolution of those in order not to crash older versions of our software. Microsoft has failed to make a reasonable way to version type libraries so that an installer can check that it does not inadvertently replace a newer tlb with an older one, thus breaking existing installed applications! We had to make a dll out of the tlb and include our own versioning info in that so we can make the installer (still InnoSetup!) do the right thing. Very strange errors can also happen like when a customer had a service pack for XP installed and the system stopped working. Noone even knew about the SP at first and we tried in vain to get it going until we finally found that the SP had changed the fundamental base handling in Winows of DCOM and RPC. Had to put a strange registry entry in place to fix that.... And lost about a week's worth of service engineer time on location (of course half way across the world too). Not funny. Unfortunately we are now stuck with it... Had we known at the time we might have designed the whole system without COM.... -- /Bo (Bo Berglund, developer in Sweden)