in windows form i create a base form and inherit all my forms from that base one .
then with this way i can share all my property , function and variable that i want be in all forms . also this object oriented way help me to change all form fast with just change my base form
now i want know how can i do some thing like this in WPF
i handle share function with a public static class but i search for better way ...
You can use a class without design mode (xaml).
check this out
site reference
Related
I need to enhance one legacy WinForms app to support the inheritance of the TextRenderingHint setting in the app forms.
For simplicity, let's suppose that we have a main form with the TextRenderingHint property of the System.Drawing.Text.TextRenderingHint type. This property specifies the text quality in the main form and must be inherited in dialog forms called from this main form. The text in the main form is drawn using Graphics.DrawString method, and there is no problem to support various settings of the main form's TextRenderingHint property (in fact, it is simply assigned to Graphics.TextRenderingHint before drawing text with Graphics.DrawString).
The problem is that the interface of one of the dialogs is based on the WinForms ToolStrip component and I need to redefine text drawing in its items to support the TextRenderingHint setting of the main form.
After searching the Internet and analyzing the source code of the ToolStripRenderer class in a reflector app, I came to the conclusion that the best way to implement what I need is to use a custom ToolStrip renderer with the redefined OnRenderItemText method.
I found the following code in the default implementation of the OnRenderItemText method in the ToolStripRenderer class (see the full code at the bottom of my question):
graphics2.TextRenderingHint = TextRenderingHint.AntiAlias
TextRenderer.DrawText(graphics2, text, textFont, New Rectangle(Point.Empty, size), color, textFormat)
, which gave me an idea that I could try to solve my problem with this simple implementation of OnRenderItemText in a class derived from ToolStripRenderer:
Protected Overrides Sub OnRenderItemText(e As ToolStripItemTextRenderEventArgs)
e.Graphics.TextRenderingHint = _MainFormTextRenderingHint
MyBase.OnRenderItemText(e)
End Sub
My idea is based on the fact that if we do not use vertical text in ToolStrip items (we don't), the basic OnRenderItemText method "just" calls TextRenderer.DrawText and theoretically my idea could work. Unfortunately, in practice this works only for the TextRenderingHint.ClearTypeGridFit option - at least, on my dev pc.
The only viable idea I see now is complete rewriting of OnRenderItemText and using Graphics.DrawString inside. Am I right? Are there other solutions to my problem?
UPDATE #1. I encountered a problem trying to reimplement OnRenderItemText based on Graphics.DrawString. It seems, it's impossible to convert text format flags passed to TextRenderer.DrawText (the TextFormatFlags enumeration) to the StringFormatClass parameter Graphics.DrawString expects...
UPDATE #2. The default implementation of the OnRenderItemText method in the ToolStripRenderer class is the following:
I'm developing a WPF application that contains a lot of forms (about 20 different forms)
each form is connected to a ViewModel class that usually hold a single object that the form is editing its properties.
I need to give a graphical sign to the user if he changed something like in Word when you edited the document and it tells you need to save it.
If the user edited even one property I need to show that sign.
Is there a simple way to accomplish that? I don't want to create an event for every property editor I have (there are more than 300 of them).
Why not use INotifyPropertyChanged?!
Since you are using WPF, you can opt for SourceTrigger to Property Changed.
Check here, http://www.codeproject.com/Articles/15822/Bind-Better-with-INotifyPropertyChanged to know about using INotifyPropertyChanged.
I'm writing a WPF application while mostly adhering to the MVVM design pattern. The application has various educational modules broken up into different categories to be accomplished by the user. The modules are organized into a hierarchical menu. My ViewModel has a class called MenuPageViewModel which exposes the information needed to render a MenuNode. Naturally, the terminal elements in the menu tree have content that I'd like to display to the user. This content can be one of many different types of modules. Currently, when the user selects a module in the menu, I can't see any way around using a large conditional block to determine what type of ViewModel I'd like to return to be displayed based on the type of the MenuItem's Content Property. For example...
if (CurrentlySelectedMenuItem.Content is Lesson)
return new LessonViewModel(CurrentlySelectedMenuItem.Content as Lesson);
if (CurrentlySelectedMenuItem.Content is SkillsCheck)
return new SkillsCheckViewModel(CurrentlySelectedMenuItem.Content as SkillsCheck);
Can someone give me a hint to a more elegant and maintainable approach? Right now, if I add a new module type, I have to remember to update this conditional block, and that just sort of annoys me.
Thanks.
If you are using Unity/Prism then using the container to resolve the object would be my first preference.
_container.Resolve(Type.GetType(strObjectType)) as BaseViewModel;
where strObjectType is a string with the type of class you want to create (eg "LessionViewModel" )
if you are not using Unity, then reflection works
Activator.CreateInstance(strObjectType) as BaseViewModel;
with both solutions you need to have the string with the class type on your menuItem.
A third option is to have a factory, but it would probably end up having a conditional situation within it or will contain the code i just listed.
Say I have a WinForm CRUD(like) application. I want to follow best practices on this so I try and make it follow OOP and a n-Tiered design.
Unfortunately I am familar with the words but not the practice of them. So lets go with the following example: My CaseNote program. I have a tabbed application where you go to the search tab to find a member and then one of the options is to go to the CaseNote tab to create a new case note, look at existing CaseNotes, or create a follow up CaseNote to a Parent Note. All of this is for the member you selected from the search tab.
So if I am creating objects and passing them around to be used by different forms where should I be instantiating them? I had thought I would have 3 layers; UI, Object, DAL. Where I fall flat is where I instance tho objects. I can't instance them in the object layer, can I? Also, if I instance them on the form how do I pass them from form to form in a quite large app?
CaseNotes Screen Shot
If you want to look at some more words around this problem you want to look at MVP and MVC. (These stand for Model View Controller and Model View Presenter). Some people will shoot me down for saying this but they are quite similar in concept.
The aim of MVP and MVC is to allow you to design your application logic without even having to think about your application apperance. It also allows you to define your user interactions without implementing an actual GUI. Esentially your model is your application logic, your data, your classes which actually do stuff like talk to your database. Your presenter or controller is what interacts with your model and what controls your user interface and reacts to user operations on the interface. Finally your View is your winforms design or your web page.
I'm sure you will be able to find plenty of material on the web about this but to give you some concrete help with this problem should serve to inform and illustrate your reading.
The first thing you need to do is start creating your objects that represent your data. So you will have a CaseNote object which is contains the casenote data. You will have a case note data container of some sort such as a case note database. You can define the logical operations and properties of these as if they where real items.
Then you would move on to define your presenter or controller which will define the operations that you want to support from the GUI. At the same time you should define an Interface that will define for the presenter/controller what operations is can perform on the GUI. So for instance your presenter may expose a method called SearchForCaseNote which takes a string parameter. Your view Interface will expose a method called DisplayCaseNote. When a user clicks on the search button the view will pass through the command to the presenter which will then call the model to get the data. The presenter may format the data at this point, i.e. convert DateTime object to a string and then pass the data back to the view through the interface define method called DisplayCaseNote.
You don't have to use the View interface, you could call into the view directly, but having the interface means you can have many different view implementations.
One last thing i need to mention is where you create these different parts of your application. My view is everything thing should fall out from the presenter/controller. So when you application starts it creates the presenter/controller object which then create and displays your view passing itself as a variable to the view. The presenter/controller can then either create the initial models by loading them from disk or ideally discover them through a dependency injection container like unity. In fact using unity to discover the view implementation is probably a better idea again as it gives you true seperation between view and presenter/controller. When you come to move to another view, (i.e. open another window), your presenter/controller should expose a method such as DisplayDetailPage which the view calls when a button is clicked. This would create the presenter/controller for the next view which would in turn create the view and get a reference to the model.
Hope this helps.
I think you should use the RocketFramework
The situation: MainForm (assigned to the MainPresenter) is up and running. The user click a ShowFoo button - an event is passed to the MainPresenter which in turn creates new FooPresenter and the FooView. How should I proceed now ? Where should the presenter be created and where should the view be created and most importantly, where should the MDIParent property be set ? (so fat I kind of think that should be done in the main view.
Notes: I am using a dependency framework, though that is quite irrelevant to the problem. Ideally I would like the IView to independent of the Form class.
The way I would handle it have a function off of the MainPresenter interface that allows me to create a FooPresenter (as well as a Foo2Presenter, etc). THe MainPresenter has all the information inside of it to properly setup a child form of the MDI parent. Hence why it makes sense to have it there.
An alternative is to have a AppPresenters class that has the MainPresenter and the FooPresenter as properties or functions. Here the AppPresenters hold the presenter classes as well takes on the responsibility for tying the forms together to have a proper MDI application. The implication of this approach is the fact the application is a master/parent form with a bunch of child forms is not reflected in the design of your interfaces.
The differences between the two approaches is minimal in my opinion. Both could be adapted to a different style of UI readily. So go which on makes better sense for you and your application.