🚀 go-pugleaf

The answer was given a week or so ago. Here is the answer.

Mark Johnson said:

-----------------------------------------------
I had this same problem.  The cause is the new tlb editor creates code with
a type IProviderPtr replacing  what used to be IProvider* in the generated
code.  If you go through all the generated source and replace IProviderPtr
with IProvider* the remote data modules will now work.  Hope this helps.

Mark Johnson
-----------------------------------------------


Panagiotis L. Staikos <pstaiko@ekt.gr> escribi� en el mensaje de noticias
37805D31.B7AF2946@ekt.gr...
> I have add at server Side (Remote DataModule)
> a TQuery Component and a TProvider(TProvider or TDataSetProvider)
> Component.
> I export the TProvider Component and it's DataSet property points to
> TQuery. The TQuery component has a SQL Statement.
> From Client Side i have a MIDAS, ClientDataset, DataSource, DBGrid
> Components.
> While i am connecting with my Server,when  i change the active property
> of The ClientDataSet to true
> (ClientDataSet Provider Property points to the Above TProvider)
> i get the Error :
> 'src->QueryInterface(GetIID(),(LPVOID*)(&intf))': No such interface
> supported
> @ C:\Program Files\Borland\CBuilder4\invlude\vcl\utilcls.h/2014
> Press [Y]es to terminate, [N]o to continue and [C]ancel to Debug.
>
> All the Providers from the server are shown in the drop-down list in the
> Provider property
> of the ClientDataSet Component!!!
>
> Prior the patch#1 i did't have any problem....
> More spesific the code that i use it works with C++Builder3, and
> C++Builder4 withou the path#1!!!
> How is the right connection between ClientDataSet and a Provider?
>
> I don't understand this error beacuse i think that all is ok.....
> (This problem was stop me since a week...)
> May i have a answer to this problem?
>
> Thanks. Panagiotis Staikos from Greece.
>
>
>


John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
3791FB86.923BE652@salts.navy.mil...
> I converted a medium sized 2 tier app. into a 3 tier app using BCB 4 as
> installed from the factory.  The app. server contains a number of TQuery
>
> objects, and the client app. contains representative TClientDataSet
> objects.
>
> When compiled and linked, both client and server apps. worked great
> together.  However, when I installed the patch everything went south.  I
>
> have followed the threads in the forum about this problem, and have
> completely built a new server app. which runs and does its thing with
> the MS SQL database.  I have also recompiled the client app. The DCOM
> object fires up the app server which connects to the database normally.
> But when the client attempts to trigger one of the TQuery objects ( to
> find a record in a table ), I get a "No such interface supported" error
> and everything stops.
>
> The error is being caused by the call to the QueryInterface() function
> in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is one
>
> of the files updated by the patch.
>
> I know if I uninstall BCB and reinstall it from the CD that the apps.
> will work.  I have done that once already.  But while both apps worked
> together when they were located on the same machine, I was unable to get
>
> the client to work with the app server with the server installed and
> running on one of our other servers ( an IBM NetFinity using NT Server
> as its OS ).  The client found and fired up the app server, but I was
> getting an OLE error number 80070105.  Yes, all required DLLs were
> installed and registered on the NF server, and the client's DCOM
> connection was able to connect.
>
> So I reinstalled the patch and landed square in the middle of the
> problem
> described in the first paragraphs above.
>
> Does anyone know what's going on?  I don't have any hair left to pull
> out!
>
> Regards,
> John
>
>

Martin,
Thanks for the reply.  As I stated in my original whine, I have been following
this thread.  I tried  Mark's solution and it did not work for me.  It's
possible that I didn't catch all of the references to "IProviderPtr", but I
went through all of the generated source code a couple of times.

Mark's procedure is not an answer nor is it a solution; rather it is a
workaround - not the kind of necessity one expects when one spends a
considerable amount of money for a development platform, and certainly not what
I expect based on my experience with BCB.  I have been using this platform
since its inception. I do not expect a commercial package to be bug free,
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.

The facts are these: everything works as documented with the original install;
things don't work when the patch is installed.

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.

What I would like to see is a response from Team B or Borland acknowledging
that there is a problem and that they're working on it, or some kind of
additional documentation which will show me where I have gone astray.

These are your ( and everyone else's ) federal tax dollars that are being
wasted while I try to get this project of mine off the dime.  Despite rumor to
the contrary, there are those public mammary types among us who try to give
good value for the bucks spent.

Regards,
John

Martin Hart wrote:

> The answer was given a week or so ago. Here is the answer.
>
> Mark Johnson said:
>
> -----------------------------------------------
> I had this same problem.  The cause is the new tlb editor creates code with
> a type IProviderPtr replacing  what used to be IProvider* in the generated
> code.  If you go through all the generated source and replace IProviderPtr
> with IProvider* the remote data modules will now work.  Hope this helps.
>
> Mark Johnson
> -----------------------------------------------
>
> Panagiotis L. Staikos <pstaiko@ekt.gr> escribi� en el mensaje de noticias
> 37805D31.B7AF2946@ekt.gr...
> > I have add at server Side (Remote DataModule)
> > a TQuery Component and a TProvider(TProvider or TDataSetProvider)
> > Component.
> > I export the TProvider Component and it's DataSet property points to
> > TQuery. The TQuery component has a SQL Statement.
> > From Client Side i have a MIDAS, ClientDataset, DataSource, DBGrid
> > Components.
> > While i am connecting with my Server,when  i change the active property
> > of The ClientDataSet to true
> > (ClientDataSet Provider Property points to the Above TProvider)
> > i get the Error :
> > 'src->QueryInterface(GetIID(),(LPVOID*)(&intf))': No such interface
> > supported
> > @ C:\Program Files\Borland\CBuilder4\invlude\vcl\utilcls.h/2014
> > Press [Y]es to terminate, [N]o to continue and [C]ancel to Debug.
> >
> > All the Providers from the server are shown in the drop-down list in the
> > Provider property
> > of the ClientDataSet Component!!!
> >
> > Prior the patch#1 i did't have any problem....
> > More spesific the code that i use it works with C++Builder3, and
> > C++Builder4 withou the path#1!!!
> > How is the right connection between ClientDataSet and a Provider?
> >
> > I don't understand this error beacuse i think that all is ok.....
> > (This problem was stop me since a week...)
> > May i have a answer to this problem?
> >
> > Thanks. Panagiotis Staikos from Greece.
> >
> >
> >
>
> John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
> 3791FB86.923BE652@salts.navy.mil...
> > I converted a medium sized 2 tier app. into a 3 tier app using BCB 4 as
> > installed from the factory.  The app. server contains a number of TQuery
> >
> > objects, and the client app. contains representative TClientDataSet
> > objects.
> >
> > When compiled and linked, both client and server apps. worked great
> > together.  However, when I installed the patch everything went south.  I
> >
> > have followed the threads in the forum about this problem, and have
> > completely built a new server app. which runs and does its thing with
> > the MS SQL database.  I have also recompiled the client app. The DCOM
> > object fires up the app server which connects to the database normally.
> > But when the client attempts to trigger one of the TQuery objects ( to
> > find a record in a table ), I get a "No such interface supported" error
> > and everything stops.
> >
> > The error is being caused by the call to the QueryInterface() function
> > in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is one
> >
> > of the files updated by the patch.
> >
> > I know if I uninstall BCB and reinstall it from the CD that the apps.
> > will work.  I have done that once already.  But while both apps worked
> > together when they were located on the same machine, I was unable to get
> >
> > the client to work with the app server with the server installed and
> > running on one of our other servers ( an IBM NetFinity using NT Server
> > as its OS ).  The client found and fired up the app server, but I was
> > getting an OLE error number 80070105.  Yes, all required DLLs were
> > installed and registered on the NF server, and the client's DCOM
> > connection was able to connect.
> >
> > So I reinstalled the patch and landed square in the middle of the
> > problem
> > described in the first paragraphs above.
> >
> > Does anyone know what's going on?  I don't have any hair left to pull
> > out!
> >
> > Regards,
> > John
> >
> >

I sent in a bug report to Borland a couple of weeks ago along with the work
around.  The response I got from the person investigating the bug was "I
rebuilt empedit and it worked for me".  This would be the case if you don't
force the tlb editor to regenerate  the code.  This should have been
obvious.  I don't think this guy spent two minutes trying to solve the
problem.  And of course the resubmitted bug report goes to the end of the
queue.

John Graham <jgraham@salts.navy.mil> wrote in message
news:3796F0CB.48790F91@salts.navy.mil...
> 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.

I aggree.  I expected better from Borland.

I fully agree with you. Quality means so much in software and to have a
patch 'wrong-the-right' is not what I expected form such and expensive
package.

Please Borland, show some signs of life on this one :-))

