My little C# project is coming along just fine. The basic idea is to create a synchronisation tool between an ERP application and Outlook, since the manufacturer of the ERP application has no plans on creating a “synchronize with Outlook” functionality in the near (and not so near) future. Since I don’t want to get into any legal stuff, I wanted to create a one-way sync-mechanism, basically a download-from-ERP-to-Outlook. And since I was in need for some project to learn C# better, this was the opportunity.
Since the ERP application has an ODBC DSN defined on the client to create a connection from MS Word to their data, I decided to use that to connect to the database. ODBC is not the fastest and most elegant thing around, but it’ll do the job just fine.
The main form is just a simple form with a textbox for the employerscode and two datefields, to specify the period that needs to be downloaded to Outlook. The functionality sofar:
– Employee-code is checked against the database
– Timespan is 7 days by default: changing the from-date, the to-date will be 7 days later
– Pressing sync will get all appointments in the daterange, and search for all attendees (other than the employee) of the appointment
What needs to be done to enter the Alpha-stage:
– Convert the found data to an Outlook.AppointmentItem and insert it into Outlook
– Have seperate time-fields (by default 00:00:00 and 23:59:59) to be able to enter a narrow timespan, without the user having to specify the time in each of the date-fields
Things I learned from working with C# (VS.NET 2003) are:
– Case sensitivity. Needs to get used to, and can be very annoying. Odbc is something else than odbc. When the compileroutput lists the error, is sometimes hard to spot what is wrong.
– Functions need not be declared before (above in the sourcecode) you use them. This is different from (object)pascal. But it’s nice: you can keep things together, without the need for a specific order. Alphabetically will do just fine.
– I’m not sure if it can be done in (object)pascal (never tried it), but variables declared within curly brackets have a scope only between these brackets. Very nice for dummy-variables, and you don’t want to make up another name, just because you’re still in the same function/procedure. If it’s a meaningless variable, using the same name is just fine.
– Compiler directives are nice. Having the ability to switch between debug and release with one buttonclick, makes it very usable to include lots of debugmessages, that just won’t show up when you build/run the release-version. No more forgetting about that one ShowMessage when releasing your work to the client.
Hi Till,
I use C# (obviously) and the way to “connect” to Outlook is to use the Interop-assemblies (installed with Office 2003 or as seperate download for Office XP). The way the interop works, are very simalar to the “old” OLE way. Remember CreateOleObject(“Outlook.Application”) ? If you know how to do that, downloading your appointments from Teamware to Outlook should not give you any problems.
Have a look here for more information.
hi there,
what u just described is pretty similar to the little tool i want to build: we use a strange not-market-standard groupware in our office (teamware). since i would rather use outlook (integrated with my palm & mob phone, works offline etc.) i’d like to write a little sync tool.
here’s y main question: who do u connect to outllok? do u connect directly to the pst file? ado? or do u connect to outlook as an app?
thx for the valuable information u gave already so far!
hi from prague,
— till.
Hi,
Have you ever tried retrieving the email address(es) of attendees from an appointment item?
I have been working on a similar synching mechanism but need to be able to extract a list of appointments from a users Calandar(this is no problem) and then retrieve the email addresses of all the Attendees which is where I am having trouble. I can get the Display Name but haven’t found a way to retrieve the actual email addresses.
Any experiences would be appreciated?
Regards,
D