Tag Info

New answers tagged

0

I have copied the default image in SharePoint and using the below code to load the default image: imgUserProfilePagePicture.ImageUrl = SPContext.Current.Site.Url + "/_layouts/15/images/PersonPlaceholder.200x150x32.png";


0

I used the following code: SPSite site = SPContext.Current.Site; UserProfileManager userProfileManager = new UserProfileManager(SPServiceContext.GetContext(site)); // accountName is Active Directory account UserProfile userProfile = userProfileManager.GetUserProfile(accountName); // PictureUrl is the property you need to set.. set it to Empty string.. ...


0

I had a similar problem and it was related to wrong deployment under "\14" folder, that it's the old layout for Sharepoint 2010 compatibility mode. I suggest you to deploy and check if your project is correctly comparing under these folders: [Common Files]\Microsoft Shared\Web Server Extensions\15\TEMPLATE\CONTROLTEMPLATES\[Your Project] [Common ...


1

Fixed it by using the following code: private const string _ascxPath = @"~/_CONTROLTEMPLATES/15/VisualWebPartProject/Export/ExportControl.ascx"; Note I just added 15 after CONTROLTEMPLATES.


0

your issue is here: private const string _ascxPath = @"~/_CONTROLTEMPLATES/VisualWebPartProject/Export/ExportControl.ascx"; but you have this location.... spot the difference: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\CONTROLTEMPLATES\VisualWebPartProject\Export\ExportUserControl.ascx your code should be: ...


2

According to this article Sandboxed Solutions support both custom actions as well as visual web parts. The following are not supported. Application Pages Custom Action Group Farm-scoped features HideCustomAction element Web Application-scoped features Workflows with code


1

There are certain recommended hardware given by Microsoft. Depending on the traffic you get to your SharePoint server you may need to scale your hardware. Writing to a custom list is the general and the safest method considering the set of operations supported by lists. If the server side object model is slowing you down, you can use the Javascript client ...


2

First of all, you have an update panel. With that you have a few options. You could wire up a server side event to your button and hide the div on button click. The button click would cause an Async Postback which would just update the content inside of your update panel. One issue with your code is you are using normal html elements. To make your ...


1

Well, you can still register scripts in a Web Part through the ScriptLink control: <Sharepoint:ScriptLink ID="ctlScriptLink" runat="server" Name="file.js"></Sharepoint:ScriptLink> You can also just embed the JS in a script tag in your web part for the time being to test if the code works (or use a content editor web part on the page). ...


1

This should work. $('#Hide').on('click',function(e){$('#div000').hide(); }); $('#Show').on('click',function(e){$('#div000').show(); }); Add this inside the page load event.


2

It depends on what you want to do with the data, I'd say. In general, I would recommend the custom list approach, especially if the purpose of the form is to collect data and use it later. Recently, I built a custom 'poll' web part that did just this - I had a PollResponses list that stored the choice the user submitted through an AJAX request, and then I ...



Top 50 recent answers are included