Can anyone point me in the direction of some potted WPF controls for interacting with SharePoint fields? Ideally, they should have comparable functionality to the HTML fields defined in the SharePoint XML namespace used in SharePoint designer. An ideal scenario would be to include similar syntax to the server-side defined HTML elements referencing a field in a list, and let the control decide what sort of data it needs to represent, and whether it needs to be editable or not.
In particular, I need it to support:
A people finder field that allows people to be identified from their names, email addresses, or usernames, much like the default HTML form element.
A formatted text field that provides basic formatting tools in the ribbon, as well as being able to provide the formatted text back as HTML (because this is how it seems to get stored in SharePoint).
Text boxes (single/multiline), combo boxes, and radio buttons (but these are all relatively easy, because they already exist as WPF controls)
In addition, values need to available in a way that allows me to push them back to the server and expect items to update. This is most important for formatted text and user "people" fields, since their displayed value is often quite different from the actual value (e.g. includes indexes to the UID for the user, or includes HTML respectively).
At present, following a lack of responses to a similar question on SharePoint StackExchange, I'm hosting the existing SharePoint forms in a WebBrowser control, which is, fairly obviously a pretty sub-optimal solution (mostly for UX and stability reasons); worst case, I can inject some CSS into the pages being displayed to hide them, but I'd really rather be abel to build something that's relatively robust.
SharePoint 2010 has provided both the Server Object and Client Object model using which a developer can use a client interface like WinForm or WPF and interact with SharePoint 2010 Web Applications, as well as work with SharePoint Objects. SharePoint 2010 has also provided Web Services and WCF services using which any client UI application can interact with it.
To use client object model, SharePoint 2010 has provided the following assembly references:
Microsoft.SharePoint.Client.dll
Microsoft.SharePoint.Client.Runtime.dll
You can find these references from the following path:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
And for 2013:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI
Sources:
http://www.dotnetcurry.com/showarticle.aspx?ID=761
http://www.dotnetcurry.com/showarticle.aspx?ID=758
This said, have you considered to do this using the content editor web part and JavaScript / jQuery and incorporate the app into the SharePoint stack?
Here is a similar question answered
Hope this helps!
Related
I cannot seem to understand if I need Microsoft.Office.Tools.Word and how to get it. I know that it works together with Microsoft.Office.Interop.Word as seen in this article, for example:
Visual Studio extends the Microsoft.Office.Interop.Word.Bookmark
object by providing the Microsoft.Office.Tools.Word.Bookmark host
control. The Microsoft.Office.Tools.Word.Bookmark host control behaves
like a native Microsoft.Office.Interop.Word.Bookmark, but has
additional events and data-binding capabilities. You can bind data to
a bookmark control on a document in the same way that you bind data to
a text box control on a Windows Form. For more information, see
Bookmark Control.
and that it enables you to add controls to a word document here, but I am not sure what the added value is (or if I need it).
I am developing an application that will generate a report of cyber security risks in a company (with primarily text and tables), and I am wondering what I have to use to make sure I can create my report properly (Microsoft.Office.Interop.Word at the least).
Also, I do not really understand where to get the Microsoft.Office.Tools.Word from. I included the Microsoft.Office.Interop.Word from NuGet easily, but I cannot find the other one in either NuGet or the Reference Manager. Because of this, I can not play around with this extra functionality and determine whether I need it in my project or not.
If you need more detail about my project to answer this question, feel free to ask.
No, you don't need to do Office Interop. Note that doing Office Interop requires you to have Office installed, also on the PC where you finally want to use it.
For a DOCX report, there are libraries like docx by XCeed (formerly a Github repo by the same author of docx on Codeplex) which can do things a lot easier. However, not all features might be supported.
My main goal with SharePoint is quite simple, I want to develop an intranet heavily based on tables and forms by using a tool/designer which doesn't force me to code all new/edit forms for List entries.
Presently I have a custom form in SharePoint designer to edit a list entry and I would like to add server side code (c#) in order to implement some specific behavior, for instance run a custom Page_Load function.
The issue is that I'm not sure how to do it and which would be the best approach, most of the examples online show an approach using Visual Studio and creating a new list (couldn't even find a way to use an existing SharePoint list) and then code the forms from scratch which I don't want.
So how can I enhance the SharePoint Designer pre-built form (image below) with server side (c#) and client side code (js) ? If possible I would prefer to do it with Visual Studio but I didn't find a way to start customizing an existing Form aspx from VS.
My suggestion... if you don't mind using Server Object Model, you could use a Visual WebPart. It's encapsulated and promotes code reusability. From there, you could include client side code, or server side code. Personally I prefer VS to do this, but if you prefer SD, here is a walkthrough https://msdn.microsoft.com/en-us/library/ee231546.aspx
And here is a link on how to include it within an application page
Add a WebPart to an Application page
Hope this helps a bit
I have created a document library with name "ARTICLES" in SHAREPOINT which stores documents. Now, I want to display the documents in Repeater and clicking on row it must display the document. And also all documents must be Downloaded in Application folder.
The application is pure asp.net application using c# and not a webpart or other.
Help appreciated!
thanks!
Although it might not suit your application (and it isn't exactly what you asked for), there is a much easier way of achieving what you described (suited for intranet applications where Windows Authentication is used).
It involves two parts:
In your web application add a IFRAME that points to your SharePoint library (using the default SharePoint web interface).
[optional] Add a custom master page to this library so that you can hide menus etc.
For many applications this solution is sufficient and saves you lot of trouble of coding the integration (and retesting it with every SharePoint update) decoupling your application from SharePoint. It also makes sure that the end user can use all SharePoint functionality such as uploading the changes directly from Word etc.
I need to create a simple application that would generate reports based on database data and some user input. I have vast C/C++ experience, but for this project we had to choose C#.
I want to avoid using 3rd-party components that would require installation on a client machine as much as possible. Thus, I would like to avoid using even the features provided by MS Office (I could have used an XLS template, just like my predecessor did, but it doesn't look like a way to go; anyways, my predecessor's sources are long lost, which is probably good, since it is a roughly 10-years-old VB monstrosity that crashes every now and then). The same goes for crystal reports and whatnot.
My current idea is to build HTML tables (using an HtmlDocument) on the fly, to present them to the user (using a WebBrowser) and to print them. Is it a right way to go? Are there any simpler/more robust/better approaches? What are the possible pitfalls?
Building tables on the fly would work. I use that technique every so often, but it seems like a hack to me. I only use it because quite often, the business need requires "good enough" and quick turnaround as opposed to "beautiful".
I'm going to preference what I'm about to suggest bysaying that I have a strong bias against 3rd-party components myself.
I flat out refuse to use them in most cases and will go out of my way to come up with another solution, because I've been burned on upgrades/licensing too often.
That said...
Fortunately, with .NET not all 3rd party components need to be installed to your clients PCs. With XCOPY deployment, often you can just reference a .DLL or a project in the solution ans specify the "Copy Always" or "Copy if newer" option to just include the dll (or resulting dll if you're referencing a class library project) and as long as the .dll is present in the same directory as the executable, the 3rd party component works.
With all of that in mind, there's a project that I've used to print a DataGridView from Windows Forms at CodeProject. This is one that you can get the source for, reference it, and use it without having to actually install anything at the client. I've used it in more than one app, and it's one of my favorite tools.
It will print ONLY the DataGridView, but it prints it exactly as it appears on screen, so if that's what you want, I'd recommend at least checking it out.
As a third option, you could consider using ASP.NET. If you're going to be generating HTML, it's just as easy (easier actually) to do it using ASP.NET than in a WinForms app. Using ASP.NET you get Repeaters, ListViews, etc, all of which make the reports easy to create.
I've got more than one real-world app that is primarily a WinForms app but has an associated reporting site.
For example, I have a WinForms app used for scanning coupons accepted at our retail locaitons. It's a WInForms app because I need to interact directly with the scanner on a COM port. However, for the reporting portion, I set up an ASP.NET website. In the WinForms app it's very simple to create a reporting menu option and point to the pages. Our users generally don't even think about the fact that this is two distinct applicaitons. They see it as one - their Coupon Scanning app.
The point of all that is that it's usually possible to do things with any given tool, but it's far easier to use the tool that is meant for the job. If you're going to be generating HTML reports, ASP.NET is a better tool than building the reports manually, and if you need to have a WinForms app for most of the UI, you can still do that and use the website for the reports - using the best tool for each task.
Maybe you would like to check RazorEngine, to create your HTML templates.
I recommend you Razor engine to render html, it is more flexible than working with HtmlDocument objects.
You can create a file with your report template, and then parse it sending a Collection of your report rows objects.
I've created a website for a client of mine. It is coded in ASP.NET with C# and hosted on GoDaddy. She requires this website to updated daily by her. However, this client has very little knowledge of how to edit HTML or text within a site. I don't want to edit it every time she wants an update on the site.
What would be the best solution to my problem? I have looked up Content Management Systems, but I'm a little confused by what exactly it does in terms of coding and the management of the existing site. Does it require me to reformat the whole site to follow the CMS's 'templates'? Would it be better for me design my own back-end panel for her to edit the content (this would obviously take significant work)?
If you want to stick with a site you're developing from scratch, I'd use the HtmlEditor from the AjaxControlToolkit or a similar control, and store the html content in the database.
Then, when outputting the html from the database to the client pages, I'd make sure to use the Microsoft Anti-Cross Site Scripting Library to sanitize the html using the GetHtmlFragment() function (since this is tagged asp.net). It's not that much work, actually, if you design the database correctly, and if you've got the skills.
CMS systems are (trying not to oversimplify) entire web sites that are already built and allow people to edit the content using built-in content editing functionality. They range in functionality and extensibility from a "You get what you get and there's very little you can change" to "You can customize the heck out of it and buy or build your own modules to extend functionality." There are a lot of good ones out there, some free, and some expensive.