I am writing an XSD parser which dynamically builds simple WinForm (based on input XSD scheme).
I want to use only xsd defined structures, not adding anything beyond xsd standard elements.
Questions:
I want xsd:element to define a control. How to distinguish which xsd:element defines which control type (especially the bolded ones)? (basic are TextBox, TextArea(multiline textbox), ComboBox, RadioGroup(group of radiobuttons), DateTimePicker, CheckBox, Panel, Button).
How about labels - maybe is it better to define them inside xsd:element of other control containing data (TextBox, etc.)? How ?
I need this parser to enable the clients to generate a schema by 3rd party tool then populate the XSD into my app and open WinForm (without need of programming it) and in further steps produce xml with data and some output.
I think you can get a lot of ideas by having a look at XMLSpy. Specifically, their Stylevision technology is probably very similar to what you are trying to achieve.
I think it also highlights a bit of an issue with your concept in general - an XSD does not contain all the necessary information regarding how to capture the data that the XML will represent. You could assume default editors for specific types, etc, but pretty soon you will run into cases where someone wants something to work differently, and XSD will not, by default, support it. I am pretty sure you will end up with some non-standard extensions, which no out of the box tool will support, or your own XML-language for defining screens. Nevertheless, I suggest having a look at XMLSpy, some of their tooling is excellent and should give you some ideas.
Related
I want to create a program that will enable user to open a file. That would create a new tab and assign a class to that tab that contains over 200 fields of various types (which I have already designed, along with read and write code of the program).
Then I would create an interface that would enable user to change any of that 200 fields.
Does that mean I have to create a property for each and every single of 200 fields that I have in order to bind them with fields?
Is there another way? Is this kind of program more viable for WindowsForms?
It seems a lot easier to do this programmatically instead of using XAML.
Is there a 3rd solution?
Maybe you are looking for the PropertyGrid. It may be not as beautiful as you'd expect, but it would cover major of your needs. There're some customizations examples, but it still looks ugly (IMO).
Otherwise you could create a control by yourself. Define deferent templates for various types of your properties. It shouldn't be difficult: some reflection, create bindings via C#, some templates.
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'm trying to design my C# winform application with a very generalized function to automatically go through all of the form elements and save their states/values in a text file so that I can load it later. I want it to be very generalized so that it'll be a cinch to reuse this code in future projects, as it wouldn't be heavily tied down to the specifics.
The form elements I want to save are text boxes, combo boxes, data grid views, list boxes and that's about it. I want to save their values and everything about them.
One way that I was going about it was to go through every possible form element and then detect eachs type, and then create the corresponding c# code to re-create its value ('tboxmine.value="blue elephant"'), and then writing the code to a file, so that I could load the code from the file and execute it using the CSCcompiler. My code so far doesn't seem to be working correctly and I'm having my doubts that this compiler is actually running the code inside my application (I think it's possibly creating a new thread?), and it just seems like there's probably a far more straightforward relatively standard way of doing this.
This seems a bit like the reverse "best practice" approach. If you dont't know about databinding I suggest you look into that.
Basically you create classes to represent your data and use databinding to associate controls with your objects. The controls will automatically show the right value and allow the user to change it. If the user has changed the value, your object gets automatically updated.
To save the data, you would use some kind of serialization to store your objects in a file. When loading, you let the Serializer rebuilt your class structure and (best case) you are good to go.
This is not exactly what you asked for, but I think it is something you could use well ;-)
N.B.: Not the complete state of the control is saved. e.g. in a Textbox your text would be saved but the BackColor won't.
To get you started look into this tutorial: http://www.codeproject.com/Articles/24656/A-Detailed-Data-Binding-Tutorial
I want to change the appearance of the default editor parts, and am a little unsure of how to go about doing this, as there seems to be a surprising lack of documentation on the subject.
I've been able to create a custom declarative catalog with some trial and error and overriding the RenderCatalogPart method, and now wish to do something similar with my AppearanceEditor and PropertyGridEditor. I've tried just changing the style of the editor parts using CSS, but they are already arranged into tables which are impossible to get rid of. It's not even possible to just take the class as is, because the classes are sealed. So I'm basically stuck with having to write my own from scratch, I guess the questions are as follows:
1) How do I go about getting the information on the controls I need to render?
2) According to the documentation, I need to override the ApplyChagnes and SyncChanges methods - but I can't find any information on what I actually need to put in these methods.
3) On a similar note, is it possible to change the layout of the EditorPart itself, so that the AppearanceEditor, BehaviourEditor etc. are displayed side-by-side instead of on top of eachother?
4) Is there any way to have the page catalog displayed somewhere on the page, even in browse mode? I'd quite like to use it as a 'minimised' area, where users can send web parts they don't want immediately. At the moment they go back into the page catalog and users tend to just add a new part instead. I know that I can have multiple catalog zones on the page, which is great, but it only shows up in catalog mode.
Any help would be very much appreciated.
I didn't get any replies here, but I was able to figure out a way to do some of these.
In the end I decided to use reflection to get each public property on the web part that was WebBrowsable, and figure out what sort of control to display from the type.
The ApplyChanges() and SyncChanges() methods essentially just persist the changes from the page to the personalization blob and vice-versa. It's a matter of rendering some controls on the page, and mapping the values to the properties of the web part in these methods.
I don't think this is possible without writing your own.
Haven't been able to do this, but I don't imagine that it's possible sadly.
WPF makes it very easy to create conditional formatting rules at design time based the underlying bound data values.
Are there any existing solutions that allow end users to create conditional formatting rules at run time?
Edit: I understand how to apply conditional formatting. I am curious if there are existing solutions that provide mechanisms for end users to create custom styles at run time
Edit: Excel's Conditional Formatting capability could be viewed as an example of the type of capability I am looking for
Karl Shifflett did a demo LOB application in WPF a few years ago. He demonstrated a way to dynamically load XAML "skins" in your application. Using this type of logic, a customer could create XAML and load it dynamically to skin the application, or you could provide an interface for a customer to dynamically change style properties and have the application appearance change based on those property settings.
His example is on his blog as well as on the Code Project.
Everything done in WPF via XAML can be done in C#, so you can create styles and triggers with C# only.
Here's an example.
For runtime formatting solutions, I would suggest using value converters.
You can get inputs from end users on what kind of formatting they need. And apply them in converters.
The following link How to customize tool item and tool container may help you. The LinsUIWPF suite is a free software. It allows end client to customize all tool items and tool container style.