We have a WCF web service returns back some xml containing a datetime value as a string. The value is first read out from a database and then appended to an xml string using .ToString().
We have a number of web servers running but this particular one is converting the datetime value to a 24 hour value, we need it has a 12 hour value but I can't figure out how to change IIS default date format. I have tried changing the regional settings and have look at the culture and ui culture values of the web service which are both set to "Invariant Language (Invariant Country)".
I think it might require a registry change. Does anyone know how to change the datetime format of a web service?
We cannot change the code at this stage so my only choice is to update the server itself.
Its running on windows server 2008.
thank you
Nevermind people I've figured it out. To change the datetime regional settings of an IIS website/webs ervice here is what you do:
First go into IIS and click on the website/web service you want to configure. On the right hand side open up .Net Globalization and change the culture and ui culture to anything other than the one you want.
Now in the control panel go into the region and language screen and change the datetime format to what you want it to be. Then on the administration tab of the region and language screen click the "Copy settings" button and tick the box "Welcome screen and system accounts". Click ok on both screens to exit region and language.
Now go back to IIS and change the culture and ui culture back to what it was before you change it. Your website/webservice should now be serving up the correct datetime format.
I think the key point here is copying the region and language settings to all system users. then changing the IIS culture settings makes IIS pickup the new settings. You might get away with not changing the culture and simply restarting the webserver or the machine after making the changes in the region and language screen but i haven't tried this.
Related
The only localisation I could find is described here:
https://dotnetbrowser.support.teamdev.com/support/solutions/articles/9000110018-chromium-language-localization
DotNetBrowser allows configuring Chromium engine with specified
language (two letter code from ISO-639 e.g. "en", "de", "it", etc).
The language will be used for UI text messages localization (e.g. text
on the web page that's displayed when Chromium failed to load URL).
By default, Chromium engine is configured to use .NET application
language that can be received from
theCultureInfo.CurrentUICulture.Name property. To configure Chromium
engine with .NET application language, DotNetBrowser extracts the
language from theCultureInfo.CurrentUICulture.Name property and passes
it to Chromium engine via the --lang Chromium switcher.
If you need to change this default behavior, then you can configure
Chromium engine directly with specified language via Chromium--lang
switcher.
Unfortunately this does not seem to apply any date formatting (which makes sense as it only seems to pay attention to the language "en" and not the locale)
When I print, the header on every page has a date which is in US format. My customers are not in the US and giving them dates in US formats would be a disaster.
Is there any way to set the date format in DotNetBrowser / Chromium?
In Chrome Advanced Settings I can pick English New Zealand and English UK as languages and those settings do affect the printed page headers.
You could specify English UK locale as "en-GB" as shown below:
BrowserPreferences.SetChromiumSwitches("--lang=en-GB");
Do not forget that this switcher should be set before you create any Browser instance.
This article describes how to set Chromium switchers: https://sites.google.com/a/teamdev.com/dotnetbrowser-support/documentation/chromium-switches
I have used Ajax calendar extender in my application in which, it is deployed in sharepoint site.
I have set my regional setting for my sharepoint site as "Sweden-Swedish" also, my site has "Select language" option for the end users.
Problem is: whenever anyone choose any of the languages from "Select language" option, it will not have any impact on the ajax calendar control, instead it is showing the day and month names in "Sweden-Swedish" culture.
Immediate help is appreciated.
Ajax Control Toolkit relies on a standard ASP.NET culture detection, which is based on browser's regional settings.
If you see, that other sites are shown with Swedish culture as well, then you can force it.
I have the regional settings set to UK in Sharepoint.
The Regional settings are also set to UK.
I have a date picker in the a custom web part.
This is sometimes showing in English US and sometimes English UK.
I have load balanced environment so perhaps it could be that one server is set correctly and one is not.
Is there any where else where I need to check for regional settings. I have checked the server settings from control panel, and the settings in the site collection?
Could there me any other reason why the date picker is acting this way please?
Thanks,
Joseph
Within the Sharepoint:DateTimeControl tag use LocaleID="2057" to show the date in UK format.
I think it will solve your problem.
Thanks,
Aniket Banerjee,
Senior Software Developer,
Mindfire Solutions
I was updating a COM+ application, when an error showed up, saying that it couldn't be changed. Now, whenever I go into properties on one of the components in that application, or the properties for that application, everything is greyed out, not allowing me to change it. Delete is no an option for the application, and if I hit delete on the component, it tells me "Some changes could not be applied due to the following errors:" - "The selected item cannot be changed. The item is currently locked against changes." I can't seem to find anything on google. At one point there was an HRESULT that showed up, I don't remember exactly what it was, but it turned out to be something like COM_ADMIN_E_NOT_CHANGEABLE, which also didn't give me much from google.
Logged on as domain user with admin privileges.
Running windows server 2008 standard.
Do you have the Protection (Disable deletion and/or Disable changes) enabled for the COM+ Application? Check by looking at Properties->Advanced for the Application:
If so then un-check Disable deletion and/or Disable changes and click OK. You should now be able to make changes/delete the application.
Going off what Lucas had said, it will work if you do a .\Administrator, and edit the properties.
The important thing to note here is under the Properties of the COM Object, the Activation tab will be the focus. Try selecting Server Application here. Then under the Security tab, choose Authentication Level to Packet, and impersonation Level to Impersonate.
This should allow you to change anything you want now.
For me, the answer was simple. Login as the local admin. ".\Administrator" then I had no problem bringing up the property pages for the COM+ applications.
I use AssetsLibrary to present pictures from the user's camera roll. However I'm not interested in the location data of those pictures. Is there a way to disable this location service prompt?
there is no way to disable the prompt. Enabling "location services "is a requirement for using the AssetsLibrary. The reason is that any photos/videos in the Photo-Library might contain geodata. This data is not just available through ALAssetPropertyURLs, but also if you read out the raw data from the asset (by using the getBytes:fromOffset:length:error: Method of ALAssetsRepresentation). Cause there is no way to strip the geo metadata from the raw image data (in case location services are disabled), I guess the design decision was made to make "location services" mandatory for using the AssetsLibrary.
This requirement might be confusing to the user. So you need to do 2 things:
1) If the user denies access to location services, then present a clear message while your app needs this access and that the app does not actually determine the current position or any GPS/data.
2) Display clear instructions how to enable location services, once the user has pressed "NO" on the initial dialog.
Cheers,
Hendrik