Regards,
Martin.

John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
3796F0CB.48790F91@salts.navy.mil...
> Martin,
> Thanks for the reply.  As I stated in my original whine, I have been
following
> this thread.  I tried  Mark's solution and it did not work for me.  It's
> possible that I didn't catch all of the references to "IProviderPtr", but
I
> went through all of the generated source code a couple of times.
>
> Mark's procedure is not an answer nor is it a solution; rather it is a
> workaround - not the kind of necessity one expects when one spends a
> considerable amount of money for a development platform, and certainly not
what
> I expect based on my experience with BCB.  I have been using this platform
> since its inception. I do not expect a commercial package to be bug free,
> 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.
>
> The facts are these: everything works as documented with the original
install;
> things don't work when the patch is installed.
>
> 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.
>
> What I would like to see is a response from Team B or Borland
acknowledging
> that there is a problem and that they're working on it, or some kind of
> additional documentation which will show me where I have gone astray.
>
> These are your ( and everyone else's ) federal tax dollars that are being
> wasted while I try to get this project of mine off the dime.  Despite
rumor to
> the contrary, there are those public mammary types among us who try to
give
> good value for the bucks spent.
>
> Regards,
> John
>
> Martin Hart wrote:
>
> > The answer was given a week or so ago. Here is the answer.
> >
> > Mark Johnson said:
> >
> > -----------------------------------------------
> > I had this same problem.  The cause is the new tlb editor creates code
with
> > a type IProviderPtr replacing  what used to be IProvider* in the
generated
> > code.  If you go through all the generated source and replace
IProviderPtr
> > with IProvider* the remote data modules will now work.  Hope this helps.
> >
> > Mark Johnson
> > -----------------------------------------------
> >
> > Panagiotis L. Staikos <pstaiko@ekt.gr> escribi� en el mensaje de
noticias
> > 37805D31.B7AF2946@ekt.gr...
> > > I have add at server Side (Remote DataModule)
> > > a TQuery Component and a TProvider(TProvider or TDataSetProvider)
> > > Component.
> > > I export the TProvider Component and it's DataSet property points to
> > > TQuery. The TQuery component has a SQL Statement.
> > > From Client Side i have a MIDAS, ClientDataset, DataSource, DBGrid
> > > Components.
> > > While i am connecting with my Server,when  i change the active
property
> > > of The ClientDataSet to true
> > > (ClientDataSet Provider Property points to the Above TProvider)
> > > i get the Error :
> > > 'src->QueryInterface(GetIID(),(LPVOID*)(&intf))': No such interface
> > > supported
> > > @ C:\Program Files\Borland\CBuilder4\invlude\vcl\utilcls.h/2014
> > > Press [Y]es to terminate, [N]o to continue and [C]ancel to Debug.
> > >
> > > All the Providers from the server are shown in the drop-down list in
the
> > > Provider property
> > > of the ClientDataSet Component!!!
> > >
> > > Prior the patch#1 i did't have any problem....
> > > More spesific the code that i use it works with C++Builder3, and
> > > C++Builder4 withou the path#1!!!
> > > How is the right connection between ClientDataSet and a Provider?
> > >
> > > I don't understand this error beacuse i think that all is ok.....
> > > (This problem was stop me since a week...)
> > > May i have a answer to this problem?
> > >
> > > Thanks. Panagiotis Staikos from Greece.
> > >
> > >
> > >
> >
> > John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
> > 3791FB86.923BE652@salts.navy.mil...
> > > I converted a medium sized 2 tier app. into a 3 tier app using BCB 4
as
> > > installed from the factory.  The app. server contains a number of
TQuery
> > >
> > > objects, and the client app. contains representative TClientDataSet
> > > objects.
> > >
> > > When compiled and linked, both client and server apps. worked great
> > > together.  However, when I installed the patch everything went south.
I
> > >
> > > have followed the threads in the forum about this problem, and have
> > > completely built a new server app. which runs and does its thing with
> > > the MS SQL database.  I have also recompiled the client app. The DCOM
> > > object fires up the app server which connects to the database
normally.
> > > But when the client attempts to trigger one of the TQuery objects ( to
> > > find a record in a table ), I get a "No such interface supported"
error
> > > and everything stops.
> > >
> > > The error is being caused by the call to the QueryInterface() function
> > > in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is
one
> > >
> > > of the files updated by the patch.
> > >
> > > I know if I uninstall BCB and reinstall it from the CD that the apps.
> > > will work.  I have done that once already.  But while both apps worked
> > > together when they were located on the same machine, I was unable to
get
> > >
> > > the client to work with the app server with the server installed and
> > > running on one of our other servers ( an IBM NetFinity using NT Server
> > > as its OS ).  The client found and fired up the app server, but I was
> > > getting an OLE error number 80070105.  Yes, all required DLLs were
> > > installed and registered on the NF server, and the client's DCOM
> > > connection was able to connect.
> > >
> > > So I reinstalled the patch and landed square in the middle of the
> > > problem
> > > described in the first paragraphs above.
> > >
> > > Does anyone know what's going on?  I don't have any hair left to pull
> > > out!
> > >
> > > Regards,
> > > John
> > >
> > >
>

Thanks to you both for the replies.  Mark, I guess you ran into a level one
service "engineer" who may be operating with a "Don't confuse me with the facts,
my mind is made up" philosophy.  A variation of this is the "It runs ok on my
machine" philosophy.

Frankly I'm tired of dealing with so called customer service types who react as
if I'm an idiot.  I may be ignorant in certain areas, but I'm not stupid, and I
don't make phone calls for the sake of having someone to talk to.  Ah well.

I did the same thing the "engineer" did and found that when I rebuilt the app.
server that it bombed when the client tried to connect.  Ipso facto or some
other Latin phrase - there IS a problem.

Meanwhile, I uninstalled the patched version and reinstalled from the CD.  My
application now runs as advertised - at least with the app. server running in
local memory.  I haven't tested it on one of our NT Servers yet; I need some
success in my life to prepare me for the next failure.

Pip, Pip,
John


Martin Hart wrote:

> I fully agree with you. Quality means so much in software and to have a
> patch 'wrong-the-right' is not what I expected form such and expensive
> package.
>
> Please Borland, show some signs of life on this one :-))
>
> Regards,
> Martin.
>
> John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
> 3796F0CB.48790F91@salts.navy.mil...
> > Martin,
> > Thanks for the reply.  As I stated in my original whine, I have been
> following
> > this thread.  I tried  Mark's solution and it did not work for me.  It's
> > possible that I didn't catch all of the references to "IProviderPtr", but
> I
> > went through all of the generated source code a couple of times.
> >
> > Mark's procedure is not an answer nor is it a solution; rather it is a
> > workaround - not the kind of necessity one expects when one spends a
> > considerable amount of money for a development platform, and certainly not
> what
> > I expect based on my experience with BCB.  I have been using this platform
> > since its inception. I do not expect a commercial package to be bug free,
> > 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.
> >
> > The facts are these: everything works as documented with the original
> install;
> > things don't work when the patch is installed.
> >
> > 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.
> >
> > What I would like to see is a response from Team B or Borland
> acknowledging
> > that there is a problem and that they're working on it, or some kind of
> > additional documentation which will show me where I have gone astray.
> >
> > These are your ( and everyone else's ) federal tax dollars that are being
> > wasted while I try to get this project of mine off the dime.  Despite
> rumor to
> > the contrary, there are those public mammary types among us who try to
> give
> > good value for the bucks spent.
> >
> > Regards,
> > John
> >
> > Martin Hart wrote:
> >
> > > The answer was given a week or so ago. Here is the answer.
> > >
> > > Mark Johnson said:
> > >
> > > -----------------------------------------------
> > > I had this same problem.  The cause is the new tlb editor creates code
> with
> > > a type IProviderPtr replacing  what used to be IProvider* in the
> generated
> > > code.  If you go through all the generated source and replace
> IProviderPtr
> > > with IProvider* the remote data modules will now work.  Hope this helps.
> > >
> > > Mark Johnson
> > > -----------------------------------------------
> > >
> > > Panagiotis L. Staikos <pstaiko@ekt.gr> escribi� en el mensaje de
> noticias
> > > 37805D31.B7AF2946@ekt.gr...
> > > > I have add at server Side (Remote DataModule)
> > > > a TQuery Component and a TProvider(TProvider or TDataSetProvider)
> > > > Component.
> > > > I export the TProvider Component and it's DataSet property points to
> > > > TQuery. The TQuery component has a SQL Statement.
> > > > From Client Side i have a MIDAS, ClientDataset, DataSource, DBGrid
> > > > Components.
> > > > While i am connecting with my Server,when  i change the active
> property
> > > > of The ClientDataSet to true
> > > > (ClientDataSet Provider Property points to the Above TProvider)
> > > > i get the Error :
> > > > 'src->QueryInterface(GetIID(),(LPVOID*)(&intf))': No such interface
> > > > supported
> > > > @ C:\Program Files\Borland\CBuilder4\invlude\vcl\utilcls.h/2014
> > > > Press [Y]es to terminate, [N]o to continue and [C]ancel to Debug.
> > > >
> > > > All the Providers from the server are shown in the drop-down list in
> the
> > > > Provider property
> > > > of the ClientDataSet Component!!!
> > > >
> > > > Prior the patch#1 i did't have any problem....
> > > > More spesific the code that i use it works with C++Builder3, and
> > > > C++Builder4 withou the path#1!!!
> > > > How is the right connection between ClientDataSet and a Provider?
> > > >
> > > > I don't understand this error beacuse i think that all is ok.....
> > > > (This problem was stop me since a week...)
> > > > May i have a answer to this problem?
> > > >
> > > > Thanks. Panagiotis Staikos from Greece.
> > > >
> > > >
> > > >
> > >
> > > John Graham <jgraham@salts.navy.mil> escribi� en el mensaje de noticias
> > > 3791FB86.923BE652@salts.navy.mil...
> > > > I converted a medium sized 2 tier app. into a 3 tier app using BCB 4
> as
> > > > installed from the factory.  The app. server contains a number of
> TQuery
> > > >
> > > > objects, and the client app. contains representative TClientDataSet
> > > > objects.
> > > >
> > > > When compiled and linked, both client and server apps. worked great
> > > > together.  However, when I installed the patch everything went south.
> I
> > > >
> > > > have followed the threads in the forum about this problem, and have
> > > > completely built a new server app. which runs and does its thing with
> > > > the MS SQL database.  I have also recompiled the client app. The DCOM
> > > > object fires up the app server which connects to the database
> normally.
> > > > But when the client attempts to trigger one of the TQuery objects ( to
> > > > find a record in a table ), I get a "No such interface supported"
> error
> > > > and everything stops.
> > > >
> > > > The error is being caused by the call to the QueryInterface() function
> > > > in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is
> one
> > > >
> > > > of the files updated by the patch.
> > > >
> > > > I know if I uninstall BCB and reinstall it from the CD that the apps.
> > > > will work.  I have done that once already.  But while both apps worked
> > > > together when they were located on the same machine, I was unable to
> get
> > > >
> > > > the client to work with the app server with the server installed and
> > > > running on one of our other servers ( an IBM NetFinity using NT Server
> > > > as its OS ).  The client found and fired up the app server, but I was
> > > > getting an OLE error number 80070105.  Yes, all required DLLs were
> > > > installed and registered on the NF server, and the client's DCOM
> > > > connection was able to connect.
> > > >
> > > > So I reinstalled the patch and landed square in the middle of the
> > > > problem
> > > > described in the first paragraphs above.
> > > >
> > > > Does anyone know what's going on?  I don't have any hair left to pull
> > > > out!
> > > >
> > > > Regards,
> > > > John
> > > >
> > > >
> >

I'm sorry I didn't recognize your problem sooner.  I've run into the
same thing, and someone from Borland determined the following
workaround.  Every exported provider X generates a function get_X, which
in its body has the line:

  *Value = IProv;

which needs to be changed to:

  *Value = (IProvider *)IProv;

Also, make sure in any existing project to change IProvider** to
IProviderPtr*.  I share your frustration that both these bugs were
introduced.

Steven Pietrykoski


John Graham wrote:
> 
> The error is being caused by the call to the QueryInterface() function
> in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is one
> 
> Does anyone know what's going on?  I don't have any hair left to pull
> out!

Steven,

Thanks.  Your response completes the workaround procedure.  I missed the
requirement to change *Value = IProv; I'll try that on the good old EmpEdit
example and see what happens.

However, I'm most interested to know whether Borland has officially
acknowledged that they have introduced these bugs in the patch and if they are
going to do something about it and when.

Steve Pietrykoski wrote:

> I'm sorry I didn't recognize your problem sooner.  I've run into the
> same thing, and someone from Borland determined the following
> workaround.  Every exported provider X generates a function get_X, which
> in its body has the line:
>
>   *Value = IProv;
>
> which needs to be changed to:
>
>   *Value = (IProvider *)IProv;
>
> Also, make sure in any existing project to change IProvider** to
> IProviderPtr*.  I share your frustration that both these bugs were
> introduced.
>
> Steven Pietrykoski
>
> John Graham wrote:
> >
> > The error is being caused by the call to the QueryInterface() function
> > in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is one
> >
> > Does anyone know what's going on?  I don't have any hair left to pull
> > out!

Thanks John,

I had the same problem after applying the patch, adding the (IProvider*)
solved all errors.

--

-----------------------------------------------------------------
PIQUOT J�r�me
A. WOLFF SA
6, rue de la Gare
67120 ERNOLSHEIM/BRUCHE
FRANCE
e-mail: wolff@media-net.fr
http://www.media-net.fr/wolff
-----------------------------------------------------------------
John Graham <jgraham@salts.navy.mil> a �crit dans le message :
379ADA40.92B73FC0@salts.navy.mil...
> Steven,
>
> Thanks.  Your response completes the workaround procedure.  I missed the
> requirement to change *Value = IProv; I'll try that on the good old
EmpEdit
> example and see what happens.
>
> However, I'm most interested to know whether Borland has officially
> acknowledged that they have introduced these bugs in the patch and if they
are
> going to do something about it and when.
>
> Steve Pietrykoski wrote:
>
> > I'm sorry I didn't recognize your problem sooner.  I've run into the
> > same thing, and someone from Borland determined the following
> > workaround.  Every exported provider X generates a function get_X, which
> > in its body has the line:
> >
> >   *Value = IProv;
> >
> > which needs to be changed to:
> >
> >   *Value = (IProvider *)IProv;
> >
> > Also, make sure in any existing project to change IProvider** to
> > IProviderPtr*.  I share your frustration that both these bugs were
> > introduced.
> >
> > Steven Pietrykoski
> >
> > John Graham wrote:
> > >
> > > The error is being caused by the call to the QueryInterface() function
> > > in line 2014 of the UTILCLS.H header file ( \include\vcl ), which is
one
> > >
> > > Does anyone know what's going on?  I don't have any hair left to pull
> > > out!
>

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.

In article <37988C8E.7A9C673A@artisansoftware.com>,
Steve Pietrykoski  <steve@artisansoftware.com> wrote:
>I'm sorry I didn't recognize your problem sooner.  I've run into the
>same thing, and someone from Borland determined the following
>workaround.  Every exported provider X generates a function get_X, which
>in its body has the line:
>
>  *Value = IProv;
>
>which needs to be changed to:
>
>  *Value = (IProvider *)IProv;
>
>Also, make sure in any existing project to change IProvider** to
>IProviderPtr*.  I share your frustration that both these bugs were
>introduced.

Ah! I remember this workaround now. :)

