Creating Scheduler WinFOrm

You really havent given us much information with which to help you.

Do you know how to draw a grid? Do you know how to implement drag/drop? Do you even know how to get the cursor position?

There are many many things involved in creating an application that you have described - and not just the technology details but the application design.

I would recommend writing down a comprehensive and detailed list of EXACTLY the things the application must do. Such as (for example):
* File | Open command - accepts an file name from the user; opens the file and displays the contained calendar; if the file doesn't have the right extension, or if its contents are not in the right format, displays an error to the user.
...
* User drags one end of an appointment - system changes the start / end date or time as needed (start, or end, date/time depending on which end was dragged). If the start is dragged past the end, or vice versa, the intuitive thing happens (i.e. the old end becomes the new start, etc.)
* User drags from the body of an appointment - system changes the start AND end date / time, keeping the duration constant.
...
* Displayed date range - a set of radio buttons is presented that allows the user to select whether the calendar displays a single day, a week, a month, a whole year, or a list of upcoming appointments.
...

Once you have written down all the behaviours your application must exhibit, you can start addressing the technical problems one-by-one.

Having a written set of requirements often reduces the level of uncertainty and makes it easier to get started. Also - if you're really not clear what the app is supposed to be able to do, you're not going to be able to finish it, are you?

It may help to organise your thoughts by grouping the requirements. There are no hard-and-fast groupings; for the app you want to write I would suggest things like: persistence; personalisation (user preferences); appointments (the set of all information that defines an appointment - required information - or can be associated with one - optional information); interaction with other peoples' calendars; user-interface interaction modes; etc.

In the case of not being sure of everything your application should do, perhaps building a prototype - that models a certain part of user interaction but doesn't persist any values - would be useful.

Also - take a leaf out of the Agile methodology play-book: iterate. Build a part, a subset of the functionality, and get it to the point that it is useful. Then, extend by adding another chunk of usable behaviour. Remember to keep each chunk small (1-4 week's work).