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.
Related
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.
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.
I want to write a GUI seating application that allows users to draw and annotate simple "maps" of seating areas.
The end result would probably look something a little like Visio, but specifically for manipulating my "seating" data model rather than producing files.
In Java-land, there's the Graphical Editing Framework (GEF) -- is there anything like this in the .NET space? Should I just use System.Drawing.Drawing2D primitives and handle it all myself?
Here is product from Nevron. It is paid but doing it all yourself will take lot of time and effort.
Open Diagram and EasyDiagram.net are available at Codeplex. Be sure to download and look into their code.
There is Netron Library for diagramming. It is open source and uses GDI+.
Check out NShape. It is an open source diagramming framework written in C# and quite powerful. Its controls are WinForms controls but you can also use it for WPF.
You might consider using the DSL Toolkit from the Visual Studio SDK. It allows you to create a graphical DSL designer by first creating a domain model, and then creating the graphical notation that will allow users to create or edit instances of that model.
You may very well be able to create a graphical notation that looks like a seating area. This would allow your users to not only "diagram", but to produce a file containing a filled-in domain model of what was diagrammed.
Check out our MetaDraw component - www.MetaDraw.com
MetaDraw is designed to make applications like this easy.
MetaDraw will support a background image and an annotation layer
You can put users into a variety of editing modes - Lines, Curves, Text, Shapes, etc.
Every drawn element is distinct - just like in Visio, so you can allow users to select objects and move them around or resize them. Every object can have multiple hidden tags ( like seat numbers or database record pointers ). You can recognize which objects users select ( for instance take some action when user clicks seat 22 ) . You can dynamically modify propertie by code - such as searching for seat 22 and changing it's fill color. Of course you can also scroll, zoom, print, save to a variety of formats and more.
I am working in C#. I find myself creating dialogs for editing my application settings all the time. For every Control on the dialog I am reading the configuration file and set it accordingly. After pressing OK, I am reading all the controls and store the values in the configuration files or something similar again.
This seems to be very time consuming, simple and repetitive. Does anybody have an idea how to simplify this process? Code generation? Helper classes?
You can bind WinForms controls directly to application settings, which should make your life a lot easier for creating dialogs to manage them.
Just select a control and look for the (Application Settings) option under the Data group in the properties pane. I put up a screenshot here to illustrate.
Do these application settings dialogs need to be pretty or are they simply there for personal configuration? If it's the latter, read all the settings into a class and assign that class to a property editor.
Not recommended for a good-looking, final UI though.
Best bet would be to use the "Settings" that are included in the default template for a winforms rather than "configuration" it is easier and the settings can be bound to just about any property for a control or read independently. Once discovered they are well documented, easy to customise and easy to use.
If you need to use configuration then I'd look at using a custom configuration section and bind that to a property grid or control set for editing. The configuration makes it easy to read and write changes to the configuration.