I am experiencing some very strange behavior with Blend:
Since weeks i am working an a project where I use Blend 4 and Visual Studio 2010 simultaneously. I've never experienced problems with one of these programs or with their co-existence. Work proceeds fine.
But a few minutes ago - from one boot of the computer to the next - Blend seems to have a serious problem:
From now on I am not able alter any value anywhere in my project. I can't create new Controls on a plain surface as well delete existing ones. If i try to alter some attribute of some existing control, the width of an existing button for example nothing happens:
Drag and Drop with the mouse results in nothing more than a slight flickering of the control which looks like if it is fighting against my modification to retain its current value. Regardless what manipulation I apply with the mouse the control stays untouched neither does any value in the properties-panel of Blend change.
It feels as if my project is in read-only mode or locked somehow.
But now comes the frustrating fact: When I apply the modifications described above nothing changes BUT the corresponding XAML code does! Enlarging the width of a button with the mouse doesn't show any effect at the control itself or in the properties pane but the XAML attribute width is changing as I move the mouse ?!
Did anybody also experience this behavior before ? Does anyone has some suggestions ? Maybe the solution is very obvious and just made a fool of myself but I got really stuck with that problem - so any help or suggestions are very much appreciated ... Thanks in advance !
EDIT: It really seems to be a Blend problem because when I open the project in Visual Studio everything is working as it should ...
Are you certain that there is not a control sitting on top of the others?
Alternatively, are your other controls in a panel (perhaps a grid) that has it's visibility set in a trigger? If so, Visual Studio displays controls visibility a little differently than Blend does. Blend attempts to get the property to which you bound your visibility during design time, whereas Visual Studio seems to display the item so long as you have visibility initially set to visible.
Can we see some code to make sure?
Related
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've been recursively refining a UI with visual Studio 2008, and I seem to have lost a control underneath the myriad layers of other controls. the project is checked into our version control software (I check in after I make a substantial enough change - for instance moving something around on or adding to the UI, or adding a method).
The refining of the UI has come directly from the boss, and he loves to move things around as we're discussing any changes that need to be made - which isn't that bad, I suppose. I check in before he starts faffing, and write down everything he does (in case we need to re-create it), then if nothing major has changed check the UI out again.
I suppose that I should mention that I'm using .Net 3.5 (because we can't upgrade to VS2010, yet) and C#, with a few custom controls (but most of them are the built-in .NET ones).
Somewhere down the line, I've lost a text box control. It's still listed in the Form properties window, and I can still select it from there. But when I look over at the form, there doesn't seem to be anything highlighted.
I've moved most of the controls around (where possible, as some of them are docked to sides of the form, or each other. Bad UI design, I know. But that's how the boss wanted it) and re-ordered them (send to back/front), and can get all the way back down to the background of the form (in most places). But I still can't find it.
At this point, I'm inclined to delete/remove the control from the form and start again with it rather than find it and move it into the new position. But, since I can't seem to find it, I'm not sure if I can.
Is it possible to delete the control in some way other than selecting it and hitting the delete key? I'd rather not have to jump back to an older version of the UI as I've made that many small changes, recently (and checked in after each one) and I have no idea when this text box got lost.
EDIT:
In case it's useful, here are some of the properties of the text box control:
Size: 356, 0
Location: 1, 1
Multiline: True
Text:
Dock: Fill
I've added text to the text property, and moved everything again and still can't find it. I've also been messing around with the Dock property in an effort to move it around the form to make it easier to find.
Also, most of the UI uses group boxes and panels, as I've found it easier to hide and disable/show and enable groups of controls as and when needed that way.
EDIT 2:
The text boxes properties are now (based on some helpful suggestions in the answers):
Size: 356, 150
Location: 150, 150
Dock: None
Multiline: True
Text: "Where are you?"
There may be few issue. Try these.
If u using team server along studio then u can right click the pending changes and see with older version where u see the changes done by previous vs current so u know want went wrong.
The control property visibility set to true. I.e: textbox1.visibility= true;
If the control is docked to fill then it wraps the other control under it. So try playin with the control properties.
Well, it has a height of 0 (Size: 356, 0). Change that to something meaningful and you will start seeing the control again.
I'm encountering a problem with the WinForm designer. I made a new UserControl, I added a DataGridView, some other elements and a TreeView. With the gui I named all those new components. Now it's time to code that stuff and I realise that the designer missnamed my node of my TreeView. The Designer also added new columns from my DataSource even if it was set to AutoGenerateColumn to false. I though: "Well time to clean some Designer crap again..." and I cleaned that stuff up in the InitializeComponent function (I know it's labeled "Do not modify with the code editor" but... do I have the choise?
Anyway, my problem is : When I go back on the Design view, the VS Designer seems to regenerate the code back but not even how it was. Now the designer declares my DataGridView and my TreeView as local members of InitializeComponent function. I can easily repair and undo my changes but I would like to understand and know if there is a way to disable the auto code generation of the designer.
Also, I tried to make another function which have all what I need so the designer don't screw it up and call it into the initialize component. This solution works at run time but not on Design view. I'm kinda low.
As far as I know, the short answer is no. If something is marked as Do not edit due to code generation., then do not edit it :). I would suggest reading up on partial classes, as that is how you can modify classes without actually messing with the auto generated code. In your case, you will need to go into the designer and fix everything there so that the auto generation works as you expect it to.
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 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