I should probably put this in Code Central, shouldn't I? :)

-- 
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.

> 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.

Robert, 

As you've seen in my other post in this thread, there is another bug
that you've given me a workaround for.  But that bug affects *every*
project, new or otherwise, does it not, and is therefore a bit more
serious?

Steve Pietrykoski

In article <379F380B.A39BBB1C@artisansoftware.com>,
Steve Pietrykoski  <steve@artisansoftware.com> wrote:
>> 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.
>
>Robert, 
>
>As you've seen in my other post in this thread, there is another bug
>that you've given me a workaround for.  But that bug affects *every*
>project, new or otherwise, does it not, and is therefore a bit more
>serious?

The problem here is that the code generator for the implementation
file generates code which must be manually edited to include a 
cast, right? I'll grant that is a bug ... but all I can do at the
moment is guarantee that the workaround gets documented.

-- 
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.

Robert,

I am gratified to see you are acknowledging that a problem exists with
the patch, and that the workaround will be documented.  However, what
would send me over the top into spasms of ecstasy would be some kind of
statement from you or your organization that a patch for the patch, or a
revision of the original patch is forthcoming and when we can reasonably
expect it.

Workarounds are, at best, temporary measures and frankly I don't have the
time to modify code produced by a generator - I have problems enough with
the stuff I write!

Regards,
John

aphrael@magescave.blackforest.org wrote:

> In article <379F380B.A39BBB1C@artisansoftware.com>,
> Steve Pietrykoski  <steve@artisansoftware.com> wrote:
> >> 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.
> >
> >Robert,
> >
> >As you've seen in my other post in this thread, there is another bug
> >that you've given me a workaround for.  But that bug affects *every*
> >project, new or otherwise, does it not, and is therefore a bit more
> >serious?
>
> The problem here is that the code generator for the implementation
> file generates code which must be manually edited to include a
> cast, right? I'll grant that is a bug ... but all I can do at the
> moment is guarantee that the workaround gets documented.
>
> --
> 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.

In article <37A2E5E4.8D888050@salts.navy.mil>,
John Graham  <jgraham@salts.navy.mil> wrote:
>I am gratified to see you are acknowledging that a problem exists with
>the patch, and that the workaround will be documented.  However, what
>would send me over the top into spasms of ecstasy would be some kind of
>statement from you or your organization that a patch for the patch, or a
>revision of the original patch is forthcoming and when we can reasonably
>expect it.

I can certainly understand why that would be so. Realize, however,
that i'm not in a position to promise that. I can, and have,
forward your request to the responsible parties, and document
the behavior. :)
-- 
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.