This might be a very newbie question (coming from a newbie) but I had some problems regarding the namespace. I've created a User Interface in Visual Studio and gave it a test name to start off and learn how to use the program and the programming language. I kept building and building my UI and now I'm at the point that I'm actually pretty satisfied with my work (and this community's help!). So I decided to change the name of the file from "Test" to something more relevant for my work.
Yet, unfortunately, I ran into some problems regarding the change of the Namespace. I know there are a lot of tabs where it needs to be changed, but I was wondering if there is an easy way to change the file name/namespace of the UI?
Thank you in andvance for replying and taking the time to explain this newbie what to do without breaking his UI ;)
Use tool like Resharper, it will do it for you automatically and safely.
With Keyboard shortcut:
Put the keyboard cursor to the namespace, press Ctrl + R + R and set the new name. It will change the namespace inside XAML as well.
With Mouse:
Right mouse click on the name space, click Refactor > Rename.
When renaming classes and variables there is the lightbulb-menu (Ctrl + .) in witch you can give Visual Studio the instruction to Change it for you. But this will not work with Xaml.
Visual Studio will not change Namespaces as far as I'm concerned. But you can still compile and look at the "Namespace not found"-Errors to change them manually.
As Yohanes Nurcahyo said there is ReSharper but only has a free Trial of 30 days.
Related
It happened again. My test data is not shown any more. I see only class and property names. Restarting does not help this time. Retracing neither.
I've been rewriting my whole project since that happened.
Now I tried to use Test Data class to address it from custom user controls so it would look like:
...d:DataContext="{Binding Source={DynamicResource TestData}, Path=Emploee}"...
//in resources
<main:TestData x:Key="TestData"/>
Not like it was previously:
...d:DataContext="{DynamicResource TestEmploee}"...
//in resources:
<shar:PVEmploee x:Key="TestEmploee" Name="Alpha" Surname="Omega" Phone="77777777" PVProfession="{DynamicResource TestProfession}"/>
<shar:PVProfession x:Key="TestProfession" Name="Some obnoxeously long profession name"/>
And right after those changes in this control (I've done it previously few times already to other controls, I've copied from previous project version) the designer crashed. Now I see
this ridiculousness, instead of test data
I am frustrated. Am I supposed to restart it again? Or there could be some way to fix it.
Answer to almost not realated question Actually worked well (the question was - how to crash a Designer =D ). If I kill designer in Task Manager, and click 2nd option in Studio. The Designer loads pretty well in a right way. All my Test Data right there. Or I found later that I can click small document icon on designer bottom to reload it with or without user code.
After a few such resets it started behaving. Marvelous!
I wanted to use a NumericUpDown box with custom text in my form, so I followed the solution outlined here. The code compiles and run perfectly!
However, I can no longer view my form in Designer mode to adjust the UI, etc. When I try to, MSVC2008 complains that it "Could not find type 'NumericUpDownEx'. Please make sure that the assembly that contains this type is referenced. If this type is part of your development project, make sure that the project has been successfully built."
My code is exactly the referenced solution's (as my initial test) and the only other change I have made otherwise is tweaking the InitializeComponent method slightly so it reads
this->nudData = gcnew NumericUpDownEx();
instead of
this->nudData = gcnew System::Windows::Forms::NumericUpDown();
Any help would greatly appreciated! ...making UI by code alone really sucks...
Well, I managed to make it work. I needed to specify the full namespace name of my new, extended control:
this->nudData = gcnew MyProject::NumericUpDownEx();
And that's it! Might just be a quirk of this old version of Visual Studio?
I work with a lot of floating-point images, and would find it extremely useful to have an image-based representation of my arrays. I'd like to create a WPF UserControl that renders the data array (as shown below) as an image, instead of a scrollable list of text values.
Is this possible? I have looked at the MDSN documentation on VS 2010 extensibility, at SO's list of VS 2010 extensions, and at this topic on creating a custom editor, but I'm a bit lost on where to start.
Update 1:
Thanks to Brian and Basarat Ali for the leads on DebuggerVisualizer. Looks like the correct strategy, EXCEPT that unfortunately a visualizer for any type of arrays is disallowed.
A work-around (of limited utility) is to visualize a wrapper object.
At Brian's suggestion, I have posted a solution on CodePlex:
VS2010 Debugger Visualizers Contrib (http://debuggervisualizers.codeplex.com/).
The project's source code demonstrates a working wrapper visualizer and a non-functional "raw" data visualizer for a 1D double[] array. Here's a screenshot of the test console running:
If anyone has any suggestions on how to work-around this problem, please let me know!
Also, any explanation of why System.Array cannot be visualized is welcome!
Update 2:
I just re-searched SO with the word DebuggerVisualizer, and find this to be previously asked. Looks like user Will Dean suggests implementing Project Mole's work-around using a WeakReference. Don't see how this would work in a DebuggerVisualizer, though.
Update 3:
Josh Smith of Project Mole just suggested a very helpful work around (thanks Josh!):
Note, you can use your ArrayWrapper approach without needing to modify your source code to open a visualizer. You can type this into the Watch window in VS:
new YourNamespace.ArrayWrapper(myArray);
Hit the Enter key, then you should see a magnifying glass icon in the Watch window next to that line of code. Click it to open your custom visualizer.
You should create a debugger visualizer. Here's a walkthrough : http://msdn.microsoft.com/en-us/library/ms164759.aspx . I believe that what you want is to be able to view all the results in an external program. For this you can just add an export option to you list to export as a csv file. However if you still feel you want a bitmap you can convert the list to an image using RenderTargetBitmap : http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.rendertargetbitmap.aspx
Since this is for runtime information in the debugger, you might consider a DebuggerVisualizer rather than an editor extension. There are some trade-offs, I am unclear which would be best for this.
(In any case, I think it is possible, and it does look useful, and I hope someone with a spare weekend hacks one out and posts the source code.)
Currently in my XAML editor view I am experiencing frequent seizing episodes of around 3 seconds each. I've been able to narrow down the reason for it to custom namespaces.
By default, my page has the 2 default XMLNS declarations:
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</Page>
This works fine, no seizing. However as soon as I add an XMLNS for controls inside my application it starts seizing up.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:controls="clr-namespace:MyNamespace.Controls">
</Page>
Its not specific to just that namespace. I've tried a large variety of namespace combinations. Basically any XMLNS pointing to one of MY namespaces causes this issue.
I'm not really sure how to diagnose this issue. Any pointers?
SOLUTION
We found out the solution. We had a reference to a Microsoft assembly that was about 7mb in size (ACtiveX stuff for web browsers). When removed, everything sped up. We're now looking at ways to abstract that assembly so that it can exist in the runtime folder but no need for a reference to it from the project. Thanks all for your ideas.
First of all we should find out what happens when you close quote mark inside Visual Studio. It's just a program (although a good one) - debug it/profile it.
Do you have any additional plug-ins
installed? Turn them off.
Turn off Intellisense.
What happens with MS Expression Blend? Does it seize?
Turn off all antiviruses.
Run Process Monitor and track what happens with VS. Are there any errors with file name/registry keys resolution?
If nothing helped, use profiler on Visual Studio process.
If nothing helped, write your question on StackOverflow. Oh. Hold on. You did this already. Let's wait for more responses :)!
Cheers!
This could be that it is looking for something or that it is recompiling code.
Select the output tag to view compile activity, then see if that is what it is doing next time it siezes up.
In some projects we get this behaviour if we exit debug mode by pressing the stop debug button instead of exiting the program.
Also, there have been several bugs reported for Visual Studio hanging when using DataGrid controls with WPF, it could be related to this. Here are a couple:
http://wpf.codeplex.com/WorkItem/View.aspx?WorkItemId=10542
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=420621
Are you running a real-time virus scanner? These can often cause sluggish performance when VS needs to compile your code...
A plausible guess is that this behavior is tied to VS's XAML editor attempt to provide Intellisense for nodes declared with clr-namespace. This is after all one of the differences between clr-namespaces and other types of namespace (whereby the URI is merely taken as a unique string, but no attempt is done to assert the definition of the underlying XML language.)
A possible workaround is too define the xmlns prefix under a bogus URI, during the xaml editing phase (and hence forgo any hints from intellisense), and to revert to the proper clr-namespace for other phases of the project.
Also, maybe adding the assembly=xxxx to the namespace declaration may help the situation. Even if the assembly in question is that of the current application, this may save the editor and associated intellisense some hesitation.
Another, counter intuitive workaround could be to have these controls in a separate assembly, as this may spare the system from the Intellisense's attempts at dynamically inferring the types structure from the source code, with all the associated hickups caused for example by the background polling for changes etc. (I do not know that it tries to do that, but sometimes, tools are getting to be quite intelligent, but too result in CPU or I/O blocks of the kind you describe.
I have created a class that is simply THIS
Class UserControlBase
Inherits UserControl
End Class
Then I changed the Inherits clause in each of my UserControls designer file to
Inherits UserControlBase
I know that generally you shouldn't manually mod the designer file. But in cases like this what else can you do? Is this OK? Is there a best practice I don't know about? Is there some other way to accomplish the same end (extending UserControl) ?
I have not had issue changing the Inherits line, adding Namespacing, or adding Imports/Using statements. If you need to do any of these 3, you won't find many other ways to handle these requirements.
I change them all the time in my C# projects... often it's the easiest way to duplicate something that you've done once in the designer to a similar form and you want to do the same thing in a different form. Visual Studio is perfectly capable of reading in your changes and incorporating it into the designer. I really don't know why there is a comment saying not to edit it. My advice would be just make sure you use source control, go ahead and edit it, test it well, and if it works, great, if not you can always back out your edits.
No. It's never a good idea to modify a file that's generated.
The Designer files are pretty simple code; the only thing that you'll typically find in there to complicate matters (but only slightly) is BeginInit/EndInit calls at the top and bottom of the file--between those the code is pretty forgiving.
*That said, do not put any code in there that will only execute at Runtime. Any runtime-dependant code will fail at design-time, so trying to open your control in Design view will blow chunks. It used to give you the Red Screen of Darn, but I'm not sure what effect the IDE has notwadays--but if things blow up and the usual tricks fail to remedy them then try removing your customized sections.
Further on that note (not to scare you, but rather to hopefully head off some of the difficulties we had) the means of determining if your code is executing in Runtime or Designtime often fail if your code is not part of the currently built solution/project.
So to bring it all home, simple UI layout/winforms modifications are perfectly fine to do by hand in the designer code. Databinding and external dependencies (with the exception of calling third party control libraries) should be cautiously approached.