As I stated in my previous posts, I am on a learning curve on interfaces. I have the following situation in VS 2013.
We have a shared container object, ex: FSContainer, implementing shared functionality for a number of our business objects. It contains a list for objects we add to the container and provides a “Count” property. A business object, ex. TInstitutions, inherits from the shared container.
I am know trying to access this structure from a Delphi 2007 side.
I defined an interface for the shared container FSContainer and an interface for the TInstitutions business object. The TInstitutions interface states that it inherits the IHYCrossPlatformInterface and my own defined IFSContainer interface.
Public Interface IInstitutions
Inherits IHYCrossPlatformInterface, IFS_Container
Each object implementation implements their respective functions and properties. On the VS side, testing the IInstitution interface provides me access to the inherited “Count” property from the FSContainer object.
The imported interface on the Delphi side separates out each individual interface definition and losses the inheritance. This result in IInstitutions on the Delphi side not having a Count property, on the VS side is does exist.
Is this another limitation of the interface translator or am I doing something wrong? Is there any way to maintain the inheritance?
Thanks for your prompt replies to my postings. I have two follow-up questions on my last post.
What would the correct interface look like on the Delphi side if I manually had to change the code? Would I just move the definitions from the Parent object to the Child object?
Could you elaborate some on how you are addressing any bugs you log from user input? I have run across references to Beta and Delta versions of your product, but can’t seem to find them anymore. We would be interested in participating in testing of interim releases.
(1). Cannot say right now - haven’t tested that yet on the Delphi side. However you should be able to just add the parent interface to the list of ancestor interfaces in the child interface definitions.
(2). The procedure looks as follows (this is developers POV, not a formal strict definition):
a) Showstopper bugs are fixed as soon as possible (this not necessary means ‘the same day’ or even ‘the next week’ - this is based on number of the users affected and current developers workload)
Then we provide a fixed build to the customer via personal downloads
b) Beta builds - contain bugfixes and new features. Also possibly contain bugs especialli in features being developed. Are available at https://secure.remobjects.com/portal/downloads/beta.aspx
c) Gamma build - re-release build. Contains same set of features as the release one, shouldn’t contain any serious bugs. Are available at https://secure.remobjects.com/portal/downloads/beta.aspx as well
d) Release build
Please note here that a couple of weeks before the release the codebase is stabilized. This means that code changes to this codebase are very limited and are mostly bugfixes, that are considered to be ‘safe’. F.e. importer changes needed to fix issues you reported aren’t ‘safe’ enough to be added last minutes before the release.