Test Results

About us

Total posts: 5
 Author ActiveX/Com
Bruce Michener

25.07.2007 02:20:55
Registered user
I'm not sure what went on, but I have a client ActiveX/Com DLL that contains a TrtcHttpClient, TrtcClientModule and TrtcResults.  The RTC server application (a windows service) it communicates with has TrtcHttpServer, TrtcFunctionGroup, TrtcServerModule and TrtcFunction components. When I made a small change to the server application (looking for specific text within the text string being sent to the function), the ActiveX/Comm DLL would no longer properly communicate with the server application. It seemed to try as the server counter I set up would add thousands to the count.  The non-ActiveX (i.e. stand alone DLL) client continued to work just fine. I believe I did upgrade my version of the RTC SDK before compiling the new server, but I did not recompile the ActiveX/Comm DLL client.  I have since, and the ActiveX/Com DLL now works (no code changes, just a compile). Would RTC version upgrade had any affect on the ActiveX/Com DLL or could it have just be Windows patches?

Thanks for any insight you might be able to give me.  I've tried to get the client to use the non-ActiveX/Comm DLL version (which worked fine during this change), but can't seem to get the DLL work properly in his VB program. All my applications, including both DLL versions are done in Delphi6.
Glynn Owen [RTC]

25.07.2007 02:58:39
Registered user
I"m not sure what you are asking here. Is it one problem that got resolved by recompiling, and then surfaced on some other system, or are these two distinct issues?

Danijel Tkalcec [RTC]

25.07.2007 03:04:38
Registered user
It depends on the version you were upgrading from. If you were upgrading from a very old version, check the "Updates.txt" file to see if there were some compatibility-breaking-changes. There were 2 or 3 such updates in the past 2 years, after which you would need to recompile all your Servers and Clients to keep them working together.

The question is now:
What happens if you recompile everything with the latest RTC SDK? Do all things start to work again as they did before, or are there some new problems?

Best Regards,
Danijel Tkalcec
Bruce Michener

25.07.2007 04:12:51
Registered user
I believe I went from 2.19 to 2.63.  I will look through the Updates.txt file.  After a recompile of the client, it works fine.  Why would the non-ActiveX/Com version of the DLL still work if it were compiled under the older version of the SDK?  I'm concerned that I'll have to update the client ActiveX/Com DLL every time I update the RTC SDK and recompile the Server.  From what you are telling me, I shouldn't have to do that, correct?
Danijel Tkalcec [RTC]

25.07.2007 05:19:18
Registered user
You shouldn't have to recompile all your Servers and Clients with a new RTC SDK update, unless there was a version-breaking change in the RTC SDK. And that was the case here, since versions 2.27 has introduced changes to the RTC SDK which could make clients compiled with an older RTC SDK version stop working with a Server compiled with the latest version.

Here is a description of changes made in version 2.27, which were probably the reason for your Client to stop working with a Server after it was compile with the latest RTC SDK ...

* RTC SDK 2.27 - Major update !!! Read before using !!!

1) If you need all your new clients and servers to stay compatible with
   all older RTC clients and servers, even if this means disabling some
   new features from the latest RTC SDK, you simply need to declare:

   {$DEFINE OldRtcCompatibilityMode}

   By default, this directive is NOT declared and all new features are used.

   If you still have some older clients or servers, please read the
   description of "compatibility-breaking" features (below) *before*
   deploying a new RTC Client or RTC Server to an existing network.

2) RTC SDK versions up to 2.04 are expecting all Field names received with
   remote function calls to be in UpperCase. This is not the case with newer
   RTC SDK versions, which allow working with field names using mixed case,
   without internaly converting all field names to uppercase.

   If you are still using Clients or Servers compiled with older RTC SDK
   versions, you have to define a compiler directive ...

   {$DEFINE RtcUpperCaseFieldNames}

   ... for your project, or to make it default for all projects,
   do it in the "" file sinde RTC SDK's "Lib" folder.

   This will make sure all Field Names will be converted to UpperCase
   when sent out, so that older clients and servers won't have problems
   with the client/server compiled with *this* RTC SDK version.

   This directive is NOT enabled by default.

3) RTC Clients compiled with RTC SDK versions *before* 2.27 do NOT send a
   control sum when using RTC functions with encryption, which makes it
   hard for the Server to check if the control key received from the client
   is a valid control key. Starting with RTC SDK 2.27, RTC Clients will be
   sending a control sum value along with each control key, which RTC Servers
   can use to check if the control key is valid and make sure at least the
   end of the request data was decrypted properly.

   But, since this control sum value is not being sent by RTC Clients compiled
   with RTC SDK versions older than 2.27, those clients would NOT work with
   a RTC Server compiled with the latest RTC SDK version expecting this.

   If you have RTC Clients compiled with RTC SDK 2.26 or older and can not
   port all of them before replacing the Server, you will need to declare
   a compiler directive ...

   {$DEFINE RtcDoNotCheckCryptControlSums}

   ... for your project, or to make it default for all projects,
   do it in the "" file in the RTC SDK's "Lib" folder.

   This will disable this new check on the RTC Server (compiled with the laterst
   RTC SDK version), so that your RTC Server can continue working with older clients,
   even when compiled with the latest RTC SDK version.

Best Regards,
Danijel Tkalcec