Too Protected

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Twice now I have run into issues with the MAPI dataprovider because there are so man private functions and variables. Since private members are unavailable to a derived class, it is nearly impossible to enhance.

First, I needed to have more control over the open functionality. I was already opening a connection to MAPI elsewhere and It was no good to open an extra connection, ask the user, etc. I couldn't change this to use my connection without changing a number of functions and variables from private to protected.

Second, since I AM using mapi outside of the data provider, it is valuable to me to gain access to the entryid for various calendar events. Again, all of the members that are used in this process are private, they should be protected.

Could you re-evaluate the use of private members in this class? Any function that MIGHT be of use to a derived class should be protected instead.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
JohnCrenshaw Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 08 September 2006 Status: Offline Points: 65	Post Options Post Reply Quote JohnCrenshaw Report Post Thanks(0) Quote Reply Topic: Too Protected Posted: 13 March 2007 at 10:16am
	Twice now I have run into issues with the MAPI dataprovider because there are so man private functions and variables. Since private members are unavailable to a derived class, it is nearly impossible to enhance. First, I needed to have more control over the open functionality. I was already opening a connection to MAPI elsewhere and It was no good to open an extra connection, ask the user, etc. I couldn't change this to use my connection without changing a number of functions and variables from private to protected. Second, since I AM using mapi outside of the data provider, it is valuable to me to gain access to the entryid for various calendar events. Again, all of the members that are used in this process are private, they should be protected. Could you re-evaluate the use of private members in this class? Any function that MIGHT be of use to a derived class should be protected instead.

sserge Members Profile Send Private Message Find Members Posts Add to Buddy List Moderator Group Joined: 01 December 2004 Status: Offline Points: 1297	Post Options Post Reply Quote sserge Report Post Thanks(0) Quote Reply Posted: 24 March 2007 at 5:41pm
	Ok, moved the majority of private declarations to protected scope. If you have any suggestions to add some members to XTP MAPI sources, you are very welcome to send them to us. For some common tasks we may even add them to base classes instead of derived ones... -- WBR, Serge