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
I have used Confuserex to obfuscate my code which is using .net 4.5. Post compilation everything seems ok except for the behaviour of combobox (across all winforms i had in the project). The comboboxes are now showing id instead of the values as dropdowns. (Whereas these were running absolutely fine from visual studio in debug mode as well as the builds from the release mode).
In confuserex I have tried setting the preset to Aggressive, Maximum ... but same issue irrespective of whichever preset i use.
Not putting any code here as there is no issue with the code per se. This is most likely a issue in Confuserex.
Is this a known issue and does a solution exists? Please let me know if any further details are required for providing help.
There's no way to give you a singular answer, but perhaps I can steer you in the right direction:
In recently implementing ConfuserEx in a Winforms post-build event, I found that some third party controls were not displaying data correctly, or at all. Like you, I changed the preset from Aggressive to Normal, to no avail. I then went and excluded some of the methods that were binding data from obfuscation. It alleviated the problem in some cases, on a data grid view and list box, specifically. In those controls, I was receiving weird glitches like extra columns, cells rendered blank (with data present in the underlying object), et al.
All bets are off for third party controls with obfuscation - you'll never know if they will play ball or not. Sometimes you'll experience this with .Net controls as well. Obfuscation and Reflection also do not get along. Perhaps check your combo box data bind technique, and lift the obfuscation from the method where it is being populated with data, if nothing else. This is, of course, if you can live with this method being exposed. Here's one way to do it:
[System.Reflection.Obfuscation(Exclude = true)]
public void MethodYouDontWantToObfuscate()
{
//Your method code
}
Until just now I had a similar problem with WPF.
Our comboboxitems were in their own class. To solve the issue I added
[System.Reflection.Obfuscation(Exclude = true)]
in front of the class-declaration (like MoSSBerG suggested) and now everything works like a charm.
I experience strange things when setting the "Language" property in WPF:
Set FlowDirection to "RightToLeft" on a Window or textbox/textblock
Set the Language property to "fa-IR"
Set the text to one of the sample texts below (A, B)
A. This text does not render correctly in WPF 3.5:
فاکس: +44 1908 215040
It works with WinForms and Silverlight. Note that it contains a 'LEFT-TO-RIGHT MARK' (U+200E)
Here is a HTML version of the above with numeric character references to LRM, to visualize where the LRM is inserted:
فاکس: +44 1908 215040
B. This text does render correctly in WPF:
فاکس: +44 1908 210210
But it contains (I believe) unncessary LRM characters. I put together the text in a trial-and-error fashion.
Here is the HTML version with the extra LRM characters
فاکس: +44 1908 215040
Why are the extra characters needed / what am I doing wrong with the original text?
Note: The problem occurs IFF setting the Language property, either explicitly in XAML or code (like Language="fa-IR") or by overriding the default value of the Language property in code (assuming current culture being "fa-IR") as so:
FrameworkElement.LanguageProperty.OverrideMetadata(typeof(FrameworkElement),
new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));
If I leave the language property as en-US, the text renders correctly in WPF, but I really need to set the Language to have value conversions work without having to set the ConverterCulture explicitly on each and every data binding that could be binding to some culture dependent data.
There are also other problems, like LRO ('LEFT-TO-RIGHT OVERRIDE' (U+202D)) being ignored.
I really need help understanding what is going on, as this could turn out to be a show stopper for localizing my application to Persian and Arabic.
I suspect that I am the one doing something wrong, as I fail to google for the problem.
Here is a a related post on MS Connect, but no one has so far confirmed the behaviour as a bug:
http://connect.microsoft.com/WPF/feedback/details/682784/incorrect-unicode-bidi-behaviour#
Note: I am not that familiar with the BiDi algorithm in general and know even less of the actual implementation in WPF. I have a basic understanding of Unicode.
In Silverlight (and probably WPF), when I define a System.Windows.Interactivity.Behavior<T> for e.g. an ItemsControl, like
public class SomeAwesomaticBehavior : Behavior<ItemsControl>
{
}
it will appear in Visual Studio's XAML editor (and probably in the Designer too) even for ordinary, non-Items-Controls and throw nasty runtime exceptions. This is contrary to Attached Properties which will appear only for intended types.
Is there a way to restrict that visibility? Some magic attribute maybe (although that would be a redundant declaration)?
If there is no way today, I hope there will be so in the future? Because it surely does confuse co-workers and designer folks when a lot of Behaviors pop up that don't have anything to do with the current object.
Update: I have filed uservoice items.
Silverlight: http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/1224253-restrict-behavior-visibility?ref=title
WPF: http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions/suggestions/1224259-restrict-behavior-visibility?ref=title
#HeRz you are correct, there is no way to filter behaviors by their targeted type. Blend (and probably vs designer) use reflection to find all of the types you create which inherit from base type Behavior and displays them in the assets list.
Blend will prevent you from dragging a behavior or trigger onto an item which it is not intended. So that should help prevent their misuse.
I usually try to write behaviors as reusable pieces of code, not scoped to a specific case. They are simply tools with specific purposes.
Was talking to a colleague about XAML and how it is both a presentation and object description language and therefore quite unique and novel among IT technology.
Is this true that XAML is unique and novel?
Does XAML have any counterparts or predecessors in the Java world or elsewhere? I believe someone told me that Java Server Faces was similar to WPF, so what is the equivalent of XAML there?
I know MXML in Flex is similar but as far as I can remember there are some major structural differences, from what I remember MXML doesn't really describe objects but is more of a pure presentation XML.
This is a case of a general technology having such an overwhelming common specific usage that becomes synonmous with the specific usage. For example, discussions of Javascript often assume the browser context and the manipulation of a HTML DOM without anyone having to expressly say so.
Strictly speaking XAML is not like XUL or SVG apart from being XML. XUL, SVG have a defined syntax for declaring User interface or graphical elements, raw XAML does not.
XAML can, for example, also be used to describe Workflows in Workflow foundation.
XAML is actually an approach to reading XML in order to describe types and properties of those types. For example, a property of a type may be described either using an attribute or an Element as long as its name can be interpreted correctly. XAML also includes an extension to the basic XML syntax where { } in an attribute can act as a short hand for a complex element.
I've not come across this sort of thing before. All other XML based technologies come with a specific purpose, XAML is the first usage of XML I've seen that is deviod of any specific nomenclature but just a means of mapping XML to types.
****XAML, XUL, and XHTML Overlap****
The greatest overlap between XAML and other standards lies in its support for concepts drawn from HTML/XHTML. The similarities between XAML and HTML are numerous. Overlap with HTML is not limited to XAML, of course. The other well-known XML GUI dialect—Mozilla's XUL—also overlaps with XHTML. Finally, both XAML and XUL overlap in places that XHTML doesn't even include. XHTML and XUL can be combined in one document (at least in Mozilla browsers). Such a combination is a rough analog for non-Web uses of XAML. In fact, Mozilla's XUL alone is a rough analog for some uses of XAML.
but taken together, they really constitute nothing more than support for most of the basic HTML content and form widgets that are already routine in ordinary Web applications. XUL overlaps XHTML less that XAML does because XUL attempts to separate itself from XHTML. It's not trying to be a drop-in replacement, as XAML is.
One thing I do like about XAML compared with HTML is the increased freedom from the publishing-derived features of HTML. XAML frees you from h1 tags, code tags and a host of other miscellaneous niche tags used infrequently in HTML. For practical purposes, these tags act as little more than style information in modern HTML documents.
HTML is also a poor GUI for applications, despite the popularity of the Web. Both XAML and XUL go a long way towards rectifying that problem. You could re-write your Web applications in XAML and they'd look better than the HTML originals, if only XAML had better CSS support.
Read the comparisons to other presentation technologies with a grain of salt - Xaml is a method of constructing and composing .NET objects. That's in stark contrast to other systems that were designed as a way to build user interfaces. The nice thing about Xaml is that it's independent of the technology stack that its used for - it's a purpose-agnostic declaritive language more like C# than XHTML. In that way, it's unique.
Cocoa from Apple, or event earlier NeXtStep had something similar long before XAML.
The GUI is created with an interface builder, which makes so called nib (Nextstep Interface Builder) files, which contains the layout, bindings, actions, outlets and serialized object instances. In the former time these nib files were stored in a binary file format, but nowadays it is also xml (xib).
So XAML is not the first not unique at all.
Besides XAML, you have XUL which is used by Mozilla. SVG on the other hand, is one recommended by W3C.
Mozilla created their UI description language XUL originally to be able to easily customize the UI of all of their products.
Nowadays it's a package which can be included in other applications and also has an extended functionality.
Although XUL mainly focuses on UI representation it also contains other structures as Events and Scripts and Data sources. Nevertheless as far as I know XAML integrates these concepts much tightlier into their .NET (and attached) frameworks. But I'm not sure if this is enough to call it unique and novel.
XAML is an object graph construction language in the dialect of XML (not the greatest choice). Every XAML element is an object instantiation and the corresponding attributes are property assignments on said instance. Since XML is a string based language, property values need to be converted from their string type into whatever type the property expects. This is done using descendants of TypeConverter that the XAML processor locates and utilizes automatically. XAML and WPF come with a default set of TypeConverters corresponding to their provided types and you can provide your own.
A rough overview of the definition process is as follows:
<classG-in-namespace-A
xmlns="namespace-A"
xmlns:alias-B="namespace-B"
xmlns:alias-C="clr-namespace:namespace-C;assembly=assembly-of-namespace-C"
propertyG1="simple text value stipulation"
propertyG2="{alias-C:classH-in-namespace-C propertyC1=valueC1,..}"
>
<classG-in-namespace-A.propertyG2>
<alias-B:class-I-in-namespace-B propertyB1=valueB1,...>
class-I-in-namespace-B's content property value assignment
</alias-B:class-I-in-namespace-B>
</classG-in-namespace-A.propertyG2>
classG-in-namespace-A's content property value assignment
</classG-in-namespace-A>
There are utility types provided by XAML and WPF beyond TypeConverters that facilitate property assignments. In particular, there are the following:
ResourceDictionary,
ObjectDataProvider,
RelativeSource,
StaticResource,
DynamicResource,
...and more as shown in Microsoft Docs
Well, XAML is basically advanced markup for .NET, therefore I think you can draw a lot of parallels from XAML to XHTML - Both being presentation techniques.
There's a lot of differences as well ofc (XHTML being interpreted by a browser to produce graphics, while XAML is being compiled into MSIL and relying on the CLR to do the graphics :) )