Calendar - CXTPCalendarCustomDataProvider vs raw insertions

Print Page | Close Window

CXTPCalendarCustomDataProvider vs raw insertions

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Calendar
Forum Description: Topics Related to Codejock Calendar
URL: http://forum.codejock.com/forum_posts.asp?TID=5365
Printed Date: 02 June 2024 at 6:40am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: CXTPCalendarCustomDataProvider vs raw insertions

Posted By: znakeeye
Subject: CXTPCalendarCustomDataProvider vs raw insertions
Date Posted: 26 October 2006 at 5:52pm

Hi!

I'm using the CXTPCalendarControl together with a custom SQLite database. Since I did not know how to use the CXTPCalendarCustomDataProvider interface, I simply inserted all events upon creation. This causes all events to be stored in RAM at all times.

My question is; will the CXTPCalendarCustomDataProvider interface somehow improve the performance in my application compared with my current insertion method?

Thanks.

Replies:

Posted By: sserge
Date Posted: 27 October 2006 at 3:02am

Hi,

Yes, the idea of using Custom Data Provider is not to store all events in the memory, but provide them to Calendar control by request.

See also an article: http://codejock.com/support/articles/com/calendar/cp_3.asp - http://codejock.com/support/articles/com/calendar/cp_3.asp

Let me know if you do have any more questions.

--
WBR,
Serge

Posted By: JohnCrenshaw
Date Posted: 27 October 2006 at 9:41am

I have been working on binding a database of my own to the calendar control. It is actually fairly easy and well worth it.

Here are the advantages(as I see it) to binding the data:

Improved performance, since the database is accessed on an "as needed" basis, rather than loading everything up front.

Improved data integrigty, since the datasource is notified of changes to the calendar as they happen, these changes can be sent to the database, eliminating the possibility of data loss from a crash or something.

Cleaner code, since loading things up when you start and cleaning them out later certainly requires a couple of ugly loops, something feels much cleaner about responding to a request for events for a certain day and giving them then.

Basically, binding the datasource is the "right" way and loading to memory is the "easy" way. Binding will take you a couple of days, but is very easy and well worth it. If you intend for anyone else to ever use this, bind it

Posted By: znakeeye
Date Posted: 27 October 2006 at 7:39pm

Ok, thanks for your information. I will take a closer look on the data provider class.

Posted By: sserge
Date Posted: 28 October 2006 at 10:47am

BTW. couple more notes.

CXTPCalendarCustomDataProvider is a default implementation of Custom Data Provider.
It is created if you use a connection string: 'Provider=Custom'
And its implementation fires notifications for DoXXX virtual functions calls.
This is an universal way. It is quite usefull for our ActiveX CalendarControl implementation.

But for a C++ you can also create an own class dirived from CXTPCalendarData (or CXTPCalendarCustomDataProvider) and override DoXXX virtual functions and others if needed (like Open, Close ...). In this case just use CXTPCalendarCustomDataProvider as example.

Also use CXTPCalendarControl::SetDataProvider(CXTPCalendarData* pDataProvider, BOOL bCloseDataProviderWhenDestroy) method to set data provider.

This way looks more convenient for C++.

But anyway, you can use any of them if you like it more...

--
WBR,
Serge