I have made a FormBase, from which I inherit a FomBaseList and a FormBaseDetail.
All other forms in the project are derived from FormBaseList or FormBaseDetail.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs with the value found in FormBaseList.Designer.cs.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
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 am studying Silverlight (mainly for Windows Phone Development). I read Silverlight 2 Unleashed and currently reading Silverlight 4 unleashed. The latter has a chapter on dependency property. As I got from this chapter is that dependency object (with dependency properties) is used for UI control objects to support animation and data binding systems. Ok. That's clear.
Now, as the chapter goes on, the attached property is discussed. The main reason to use it (as stated in the book as well as on the internet) is to prevent making subclass and add attached properties to the object in concern. And since attached properties are already dependency properties, attached behaviour is added too.
The question now: what do I have to do that? What's wrong with subclassing? and really, why there is alot of code when dealing with attached property?
The question now: what do I have to do that?
Let's look at a great example - layout.
Take the Grid class. If we wanted to support this, every control would need to have a GridRow and GridColumn property. However, attached properties allow us to attach Grid.Row to any control, which in turn allows the Grid to layout that control within itself properly.
Attached properties all work in this basic way - they allow you to "attach" something that defines or helps some behavioral feature work properly without changing the "something" itself.
I downloaded a project off codeproject and was messing around with it (I am more an asp.net developer) when I noticed these overlay icons...the lock one on the label is really interesting as when I right click the control is unlocked yet all the properties are grayed out. When I add a new label I do not have that lock icon when I select it. What is this? Also what is the double boxes icon (the other 8 that are highlighted)?
The Winforms designer observes standard .NET accessibility keywords. The Modifiers keyword for a control is what counts here. That sets the access keyword for the member variable. The default for a C# project is private, for a VB.NET project it is Friend. VB.NET is more friendly about it.
That matters when you derive a form from a base form, Project + Add New Item, Windows Forms node, Inherited Form item template. The derived form will have the controls of the base form but they cannot be changed if their Modifiers property is Private. The designer makes it obvious by displaying the lock icon. And by displaying the properties of the control in gray text.
Normally this means that the controls are defined in the base control and so you cannot change them in the derived control (so they are all locked).
I’ve met strange behaviour for WPF design-time in Visual Studio 2010: after an instance of the Popup class was created, and I switched the code tab in Visual Studio to a different file, the Popup still remains on the screen!
I have a piece of code, which allows to reproduce this, but I am not sure if I should paste it here (it's not so short), so maybe I'll just give a link to it: here.
For unknown reasons beyond mere mortals' comprehension, Microsoft has decided this is the default behavior of the Popup class in WPF. You have to implement the "hiding" logic yourself. I suggest handling the Window.LocationChanged, Window.Activated and Window.Deactivated events of the Window containing the Popup and close it yourself.
Edit: To clarify myself, the Window events you need to handle are the events of the window that contains the Popup's PlacementTarget element. Usually when you create a popup, you set it relative to some element contained in an application's Window (similar to how the tooltips work). If this is your case, then my solution is correct, but I forgot to mention this point about the PlacementTarget.
In your code behind; you can simple check this boolean:
DesignerProperties.GetIsInDesignMode(this);
"this" represent the object containing the popup. For example the Window.
If true you can say:
myPopUp.IsOpen = false;
For Store Apps/WinRT:
Windows.ApplicationModel.DesignMode.DesignModeEnabled
I have a following requirement for a very complex UI. (Complex here means there are lot of controls in the form [approximately 100]). I am using MVVM (if my problem requires it to slightly go away from MVVM I am ok with it)
My question is for Editable ComboBox and TextBox. But I would say I like to hear a common algorithm which will fit all controls.
Requirement 1 : The user edits the content and goes to next control, the color of the control/text should become red.
Requirement 2 : When the user comes back to the previously edited control and enters the value which was initially present, the color of the control/text should become back to black.
I know the requirement is tough and I have been breaking my head to design a generic algorithm using which I can store the previous value and call a function to change the color of control.
To just give you all an idea, --> I tried storing 2 properties for every TextBox like Default_Text and Text. But since the number of properties are huge, the memory footprint is very huge. Also maintaining so many properties is very tough.
--> I tried adding a Dictionary to every ViewModel to store what values have got changed. But here the problem I faced was giving unique keys to all the controls in my application, which is not very helpful
--> I had even thought and tried about subclassing controls like TextBox, ComboBox and overriding some methods to suit my requirement, but sadly I failed miserabley when I started adding validations and all.
So here I am stuck with designing a generic WPF property system/algorithm to handle all undo redo functionality, changing styles of controls,etc!!!
It will be really great if you experts can guide me in right direction and also help me in developing such an algorithm/system. A sample illustration will be nice though!!!
I found an answer to the above problem. I used attached behavior for this. More details on this link Function call from XAML from StackOverFlow.
When I databind, I store the initial value of the DataBound variable in the Tag property by using Binding=OneWay. Then I have written a attached behaviour for LostFocus event. Whenever the user enters a control and then goes to other control, it fires LostFocus event and calls my attached behaviour. In this, I check whether the value is equal to the value in Tag. If it is same, I display in black else I display in red.
Attached Behaviour rocks in WPF. I can achieve anything from that cleanly without code cluttering!!!!
Another alternative is to use some "dirty" tracking in your models (or viewmodels) and bind to a properties isdirty (and convert it to a color).