Dear Richard,
have you an working Source Sample ?
Regards, Norbert
Dear Richard,
have you an working Source Sample ?
Regards, Norbert
NK wrote:Dear Richard,
have you an working Source Sample ?
Regards, Norbert
can you share?
I looked at Codejock for the calender controls. It appeared to be a decent set of controls, and my communication with the techs was pleasant. However, they are unfamiliar with xBase languages, ie. xHarbour, and there was an issue of a clean interface to .dbf files.
We have several threads on this forum regarding Codejock and no one seemed to have worked through using the product in an application.
We'll be interested in seeing what you share on the subject.
Tim,
How do they handle the data--as a recordset? We should be able to save a recordset to a dbf without too much trouble.
James
TimStone wrote:I looked at Codejock for the calender controls. It appeared to be a decent set of controls, and my communication with the techs was pleasant. However, they are unfamiliar with xBase languages, ie. xHarbour, and there was an issue of a clean interface to .dbf files.
We have several threads on this forum regarding Codejock and no one seemed to have worked through using the product in an application.
We'll be interested in seeing what you share on the subject.
Could anybody feel more details of how to work with FWH+Codejock RibbonBar?
Do I have to use some Lib?
Which tool should use?
Is it possible I to develop my own Themes?
Regards,
Ale
James,
The interface directly to Outlook, or they handle the values in memory, or they write to SQL. The way they explained it to me was to either use one of their native data formats or capture the memory values and write them to the .dbf. That would seem normal but the correspondence indicated it is "theoretically" possible, but they had no examples of it having actually been accomplished.
I was going to work with it, but then the guys from ViaOpen indicated they were going to have their calendar controls soon so I decided to work with them. It just seemed it would be better, if possible, to use a product focused on FWH/xHarbour.
Tim
TimStone wrote:James,
The interface directly to Outlook, or they handle the values in memory, or they write to SQL. The way they explained it to me was to either use one of their native data formats or capture the memory values and write them to the .dbf. That would seem normal but the correspondence indicated it is "theoretically" possible, but they had no examples of it having actually been accomplished.
I was going to work with it, but then the guys from ViaOpen indicated they were going to have their calendar controls soon so I decided to work with them. It just seemed it would be better, if possible, to use a product focused on FWH/xHarbour.
Tim
Do I have to alter some thing in the class TActivex, to work with Codejock?
Regards
Ale SB wrote:Do I have to alter some thing in the class TActivex, to work with Codejock?
Regards
Tim,
>The interface directly to Outlook, or they handle the values in memory, or they write to SQL.
I'm still confused.
Why would anyone want to use a calander control that was linked to Outlook, since Outlook already has a calendar [that can be accessed outside the program]?
It would seem no matter how the data is stored on disk that they have to "handle the values in memory." What does this mean?
If they write the data to SQL, I would assume they use recordsets since it seems most SQL languages do use recordsets. Do they mean that they don't use recordsets?
Did they give you some kind of documentation about handling the data?
James
OK ... the native handling of the data is 1) Outlook, 2) Access, or 3) Memory ( which can write to a binary file ). I dug through the information and finally came across the following information which is about the only thing that explains the linking to data:
http://codejock.com/support/articles/co ... r/cp_3.asp
That is probably the best explanation. My guess is that we could load the calendar data from a .dbf, and save it back to a .dbf. This would then allow people to access the same data at different locations.