Tag Info

Hot answers tagged


A content editor web part can load the source HTML from a file and doesn't reformat it. Store the HTML in a file called "calendarhtml.txt", or something meaningful, and point the cewp to that.


I have had good luck placing links in Web Part Pages Content Editors with javascript when I don't want SharePoint to change a relative URL to an Absolute. Maybe that will work. <A title="A Test" href="javascript:window.location.href('http://myaddresshere.com/tech/@234?i=whatever')">My Link</A>. See if that works


Well, basically it calls this method SPHttpUtility.EcmaScriptStringLiteralEncode. As far as that method goes, I'm not really sure. According to the msdn article, you can go to a website that explains what ecma is. Or if this helps, here is the reflected code: private static readonly ushort[] ScriptCharMap = new ushort[] { 0, 0, 0, 0, 0, 0, 0, ...


You can't change to encoding for a single webpart but you can enter the characters as entities like: &aelig; &oslash; &aring; &AElig; &Oslash; and &Aring; giving æ ø å Æ Ø and Å


This method is used to get XML, XSL files. You need to use XmlTextReader in order to get the contents from a file. One example is listed below: XmlTextReader reader = new XmlTextReader(new StringReader(web.GetFileAsString("URLHere"))); When you are dynamically adding some WebPart this method helps to associate XML, XSL to that WebPart. This function ...


To be honest I don't know; but judging by the name I wonder if perhaps it's nothing more than an xslt equivalent of the javascript escape() function?


Instead of using UTF-16 which seem difficult, you could replace your accented characters with the equivalent utf-8-safe numerical code. This would look like the the following: string body = messageBody.Replace("à", "&#224;"); body = body.Replace("á", "&#225;"); This will effectively give your html-email-body the correct character encoding and ...


Try this http://vintentou.wordpress.com/2012/07/03/encoding-of-sender-name-using-sputility-sendemail/ This solution relates to sender name. But if It works, It can be helpful for your situation too.


This definitely does not look like a SharePoint mechanism. I guess you have something else between SharePoint and your users: Proxy Authenticate Proxy Additional module on your SharePoint server


It sounds like a proxy is running between you and your SharePoint server, and rewriting the URL query string. Could it be ForeFront UAG ?


Regardless of your encoding problem, updating the xml that was used to create fields will not push down the changes to existing fields based on that xml. If you want to update the DisplayName for existing fields, you would have to write some code (in a FeatureReceiver) to do this for you.

Only top voted, non community-wiki answers of a minimum length are eligible