I realized that VS gives error when we try to copy paste one of the window. The errors are usually of type the method call is ambiguous between InitializeComponet() or other methods. This is because that VS only renames xaml files but not the assciated CS files. I dont know why VS dont handle that. What is better way to copy paste the existing windows, that will not give any error. Or is their any simple workaround? What all other things we need to manually rename?
The VS renames XAML and the associated CS files as well. What it does not do is change the class name and constructor name in the CS file and the x:Class property in the XAML file. If you change these, this would work fine.
I don't think there is a workaround, but I don't think that it is a lot of work either.
Related
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'm attempting to use a resx file to localize some strings I am using in a XAML file. I've looked around at other documentation on the web, and they all seem to recommend a two part process:
Add a clr-namespace to your window, like this:
xmlns:props="clr-namespace:PJConfiguration.Properties"
Use that namespace to localize your string like this:
Content="{x:Static props:Resources.SharedSettings}"
I've done this, and also made sure that my resource classes are public, but I still get the following error from the XAML in step 2:
Cannot find the type 'Resources'.
Does anyone know what else might be causing this problem? Thanks in advance.
In order to make the Resources visible to XAML, you have to make sure that the code generation mode for the resources is set to public. In VS, you find that setting in a ComboBox near the top of the Resources designer window.
For more information on using .Net resources in XAML, you might want to refer to these blog posts: http://wpfglue.wordpress.com/category/localization/
Check if your .resx file is the default Resources.resx file inside the Properties directory of the Application assembly. If that is, there is no reason XAML couldn't find the public class Resources from the correct namespace under local assembly.
Try to specify the assembly name in Step 2 as recommended in this answer.
I previously had a subfolder in my WPF application project called "Controls". It contained a WPF user control. I decided to move that user control to my "Views" folder. Since the original folder was empty, I decided to delete it from the project.
Because the user control and folder is removed I receive a compilation error because the user control used the ProjectName.Folder namespace and now nothing references it. MainWindow.g.cs is what references ProjectName.Controls in a using statement.
I know that *.g.cs are generated by VS and can't be edited because it will be overwritten. What do I do to not allow that namespace to be written to the g.cs file? I tried cleaning my solution/project and rebuilding but nothing has worked.
I had a local reference to the Controls namespace in my Xaml code (MainWindow.xaml). I removed the reference, cleaned the project and produced a successful build.
In your user control file,
In your ClassName.xaml, you must change the namespace as shown below
<UserControl
x:Class="YourOldNamespace.ClassName"
...
...
/>
And in your ClassName.xaml.cs, you must change the namespace as shown below
using System;
using System.Windows;
namespace YourOldNamespace{
public class ClassName{ ....
}
In both the files, you must replace YourOldNamespace to some new namespace as needed.
I have had problems with g.cs files in my projects before too. Since they are auto generated, I tend to just delete the file manually and rebuild.
Dont forget too, that you must check to see if the Build Action property when you click on the affected XAML file is set to PAGE (instead of resource). This is useful to know when you copy a XAML from another project using copy-paste to save time.
Also look at App.xaml and all of your resource dictionaries. For whatever reason, VS 2012's replace in files / "Entire Solution" option didn't find the old namespace reference in App.xaml, had to manually change that. Fixed it for me.
Don't forget to change your Generic.xaml file too,
<ResourceDictionary
xmlns:local="clr-namespace:MyOldNameSpace">
</ResourceDictionary>
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.
I'm learning WPF.
I want to provide my own Main method in my App.xaml.cs rather than getting one generated for me in App.g.cs. However I keep getting conflicts because I haven't found out how to stop an additional Main from being generated.
Is there a setting in my project file or elsewhere that controls this?
I found the answer here. http://learnwpf.com/post/2007/12/13/How-can-I-provide-my-own-Main%28%29-method-in-my-WPF-application.aspx
It is:
The way WPF knows to create the Main() method for a particular xaml file is through the build action property set for App.xaml - it has a build action of ApplicationDefinition. By changing this to Page WPF won't create the Main method and you can provide your own in a regular class file you add to the project.
However in the comments to the above blog, a comment notes there may be issues with blend and it references: http://blogs.msdn.com/expression/archive/2008/04/09/creating-a-wpf-blend-project-that-loads-resources-in-code.aspx . I don't fully understand the issues yet.
You can also just create a separate class (for example, Entry) which is responsible for bootstrapping your application. Then go to project settings and set your startup object to Entry. That way you don't even have to disable the autogenerated method.
The easiest way is to set the Build Action in the Properties window from ApplicationDefinition to Page for App.Xaml.
Then you can define your own entry point.
I found a solution:
Copy the data from your app.xaml file
Delete app.xaml file and re-create with the same name
Create `main` method in .cs file, and paste your old copied code into it
One way is to forgo defining an Application-derived class in XAML, so you can manually define the Main method with your custom requirement
The Easy way just create a class like Startup.cs with build action to compile
and remove ApplicationDefinition from App.xaml convert that to page
and remove it from any other file in the application