Article View: borland.public.cppbuilder.database.multi-tier
Article #1683Re: Another slant on the patch problem
From: aphrael
Date: Tue, 27 Jul 1999 00:00
Date: Tue, 27 Jul 1999 00:00
50 lines
2890 bytes
2890 bytes
In article <3796F0CB.48790F91@salts.navy.mil>, John Graham <jgraham@salts.navy.mil> wrote: >however, I do expect it to work. And I expect a factory created patch to not >cause problems that did not exist prior to the update. That's a fair expectation, and in this case I must say that the problem is essentially my fault. Prior to the patch, tlibimp did not convert pointers to built-in-interfaces to smart interface wrappers. It was always intended that tlibimp do this, and (along with a number of other features that didn't quite make the cut), it was decided to add the feature in the patch. I should have objected; unfortunately, I did not know better at the time. What happened is that the implementation file generator attached to the type library editor also had knowledge of the IProvider* type. So we patched that --- establishing a disconnect: the generator, and the importer, would now create code that was inconsistent with code generated in the unpatched version. Unfortunately, there was no way to teach the generator to automagically convert the unpatched code; this has to be done by hand, by changing all IProvider* references to IProviderPtr references and re-registering the type library. Note that there should be no problem whatsoever with completely new projects: i've tested about a dozen now, and all of them have worked flawlessly. The problem only exists in projects taken from the unpatched version to the patched version. >I have repeated this problem using the EmpEdit example supplied. I simply >compiled and linked both the app server and client projects with the updated >version of BCB4 and it worked flawlessly running the server locally as well as >on one of our remote NT Servers. >I then built a new app sever being careful to duplicate the lashup in the >original and compiled and linked it. I registered everything and came up with >the same "Interface Not Supported" error pointing to utilcls.h when the client >connected to the server as I experienced with my own application. When I get some free time --- say, in a week or so --- I will do this (I haven't), and then post the results. Robert West Borland QA -- Caminante, son tus huellas el camino, y nada mas; caminante, no hay camino, se hace camino al andar ... Caminante, no hay camino, sino estelas en el mar.
Technical Details
Message-ID:
<7nloia$pru$1@rspitz.inprise.com>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<3791FB86.923BE652@salts.navy.mil> <7n6buq$la622@forums.borland.com> <3796F0CB.48790F91@salts.navy.mil>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fcd2b,e64518dbee1d18e6 X-Google-Attributes: gidfcd2b,public From: aphrael@magescave.blackforest.org Subject: Re: Another slant on the patch problem Date: 1999/07/27 Message-ID: <7nloia$pru$1@rspitz.inprise.com> X-Deja-AN: 506028310 References: <3791FB86.923BE652@salts.navy.mil> <7n6buq$la622@forums.borland.com> <3796F0CB.48790F91@salts.navy.mil> Organization: association of modern mages Newsgroups: borland.public.cppbuilder.database.multi-tier