Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TKCalendarMonthView highlighting incorrect date on app startup #47

Closed
atomicbird opened this issue Jan 7, 2011 · 2 comments
Closed

Comments

@atomicbird
Copy link

I'm using TKCalendarMonthView-related classes in an app. When the app starts up, December 26 is highlighted as "today", even though it's currently January 7. The result looks like this: http://dl.dropbox.com/u/14191/CalDemo.png

I put together a minimal test case that demonstrates this behavior. The demo project adds TKCalendarMonthView and related files, and then does just this:

self.calendarView = [[[TKCalendarMonthView alloc] init] autorelease];
[self.calendarView selectDate:[NSDate date]];
[self.view addSubview:self.calendarView];

None of the delegate/data source methods are implemented.

The demo can be found at http://dl.dropbox.com/u/14191/CalDemo.zip

@devinross
Copy link
Owner

I looked at the project and recopied the latest calendar month view implementation into the demo project. It fixed the problem. http://cl.ly/3zII

@atomicbird
Copy link
Author

I forgot that I had renamed a couple of variables in TKCalendarMonthView.m because of compiler warnings, and apparently one of them needs to have its original name. In -drawRect:, CGRect "r" is declared twice and LLVM reports "declaration shadows a local variable". I made a guess at fixing this but apparently guessed wrong. The declaration is at line 324 in the latest version:

CGRect r =[self rectForCellAtIndex:index];

CGRect r was previously declared just above on line 318. I had renamed the inner declaration but apparently that's what caused my problem. Changing this line by dropping CGRect seems to fix the compiler warning without causing buggy behavior.

Incidentally the same problem exists in -initWithSundayAsFirst:. The variable s is passed in as a BOOL argument but then also declared as a pointer to NSString on line 700. In this case changing the second declaration to use a different name doesn't seem to cause any problems.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants