13 Answers, 1 is accepted
Currently, there is no way to change the rule, with the exception of modifying the source code of the control, of course. Currently, we are extracting the number of the week the following way:
CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(date, CalendarWeekRule.FirstFourDayWeek, CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek)
Regards,
Tsvetie
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>
Thanks for the reply but I have decided against using the timebar for what I want to do at this point. But going forward it would be nicer if you could set the calendar week rule and the first day of the week, like on the scheduler component, via properties without us having to change the control's source code as I think that would get a bit sticky for us.
Cheers,
Simeon
I'd like to know if there is any upgrade to Timebar? I'm looking for an approach to set the first day of week for the Timebar, to make a week from Saturday to Friday.
Thanks,
Jin
In short, no, the feature is not available yet. We will consider adding support for changing the first day of the week for Q2 2013.
Greetings,Tsvetie
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
Is there any news about this topic? Has this been corrected in any of the latest versions of controls?
Best regards,
Beata.
You can use a custom interval to get this behavior. Check out our online documentation and sdk sample (you may want to use the sdk samples browser).
Regards,
Petar Marchev
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
To save someone some time...
class
CustomWeekInterval : IntervalBase
{
private
static
readonly
Func<DateTime,
string
>[] formatters;
static
Func<DateTime,
int
> WeekOfYear = date => {
return
CultureInfo.CurrentCulture.Calendar.GetWeekOfYear(date, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday); };
static
CustomWeekInterval()
{
formatters =
new
Func<DateTime,
string
>[]
{
date =>
string
.Format(
"Week {1}, {0}"
, date.ToString(
"yyyy"
), WeekOfYear(date)),
date =>
string
.Format(
"Week {0}"
, WeekOfYear(date)),
date =>
string
.Format(
"Wk {0}"
, WeekOfYear(date)),
date =>
string
.Format(
"W {0}"
, WeekOfYear(date))
};
}
public
override
Func<DateTime,
string
>[] Formatters => formatters;
public
override
TimeSpan MinimumPeriodLength => TimeSpan.FromDays(7);
public
override
DateTime ExtractIntervalStart(DateTime date)
{
// Telerik.Windows.Controls.ScheduleView.CalendarHelper
var first = CalendarHelper.GetFirstDayOfWeek(date, DayOfWeek.Monday).TruncateToDayStart();
return
new
DateTime(first.Year, first.Month, first.Day);
}
public
override
DateTime IncrementByInterval(DateTime date,
int
intervalSpan)
{
return
date.AddDays(intervalSpan * 7);
}
}
Hi Brian,
I wanted to take a moment to reply here to let you know there will be a small delay in getting an answer form Petar. Today is a public holiday for our European office in Sofia, which is where Petar is located.
I have locked this thread open for him to reply when he gets back into the office tomorrow. Thank you for your patience and understanding!
I the meantime, I can make comment about the error. If the XAML designer is complaining about something that only happens when there is a different .NET version used, then the Visual Studio toolbox is using the wrong .NET version. You can usually fix this by running the Visual Studio Toolbox configurator, then do a Clean and Rebuild.
Regards,
Lance | Team Lead - US DevTools Support
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.
I think I'm starting to understand some of the issues that I have be seeing in the designer. I have a solution with 10 projects, basically building a suite of applications for our internal teams. As I've added to the solution the versions of Telerik libraries have been also changing over time.
At some point, using the upgrade wizard, I ended up having references mixed in the different projects. For instance...
<
HintPath
>..\lib\RCWPF\2020.1.218.45\Telerik.Windows.Controls.dll</
HintPath
>
and
<
HintPath
>..\..\..\..\Program Files (x86)\Progress\Telerik UI for WPF R1 2020\Binaries\WPF45\Telerik.Windows.Controls.dll</
HintPath
>
I'm going to go out on a limb here and assume that the RCWPF is because the "Offer Beta Versions if Available" option is set in the Progress Control Panel.
I change all of my projects to point to the same references and things in the designer operated as expected. I just need to keep a closer eye on the reference paths being set in the projects.
Thanks
Hello Brian,
Bingo. The nested /lib/ folder was created either by the Upgrade Wizard or the project template. Let me explain the difference between them, why they were created and how you can turn off the auto-creation.
With that info, you can then make a choice on which one you want to stay with. First, let's visit the options panel that enables/disables this:
Open the Telerik VSExtensions Options panel (here's a screenshot from VS2019)
On the General tab, you'll see a "Copy referenced assemblies to solution" checkbox
That's is what the project wizard and upgrade uses to decide on one of the following options:
- If it is checked, it will create/update a nested project-root/lib/product-acronym folder.
- If unchecked, the references will always have a standard path, the installation folder (C:/Program Files (x86)/Progress/product)
"RCWPF" means RadControls for WPF". There is a different acronym for each product and you can have multiple products in that folder (e.g. if the solution also has WinForms and ASP.NET projects).
The reason why you might want to stay with a /lib/ folder is if you need to keep the assemblies checked in with source code. Alternatively, unchecking it means you'll always have a stable location, regardless of which project is open.
> There are licensing situations to consider. Checking in the assemblies means that you're redistributing it to all the other devs, if those devs are unlicensed (and are using the Telerik API directly), would be a license policy violation.
Ultimately, this choice comes down to what makes the most sense for that solution and the project.
NuGet - Alternate Option
You could instead switch to using the NuGet packages instead of assembly references. We have a full tutorial and video here - Using NuGet to install UI for Silverlight.
This tends to be the most seamless option for source control, because no matter where the project is being built (your machine, other dev machines and CI/CD (i.e. Azure DevOps), the NuGet restore command will get the assemblies from the Telerik server directly.
You don't need to check in assemblies alongside source code and you don't need to have that version of UI for WPF install everyone's machines.
I have a blog post on using Telerik NuGet server in Azure DevOps. Although you're not having a problem in DevOps, the first option I share a nuget.config file that you can use for that solution.
Wrapping Up
If you have no further questions for us regarding this topic, you can close the ticket by using the "Mark as resolved" button (in the email or ticket webpage). If you have any other questions, please don't hesitate to open a new ticket.
Thank you for contacting support and choosing UI for WPF for your projects. Have a great day and stay safe!
Regards,
Lance | Team Lead - US DevTools Support
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.