We have an web application in C# in where we have multiple pages with reportviewer controls, and almost all of them have date parameters.
That date parameters are rendering a datepicker (everything it's fine till this point, no exceptions, no problems) but all the datepickers starts on Sunday ("domingo" in spanish, "do" abbreviated) and our client complains about it; he wants it to start on monday ("lunes" in spanish, "lu" abbreviated).
Accessing the same reports from reportserver works fine, all the datepickers starts on monday("lu") and it works fine:
I've checked that user's Culture and CultureUI it's correct (es-ES for spanish culture); and i think that's working fine cause today's text and day names are properly translated...
I've Googled it and i have only found that if you change DATEFIRST in SQL it must be solved; but it doesn't.
Can anyone give me a clue or any solution?
I know that i can use my own parameter selectors and call the reportViewer only to load the report with the parameters, but this solution will take a long time and we prefer to avoid that solution.
I've also read that with Reflection i can access the Datepicker class inside Microsoft.Reporting and change it to start on monday; but it's not a "nice" solution and it's really complex.
I've had similar trouble with date-format on the client. The doco says that it should determined by the Language of the report, so set that to the language of the client (see below). You could even be more specific and set the language to es-ES
But I've found this approach does not always work. (for me at least). Once the report is set up like this, changing the client locale, should change the date format (and start day of week).
At one point changing the locale of the SSRS server had the desired effect (but this is a pretty sweeping change)
Related
I'm currently encountering a weird behavior of sharepoint in my current project.
The task is simple in its core:
We have a site collection, where we can create projects (projects are then subsites of the root site again). In v1 our product was only available in one language. In v2 we implement multilanguage.
When the new solutions are deployed, new project site are in the correct state.
The rootsite and older project sites are not.
I'm currently developing the update mechanism for the root and subsites.
And here somethin unexplainable (at least for me) happens:
Navigation:
The navigation nodes have to be updated the following way
foreach (CultureInfo culture in web.SupportedUICultures)
{
node.TitleResource.SetValueForUICulture(culture, SPUtility.GetLocalizedString("$Resources:" + key, resource, (uint)culture.LCID));
}
node.Update();
When I initiate the update while having german as my active display language, exactly 2 nodes are shown as $Resources:.... in german, but in english they are correct.
If i initiate the update while having english as my display language, all nodes are correct in both languages.
Listviewwebpart
On one page we introduced a few listviewwebparts. I create them and customize the view of the webpart. When I start the update with english as language, everything works fine.
The listview is completely translated both in german and english.
However, the moment i let the update run with german as active language, some fields are not translated. And here is the thing: Only in this exact listview! When i switch to the list, and check the fields, everything is ok!
I don't get it.
So in short:
- Update with german: 2 Navigation don't get the resource value (just german, english works fine)
- Update with english: Fields in listview not translated, but the fields are translated in its core.
Did someone ever encountered a behavior like this?
I tried changing the order in which the update works, but nothing changes.
I have a software developed in C#, which is a pure sentefic application. Howver the German users found this software stopped working from time to time, when it is installed on German computers. The temporary solution is to change the Language setting in the control panel, and it works fine after we change the language setting from German to English. This is just a kind of engineering sofware, and the software have nothing relalted to the German or English language. Also, as suggested from other posts in msdn, I have checked the "InitializeComponent()" in the source does several times. There are not strange codes in the "InitializeComponent()" function.
When you change locale, you change the meaning of ',' (comma) and '.' (full-stop) when used in numbers. Could it be that you are trying to parse text containing these characters into numbers?
Does your program attempt to initialize numeric fields with formatted numbers, perhaps?
You need to make sure that your code is sensitive to the user's culture when parsing and formatting text. You also need to make sure you use a consistent culture (e.g. the InvariantCulture) when reading data stored to file or sent over a network.
If you are using .NET Framework 4.5, you might be interested to read about the CultureInfo.DefaultThreadCurrentCulture Property.
In the .NET Framework 4 and previous versions, by default, the culture
of all threads is set to the Windows system culture. For applications
whose current culture differs from the default system culture, this
behavior is often undesirable.
The examples and their explanations on the page could be quite helpful for your issue.
Also, as a side note, try{...}catch{...} blocks are always welcome.
I have two tables Confirm_orders and Tentative Orders that have Start Date and End Date..
How can I implement these dates in calendar in my .aspx page?
All I want is the Start and end date (that represent event dates), to appear in calendar in the from of Red Color.. Those dates must be marked in the calendar, so that the Employee who logs in, can view those Tentative dates and can confirm those dates..
I'd start by figuring out what calendar control you want to use. There's a million of them, whether you want standard HTML, jQuery, YUI, MooTools, or whatever floats your boat.
ASP.NET has a very basic one built in. You can read about it here. It doesn't require any script or anything and you can manipulate the styles with server side code. The Microsoft AJAX Control Toolkit (Microsoft's more modern web control framework) also has a Calendar control.
Usually when I'm looking for a control that has a certain feature, in your case the ability to highlight certain dates, I find a tutorial or sample that indicates exactly how to do that first. Then I'm not tied down to a certain control. I searched around a bit and found this StackOverflow question that is very similar, using a jQuery based control. Once you read your data from your database, you can write the start and end dates out as JavaScript variables and follow the example from there.
You need to use a javascript DatePicker. There is no built-in C# HTML helper that displays a calendar.
I have a report choosing start date and end date.
I tested at the office and it is working fine.
When it is installed at the user's place, the following error pops up.
I wonder why is that?
I bring back the database and run at the office.
Still working fine.
Well, it's not a parsing problem in DateTime.Parse, which is what I first expected. Your code (Form1.Calculat) is calling the constructor directly, so you should be able to log what values you're trying to use to create the DateTime, along with which row of the database is causing the problem.
We can't really do any of that diagnostic work for you, but once you've worked out what the values are, you should look through your code to work out where they're coming from.
Does your client have a different default culture to your development machine? That's normally the first port of call - but unless you're manually parsing date/time strings into their constituent bits, I wouldn't have particularly expected this failure mode.
If you could post some code, that would really help.
Are you passing the values to the TimeToTicks method ?
Probably these values are not forming a valid DateTime. Why it works on your office PC might be because you have different culture settings.
For example, in one culture "11/25/2010" is a valid date as the format (MM/dd/yyyy), but on a different culture, where date format is set as (dd/MM/yyyy) it will not be a valid date.
You can change the system date format from the control panel or modify your code accordingly. Hope this helps.
I think it is most of a problem Culture specific rather than any other issue. At one system the date format would be MM/DD/YYYY and at other system it would DD/MM/YYYY or something like that. So the datetime object should be picked culture specific and values should be passed that way as well.
Hope it fixes the problem.
I would like to put the date the application was built somewhere in the application. Say the about box. Any ideas how this can be done? I need to do this for C# but I am also looking for a general idea, so you can answer this for any specific language other than C#.
Typically we just go with the executable's last modify date. This will be set when the exe is built and usually never changes (short of someone actually editing the file). When the file is installed, copied, moved, etc, Windows doesn't change that value.
DateTime buildDate =
new FileInfo(Assembly.GetExecutingAssembly().Location).LastWriteTime;
We use this technique for the about dialogs in our C# and C++ apps.
The third number of the assembly version is a julian date with 0=1 Jan 2000 if you're using [assembly: AssemblyVersion("1.0.*")]
e.g.
DateTime buildDate = new DateTime(2000,1,1).AddDays(
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Build
);
You should be using version control - Subversion is free. Then you could include a number from the version control system that would unambiguously identify the source code used to build the app. A date won't do that. There are other advantages too.
Full history of all changes to the project.
Work seamlessly with other developers on the same project.
EDIT: Nikhil is already doing all this. But for some incomprehensible reason he has been told to include the date as well. I'm going to leave this answer here anyway, for future readers of this question.
There are usually keywords in your source code control system for this sort of thing.
Otherwise, look at including the date and time in the version number, or simply creating a small source code file which contains the date and time, and gets included in the build