We have a 3rd party component that takes INPUT as an .xsn (InfoPath2007) file and gives a pre-determined output. It was all fine until one of our client decided not to use MS-InfoPath anymore and as such even our 3rd party component is not able to function as we are not able to create xsn files (which were created by a human-InfoPath user till now, until InfoPath was discontinued in their group)... so the challenge for us is to create these SIMPLE (textbox, dropdown, date-picker and check-radio-box controls) InfoPath like forms -- .XSN files programmatically. Is this possible? Are there any APIs or Object-model based functions that can be leveraged for this task. Our team is predominantly C# developers. Our current analysis reveals that files pertaining to manifest, XML, J-scripting parts of .XSN might be achievable after some careful coding... however XSL (part that is associated with layout) seems to be a big gamble. Any pointers on this subject will be greatly appreciated.
UPDATE (as the problem statement does not seem to clear yet):
We do not want to convert InfoPath form into any HTML or alike format.
NOW here, we need to create some simple (pre-determined control-types with their known data) InfoPath forms programatically in .xsn file format. We want this to be done programatically, because earlier it was being done by a human-client who no longer subscribes to InfoPath-license and hiring another human for doing this is ruled out for various HR-reasons. So this "programatically"created xsn-file is fed it into this 3rd party component. Then this 3rd party component reads through the various parts inside the xsn-input and manipulates on it, into an output custom-file-frmat such that the custom 'workflow-component' keeps working further ahead... so hope you get the bigger picture now. Now an xsn file is essentially a CAB file consisting of many parts-components like manifest, xsL, xsD, xmL, images, jScript etc. So now if I have a winforms or ASP.NET webform... is it possible to write some component (using InfoPath object model or APIs) which can read through the UI-controls of this winform and then come up with the essentials that need to go into xsL, xmL, manifest etc so as to "collectively get compressed" into an InfoPath form!!!
Yes it is possible to Automatically create InfoPath Template Forms. The XSN is nothing but a cabinet file (.CAB) having the extension renamed to .xsn.
To further understand what are the contents of CAB file and what do they do, please follow the link:
A beginner's guide to forms and form templates
Following are the links that shall help you further.
Microsoft Cabinet Software Development Kit
A relevant Q&A to open CAB through C# program
Related
In short, im creating a Visual Studio extension in c# that enables non-automation testers to create automation scripts for web based solutions (using selenium).
We've created a template already for users that lays out the project file structure (test runners etc) and im using windows forms toolbox controls to create the dialogue windows where they will enter things like URls, Xpaths, page names etc etc
My question is this;
How on earth do i go about creating .CS files dynamically based on their inputs in these toolbox windows?
The simplest (he says) window i have is one that simply allows them to enter a URl and a webpage name. When they click the 'ok' button on this window, it should create a new .CS file with the webpage name as the class name, the url as a string that the webdriver can use to kick off the test and a few other bits and pieces as a template for them to start adding web elements to.
Any guidance would be greatly appreciated, there seems to be precious little around the web about creating VS extensions!
You got a few options here.
Typically, most people would do this by implementing a custom project item template, along with a custom IWizard based wizard associated with your template.
If you are displaying a modal UI from your IWizard.RunStarted, you can simply populate the ReplacementsDictionary with the text gleaned from your custom UI, which would then be swapped for the tokens in your templatized .cs file.
Or you could programmatically add code to the file after it was generated and added to the project (admittedly a much uglier and more difficult to code).
And finally, you could just generate the file in the project directory, and programmatically add it after the fact.
There's a number of old blog articles from the archived VSX Arcana blog that you might also find helpful.
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.
C# expert and ASP.NET developer at heart, I find myself assigned now to an Office Add-In project. Luckily I have worked on several Excel Add-Ins in the past, but it's all blurry in my mind and I never had a chance to learn it in a well structured manner.
I was surprised to notice that SO and the whole Internet is lacking proper documentation for VSTO, Word DOM, OpenXML, etc. Lacking might be an exaggeration, but it's not abundant or well organized, that's for sure.
So what I'm looking for basically it's an overview, jump-start, or cheat-sheet, however you want to call it, containing a high level summary of the important parts of Office development.
PS: I will post my findings as well during my study.
My 2 cents
1) For latest WordArt in word, you would need OpenXML data to insert in Word. For Excel\Powerpoint, things are easier, you can just use interop.
2) Don't always trust the documentation. If you get an int instead of a bool return value, its mostly a value from MsoTriState. e.g. Bold property should return bool as mentioned here. But, instead it returns int. So, you have to cast it like "(MsoTriState)returnedBoldValue" to figure out what that integer actually means.
3) Installation can be a pain, consider using ready-made products like Advanced Installer(I found it cheaper than others). Others might be good or better as well.
4) Table styling can be a pain. Here is a list of the weird IDs you need to use it for Powerpoint.
5) TextFrame2 is still not valid for Word(even if the documentation might say otherwise). Its only available to Excel and Powerpoint. For Word, you have to use TextFrame.
6) WPF is not supported. But, I was able to get it working just fine after some research. You need to make sure to load resource dictionaries and they work fine as well.
7) Window Association was a bit of an issue(Parent - Child). WindowInteropHelper is your friend there.
For now, I will stop here. I will post some links later.
Document Level Architecture
Document
Template (essentially the same as Document from VSTO's perspective)
"Contained" by the Document.
Document contains the relevant information required to load the Add-In. Does not use Registry.
Application Level Architecture
Add-in
Directly plugged into and loaded by Office. Agnostic to Document. It is registered via Registry keys.
Ribbon
Supported by Visual Designer. It handles state automatically for you.
Ribbon X
It allows a much better customization. It's XAML like. No Visual Designer. It doesn't handle state. You need to handle state on your own, using callbacks.
Word DOM - Document Object Model
Application
Documents
StoryRanges
Range
Styles
Style
Windows
Window
Panes
Pane
It is nothing special, just another DOM, quite similar to the HTML one. However, it will take some time to get used with it and the information on the Internet is not as abundant as one might hope.
Manipulating the DOM
Directly
VSTO Controls: Windows Forms Controls, Host Controls
Windows Forms Controls
Powerful (supports .NET databinding for example) however they are not really part of Office so they will feel like a nut in a wall.
Host Controls (wrappers around the Interop Word objects)
Bookmark Control - old method, move on, nothing to see here.
XML Node & XML Nodes - deprecated. Removed in USA due to lawsuit.
Content Controls - The future! Support real data binding to hidden XML data field in the XML parts of the document.
Deployment
Click-Once - simple and fast. It adds the Registry entries for you. But it doesn't allow much customization. For example you can have a Click-Once project installed only to the current user.
Windows Installer, Installshield, etc. You need to add the .manifest and the .vsto files to the output. You need to add the registry keys.
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 want to create a help file opens when pressed F1 anytime. How to create it and include to code?
You are asking two things which are separate issues:
Create a help file.
This can be tricky depending on how you do it. There are many different options, some launch a web browser to a online help while others launch a help viewer of some kind. I have also seen people having simple help viewer implemented in simple controls like some kind of browser control or rich text viewer. To create a external file (like a *.chm file) I would use a commercial package like robohelp, there are SDKs from Microsoft, but packages like RoboHelp makes lift so much easier.
Launch the help
To get the help to be displayed you normally (in the case of an *.chm file or an web browser) need to launch the viewer program. The help SDK from Microsoft contains help for this, but you may also just lauch the program as any other program. Take a look at the System.Diagnostics.Process class.
If you want to create a CHM help file you may check out HelpNDoc which is a perfect tool to create PDF,HTML and CHMs instantly. If it comes to launching, mrz is also perfectly right.
There is a help SDK that microsoft provides
check it out:
http://msdn.microsoft.com/en-us/library/ms670169
Im assuming this is what your looking for?
you could set F1 to one of these HTML pages?
If your program is rather simple, a single HTML file opened in the user's default browser should be ok. But if Your application is a bit more complex, there's no real alternative to a chm file.
You might also include a PDF which describes common use-cases. (Like a book about using your software)
You can create your help in HTML format and for viewing, you can create a Form which has an embedded browser in it, and load the index (or whatever you call the first page) in the browser.