Detailed Question:

This is a cumulative assignment where first we had to write library in C which reads calendar files and interpret the data.

Now we have to write GUI in python and implement already written C function in previous assignment into the python. I have attached first two

Assignment as well to explain what you have to do. The first two assignments were marked through auto grader.

I also want you to fix my A2 first with provided auto grader then implement A3 which is required for A3 since its built on A1 and A2.When an application wants to read an ICS file, it will open the file in the normal C way, resulting in a FILE* variable. At this point, your utility functions will take over and digest the file's contents. Once the file has been read in, the application should close it in the normal C way; your utilities won't close the file, since they didn't open it.

CAUTION: In the next assignment, the input file will be connected to the standard input stream (stdin). stdin works just like a text file for most purposes, so it should be transparent to your program whether it is a "real" disk file or not. However, stdin cannot be repositioned using fseek or rewind , so avoid developing any algorithms that rely on repositioning the input stream. They would work for this assignment, but you'll run into trouble on the next one and be forced to recode.

You must code and submit two source files with these exact names (case sensitive) and proper file headers:

calutil.h: the public interface to your utility package.
calutil.c: the private implementation of the utility functions
Applications will #include "calutil.h" in their main program. For your own test purposes, you will also want to code a main program in another .c file that calls your functions with a variety of test cases, but you won't submit that program. Do not put your main() function in calutil.c, or else the official test program will fail due to multiple definitions of main(); you will lose marks for that.

A basic calutil.h has been provided for you. You must customize the file header with your student name and number. You may add to it if necessary, but you must not change the given typdefs or function prototypes, or else your utilities will not compile with the official test program. Be careful about upper/lower case! In classic (confusing) C style, output pointer arguments seem to have extra stars, but these become "&" (address of) in actual use. The const keyword has been inserted both for documentation purposes and to help you avoid trying to assign variables that are read-only.

You are free to create additional "helper functions" in calutil.c, each with its proper function header, if you find some recurring processing steps that you would like to factor out into a single place. Do not put helper function prototypes in calutil.h, since they are internal to your implementation and not for public users of the utility package.

Your functions are supposed to be robust. They will be tested with various kinds of invalid data and must detect problems without crashing. However, be sure to follow the specifications re error returns. Functions designed for use as utilities must not print out their own error messages! You will be penalized if your calutil.c does this. Error or status messages should be printed by a higher-level module, not low-level utility modules. This is because utilities generally have no way to know how the calling application wants to handle errors, or how it plans to use the stdout and stderr streams.

HINT: You may find it helpful to implement and test the file I/O functions in a top-down fashion. That is, code readCalFile first, and also write stubs for the subfunctions it calls. readCalFile can then be used to drive test data into your other functions as you begin to code them. Bottom-up implementation is also a valid approach.

HINT: In order to tell whether readCalFile (and subfunctions) are working right, it will be extremely helpful to write a private utility like "printCalFile" that mechanically goes through the data structure and prints everything out compactly. This also has the benefit of testing out the navigation of all the pointers and array sizes, so they won't blow up unexpectedly later. Put that utility in your own test program .c file, not in calutil.h/c.

Each prototype is given with pre- and postcondtions. The preconditions should be assumed true by the function and not verified, unless the description calls for testing and provides for error-handling. If a caller violates an unverified precondition, the resulting behaviour is the calling function's fault.

NOTE: If for your own peace of mind during development you wish to verify preconditions beyond those required by the spec, use assert() for this purpose. Conversely, do not use assertions to check for errors that are required by the spec. The official test program will be compiled with assertions disabled, so that they do not interfere with the autotester's smooth operation.

Since ICS files are ASCII, you can open the sample files in a text editor and "damage" them, to try out your error detection code. Don't limit your testing to just whatever files have been supplied!

Attachment:- uploading.zip