I've been working on a SharePoint project and I have gone the route of loading User Controls through a custom web part.
I have several web controls where I need to dynamically generate hyperlinks (in a loop from a database) that will call certain functions of the User Control when clicked.
When I'm building my own ASP.NET sites, I just add parameters to the hyperlink and check on the page load to see if I need to run any other code when a hyperlink is click.
I'm starting to realize that this probably won't be very reliable inside the SharePoint environment because I don't control the way web page URLs are formed.
I would prefer to have it post back when the hyperlink is clicked and pass some values, but I'm not sure the best way to approach this.
Could someone point me in the right direction?
Thanks.
You can still add querystring parameters to the end of any url and your webpart will pick them up.
The way you create the url will have to be a little more sophisticated in that you cannot assume yours will be the only query parameters on the url.
The SPHttpUtility has some helpful functions.
If you want to avoid the complexity of dealing with and parsing URL's then you need to be using the ASP.NET server controls - the whole idea of them is to abstract out complexity such as that.
http://msdn.microsoft.com/en-us/library/seey0yt3(VS.85).aspx
http://www.startvbdotnet.com/aspsite/controls/linkbutton.aspx
Related
this seems to be a bit of an odd requirement, but we have a separate form (not an infopath form) being filled out by people. Now, this form that we have has quite a lot of validations in it. We're currently trying to prevent people from accessing the list where this certain form is saving the data, this is so that they won't bypass the validations we created in the form that we created. Is there a way to be able to do this, one way or another?
Easy fix. Use SharePoint Designer to browse to the list, starting from "All Files". The list has several files in it. You're only interested in NewForm.aspx and EditForm.aspx.
Open these files. Either add JavaScript redirect code directly to the file (near placeholdermain) to point back to AllItems.aspx, or add a Content Query Web Part to add the redirect JavaScript code in that added web part.
Either way, when users go to add/edit items in that list, they will be bounced back to the page that list the items.
This will only work when JavaScript is enabled. Mind you, SP won't work very well with JavaScript off anyway, so people may not disable JS. But for a bullet proof solution, make a Visual Studio feature for the specific list.
I was wondering if someone has had a similar requirement before. What they want is a link that on the main site that would point to a different document contained within a document library every week. So week one it would be "document1.pdf" and week two it would be "document2.pdf" and so on. Is this possible for the navigation that is contained in the left hand side of a sharepoint site? Can a link be tied to a lookup? Any help would be appreciated!
You can create some redirect javascript within the Content Editor webpart. host it on a page and add a link to the page on the navigation.
This is by far the fastest way to get what you want.
Make sure to follow the advice here to be able to edit the page once you set the redirect.
I am stuck with a problem. I am having tool part where I get all the Lists present in the Site.
I have other web part which should get the selected List in the tool part.
I see that the web part is loaded first then the tool part. so the web part is unable to the List selected in the tool part.
Please note that the text box is in a User Control.
Please help me.
I have looked at your code and found the following:
First things first. You need to move AWAY from using ToolParts and the SharePoint native webpart. they are deprecated and are a remnant from SPS2003. In MOSS / WSS 3.0 you can and should use the ASP.NET WebPart.
Secondly, I think you are mixing things up. The ToolPartGetLists is not a toolpart, it is a webpart, that in itself loads the CustomToolPart, which in turn allows you to select a list.
This toolpart is only shown when you edit the shared webpart in the UI. The list you select is then persisted to the SelectedList property of the webpart using the toolpart.
The connected webpart then tries to read the SelectedList property I guess.
Like I said, I could go and try to fix the code for you, but it is not the way to go, you really (REALLY) need to switch to ASP.NET WebPart based webparts. The native sharepoint one WILL be fased out in the (near) future.
Here you can find an example, with code! (scroll to bottom for download link). As a bonus, it uses the built in sharepoint listpicker
I don't know of any way you could control the load order of elements (web parts) on the same page.
Sounds more like you want to have your second web part (the display of the lists) have a "default" when the page loads--which could be empty. Then it would be changed to the selected list only when the user clicked a new selection in the other web part (the list of lists).
The biggest problem I have faced so far in sharepoint, is to be able to make a certain webparts invisible or hide if the user is not logged in, basically to be able to make an audience for anonymous user.
If anyone knows how to do that, please help.
As far as I know the only way to do that out of the box is to wrap the complete Web Part Zone in a SPSecurityTrimmedControl.
Another thing you could try is to create Control Adapter for every single Web Part type and then implement the display logic in there. Please notice though, that this approach has some limitations. The most important is that all Control Adapters will be applied to every single Web Part in the given Web Application of the given type.
A little trick I use is to hide the web part in your CSS (either your master CSS or another web part), and then use ANOTHER web part - this time targeted to authenticated users - that overrides the initial CSS, making the content visible. I wouldn't recommend it for secure content, since the web part is still being rendered at the client, but if you're going for UI elements, this works perfectly.
I'm not sure that there will be a definitive answer to my question, but I'd like to read some discussion from other folks on this... here's some quick background.
I'm creating a request form that will handle adding new equipment to our datacenter. I'm collecting some pretty basic info about the submitter and the equipment to add. Some of the metadata gets pretty complex, but I won't get into that here.
At first I started with a browser enabled InfoPath form, because most of our users aren't licensed for the InfoPath rich client. After much frustration I got things working, but could never get a level of performance that I was happy with. Since then I have been playing around with SharePoint's web services and I have a GREAT form that I've written in HTML (with some jQuery magic) that submits to a SharePoint list.
So now I'm asking myself... why not just use this form? First, I can get rid of InfoPath completely... that also helps us out with licensing since I won't need Enterprise licensing. Second, performance... Third, sure I have to hand code it, but I can, and I enjoy it.
So, InfoPath is out the door.
That leads to where I need some best practice ideas mixed in with new ideas. I've got this form that works great, but I want everything to work within SharePoint. As a test, I just created a new view for my list, removed the web part that shows the list, and plopped in my form. Aside from some CSS issues, everything works and it updates the list lightning quick!
But should it be a custom view? Should it live somewhere else? Should I just edit NewForm.aspx?
I'd love to hear some thoughts on this. Ultimately, my entire solution will be deployed as a Feature, but I'm not sure that's relevant.
Thanks!!
I would've done it mostly the same way:
Create a new form (via SharePoint Designer or a custom ASPX page)
Encapsulate the form in a Web Part (you can use the SmartPart Web Part if you're in a hurry)
Create as many custom views as you want, it doesn't really interfere with the way you code the form
If you must modify NewForm.aspx, don't delete the default ListForm Webpart since it's used by SharePoint for other things. You're better of just hiding it to avoid future issues.
Hope that helps
I think you should create custom form templates for your request SharePoint-List.
See MSDN: Creating Custom Form Templates.
I also recommend reading Understanding SharePoint: List Forms.
There's nothing wrong with using a custom form or a completely seperate app to edit SharePoint data. You end up with the same data you would get from using the standard new form, so it can't possibly break anything beyond the modified view.
Setting up a custom newform is probably the most appropriate place for it - easy enough to change the newform url in schema.xml or through designer.