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.
Related
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
You know, like in CCleaner app where main activity is on the left side of the app and the right side area is changeable fragment.
http://cache.filehippo.com/img/ex/3049__ccleaner1.png
How to do it? I imagine I could do it by putting all fragments in the same place and just change their visibility to show just 1 at the moment, but that would make the code a whole lot of mess.
I've done this in the past by using UserControls. It's worked nicely for things like choosing payment methods (cash, cc, cheque...).
There are a couple of options for changing the display, either have all the UserControls present on the form and hide or show them as required or have an empty placeholder panel and use a factory to construct the appropriate UserControl as needed. I've done both and it really depends on the complexity (and expected longevity and users) of the project as to which is appropriate.
Using a Model-View-Presenter pattern helped with managing all of this.
What you don't want to end up with is a massive switch statement that changes the visibility of dozens of manually positioned controls individually. I've seen it and that way lies madness.
I have inherited a large MFC application which contains a CComboBox subclass that overrides OnPaint. Currently it does all its drawing by hand (with lines and rectangles), and renders a combo box that looks decidedly Windows 98-style. However, it otherwise works great and provides a lot of useful custom functionality that we rely on, and rewriting the entire control is probably not an option.
I would like to modernize it so that the OnPaint draws in Aero style where available (falling back to the old code when modern theming is unavailable). I've done this with some other custom controls we have, like buttons, and it works great for our purposes. I know there are some tiny behaviors that it won't get right, like gentle highlights on mouse-hover, but that's not a big deal for this app.
I have access to the CVisualStylesXP ckass, so I've already got the infrastructure to make calls like OpenThemeData, GetThemeColor or DrawThemeBackground pretty easily (via LoadLibrary so we don't force Vista as a min-system). Unfortunately, I don't know the proper sequence of calls to get a nice looking combo box with the theme-appropriate border and drop-down button.
Anyone know what to do here?
Honestly, I don't know why they originally tried to override OnPaint. Is there a good reason? I'm thinking that at least 99% of the time you are just going to want to override the drawing of the items in the ComboBox. For that, you can override DrawItem, MeasureItem, and CompareItem in a derived combo box to get the functionality you want. In that case, the OS will draw the non-user content specific to each OS correctly.
I think you best shot without diving in the depth of xp theming and various system metrics is take a look at this project: http://www.codeproject.com/Articles/2584/AdvComboBox-Version-2-1
Check the OnPaint of the CAdvComboBox class - there is a full implementation of the control repainting including xp theme related issues.
Not sure if it's the same situation - but when I faced this problem (in my case with subclassed CButtons), solving it only required changing the control declaration to a pointer and creating the control dynamically.
Let's assume that your subclassed control is called CComboBoxExt.
Where you had
CComboBoxExt m_cComboBoxExt;
You'll now have
CComboBoxExt* m_pcComboBoxExt;
And on the OnInitDialog of the window where the control is placed, you create it using
m_pcComboBoxExt = new CComboBoxExt();
m_pcComboBoxExt->Create(...)
Since this is now a pointer, don't forget to call DestroyWindow() and delete the pointer on termination.
This solved my particular problem - if your control is declared in the same way, consider giving it a try.
I need to modify the way the filter acts in the Silverlight Pivot viewer.
I have this filter:
Keywords:
x Keyword a
_ Keyword b
x Keyword c
_ Keyword d
_ Keyword e
The filter generates “Keyword a OR Keyword c”. What I need is “Keyword a AND Keyword c”.
Is that possible?
Any help is appreciated!
What Poker Villain says is quite right but that doesn't mean the PivotViewer is not a solution for you. I had a similar problem with a system I've been working on and managed to find a suitable way of making the PivotViewer play nice. This will only work for JIT collections though since it relies on re-fetching the data.
Essentially the system I've been working on is a case management system. Much of the data associated with a case is mutually exclusive and so fits the model of the PivotViewer but there is also the ability to add 'tags' to a case and like you suggest, often the user will want to combinational logic there. Here's what I did to fix the problem.
First off,..you're gonna want a copy of Silverlight Spy. Now in the explorer tab of SSpy, you can drill right down the Visual Tree and look at the guts of the PivotViewer. Here's how mine looks...
You can see I've drilled right down into the control named 'PART_FacetPane'. Below that there's a bunch of CustomAccordianItems. Essentially, you just need to subclass the PivotViewer (that's why mine says PivotViewerEx) and override the OnApplyTemplate method.
In here you will be able to use GetTemplateChild or some other means to navigate the VisualTree and add another control yourself. In my project, I used a simple tag cloud control I'd previously built.
What I do is handle the events of the tag cloud control and append querystring values to the URL used to build the CXML and filter the data based on these parameters. It's not as fluid as being able to filter the data 'live' as it were but it's a solution for now.
It's probably worth mentioning that depending on your circumstances, you may need to add a final, randomly generated querystring value to the CXML URL so you don't get a cached copy of the data.
HTH, Stimul8d.
bottom line ... NO.
You get what you get with this control. (for now)
but you could generate a "dummy" facet that was the concatenation of all the keywords for an item. But if you had more than a few keywords, it would look very ugly.
I have found the following in WPF:
I have a form with AllowTransparency=true. Inside the form I put a Combobox.
I add some items to the combobox.
I run this application and click on the combobox. At first it does not seem to appear at all. On closer inspection (after adding more items) I see that it is actually appearing behind the form. If I add enough items it become visible from behind the form.
If I just change AllowTransparency=false, then all is fine.
This looks like a bug in WPF (3.5 SP1).
Any one know of a workaround for this?
Go to
https://connect.microsoft.com/dashboard/?wa=wsignin1.0
submit your feedback after searching #
https://connect.microsoft.com/VisualStudio
https://connect.microsoft.com/VisualStudio/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=1160&FeedbackType=1
and mention steps to reproduce.
There was an update of 3.5sp1 but you could test,but I doubt
http://www.microsoft.com/downloads/details.aspx?familyid=6c095bba-6100-4ec9-9c54-6450b0212565&displaylang=en
AllowTransparency is slow and buggy and shouldn't be used - it's a great way to run into bug in various display drivers.
You can get almost anything you like without using AllowTrasparency, take a look at this post for examples:
http://blogs.msdn.com/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx