I think each CellFormat must have a solid FillPatternStyle, which would cause all of its foreground pixels (i.e., black pixels) to be turned "on" and so they cover-up whatever background fill color is being used.

Try something like the following code to see if it works for you this way,

IWorksheetCellFormat cf = pipelineWorksheet.GetCell("A" + rowIndex).CellFormat;
cf.FillPatternBackgroundColor = System.Drawing.Color.Cornsilk;
cf.FillPatternStyle = FillPatternStyle.None;

Regards,

[quote user="vasanth_krt"]

<configuration>
     <configsections>
:     :
:     :
And am getting,
" Unrecognized configuration section configsections. "
as the error message….

[/quote]

Change "configsections" to "configSections" with a capital S (do this to both the start tag and the end tag near the end of the file.)  XML is case-sensitive.

[quote user=”BOGHRD”]are they modifying the entered dates using the server(s) offset – or the clients?  My best guess is the server.  How do these functions work with dispersed server farms?[/quote]

WebScheduleInfo has a property on it that lets you set the TimeZoneOffset to use for this end user.  Different end users talking to the same server may have different TZOs that tell WebScheduleInfo what TimeSpan to use when translating to / from UTC so that the server always sees UTC and the end user always sees their local time.

What you set the TZO to for a particular end user is usually tied to that user somehow (preference, field on that user's account, etc.)  As with authenticating users, handling these preferences is something that's left up to the application. There is a WebSchedule sample demonstrating these functions and the effects of international scheduling and international dateline crossovers, that lets the user pick their time zone from a dropdown list of all of the world's timezones.

TimeZoneOffset persists between the user and whichever Web server in a server farm they are talking to for that particular request, so it shouldn't be affected at all by the user's session being handed-off to another server in a different geography because the user's preferred time zone is still part of that session.  As long as you are setting the TimeZoneOffset property correctly for the end user's time zone, the WebScheduleInfo control created on the new server will know how to translate between UTC and local time.

[quote user=”BOGHRD”][/quote]how does the Infragistics Scheduler save local time to UTC time, and display UTC time to local time?  Is it a bit of a trade secret?

The date/times are always stored in UTC, this is important because the persistence format and the format that the date/times are passed around in needs to be completely objective and unambiguous.  The ServerTimeZoneOffset property I alluded to will always shift these date/times for display purposes to the end user's local time.  The end user edits the values in his/her preferred local time zone, and those changes return to the server where the ServerTimeZoneOffset value shifts back these date/times to UTC for storage.  Inside the DB everything is always UTC, and when shown to the end user everything is always converted to that user's local time.

[quote user=”BOGHRD”]I think I might be forced to attain the time offset using JavaScript, save the offset to a hidden field, and generate the date/time in SQL using the DATEADD SQL function?[/quote]

If your WebGrid column may be displaying StartDateTimes for the appointments of different users, and you want to display those times in the local time zone of the user who made them, then there is some truth to the approach you describe.  You may need the time zone information along with each StartDateTime that appears in local time for display purposes though, to differentiate 1200 Eastern Standard Time from 1200 Central Europe Time for your WebGrid's users.

[quote user=”BOGHRD”][/quote]

Regardless, the webscheduler saves the start dates as a UTC date.  I think I can handle the offset for generating the SQL to filter the data used in the browse, but how can I display the local date version of the UTC date in a grid column?

Do you know what the end user's local time zone is?  If you know their time zone is US Eastern Standard Time for example (whether from an authenticated user's preferences, or just because it's an intranet application for an organization with a single office located squarely in the eastern US and no access by anybody in another timezone is possible) then you could create a TimeSpan for -5 hours (which is the offset from the Greenwich Meridian running through London — GMT or Greenwich Mean Time and UTC will be identical when there is no Daylight Savings Time in effect as there is currently, but the offset should be adjusted by +1 for DST if and when it affects your geography) and add that to the DateTime displayed in each cell.

You would have to loop over the Rows collection(s), pluck out the Cell from that Row's Cells collection for the Column you wish to display local date/times in, perhaps parse the formatted string text value into a DateTime, add this TimeSpan to the DateTime, then assign the DateTime as a formatted string text value back into the Cell.

Note that if you want to allow the end user to edit the StartDateTime column, then you will need to perform the reverse translation from local time into UTC time (subtract the TimeSpan for the offset, so it would be +5 hours for EST) in an event like UpdateCell before the changes get commited to the Activities table in your database.  The WebSchedule data model stores everything in UTC because if it were stored as local time, two users viewing an appointment from different time zones would believe the appointment started at different times.