Tag Info

Hot answers tagged

4

Since you use more complex data types, the toolpart manager cannot convert the data type to a field in the toolpart (as you do) When you add your custom toolpart this will inevitable be placed over or under your OOB toolpart (you handle where in your toolParts array). However if you add your other "simple data type" custom properties to the toolpart as ...


3

I believe you can accomplish what you want by adding some code to the property declaration like this: public string TextBox1 { get { if(!String.IsNullOrEmpty(_TextBox1)) { return _TextBox1; } else { return "My Default"; } } set {_TextBox1 = value;} } string _TextBoxl; To be honest there is so much information in your question it is ...


3

When I have done the same I have always set the values of the custom property controls inside the ToolPart's CreateChildControls method to the corresponding values of the properties in the WebPart. protected override void CreateChildControls() { (MyWebPart) wp = (MyWebPart) this.ParentToolPane.SelectedWebPart; TextBox t = new TextBox(); t.Text = ...


2

If you are talking about a Publishing page by any chance, you could use any of the fields of the underlying Content Type via the Page Field filter web part and send that to any of the web part in the page via connections. Of course not every web part support Connections, but most ListViews or DataView support that. Additionally you could simply use any of ...


2

This purely depends on where in the life cycle of the Web Part you use the properties. If you use the values early before the "ToolPane" gets the clicked event for Apply/OK which causes your ToolParts ApplyChanges to fire and change the properties, well then the changes wont show up until next pageload. If you use the values late (after the clicked event) ...


2

I would do it in the setter. As you are throwing an Exception anyways it is cleaner to not let the user set the value in the first place. If you would do validation only in the ApplyChanges method, other code might have worked with the already wrongly set value. Validate in set, so the user isn't even allowed to write invalid stuff to your variable. Here ...


1

Pretty sure there is a limitation in the app model against doing this. Only basic tool parts / custom properties like string, int, bool or enum can be created in app Webparts See section Table 2. App part custom properties here: http://msdn.microsoft.com/en-us/library/fp179921.aspx


1

Sinuhe, MSDN provides a pretty reasonable guide for what it is you are trying to do. Please check out "Creating a Custom Web Part Editor in SharePoint 2010" and see if that offers you any help. I can't give you the specific answer you are looking for but this should at least point you in the right direction. Unfortunately, there does not seem to be a way ...


1

It's mostly a question about CSS. As I some what support the Javascript ideas, I must say they are a bit overkill, as you easily can edit the CSS for both the Ribbon as well as the ToolPane. .ms-ToolPaneOuter this is the ToolPane CSS class you'll need to modify the CSS for. s4-ribbonrow the Ribbons div ID, or if it's only the Toolbar Ribbon, it's this class ...


1

I can only assume that the web part was added to a page layout that had a web part zone and a rich content zone below it, or had two rich content zones, and only the label for the bottom one is visible. It is a poor example from MS though. They could have at least had more context of the page it's running in, like a Team Site. That way we know what's normal ...


1

Those Properties are stock standard with any Sharepoint webpart as you know. I have not tested the following code, but i'm pretty confident that this should work: public override Microsoft.SharePoint.WebPartPages.ToolPart[] GetToolParts() { Microsoft.SharePoint.WebPartPages.ToolPart[] myCustomToolparts = CreateMyCustomToolParts(); ...



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