I have a project that I built with the old Codename One UI Designer. It has many 'SpanButtons' that I need to change for 'Buttons'. I don't want to have to do this using the Designer tool as it will involve a lot of work. Which files should I manually edit to make the change?
This wouldn't be much simpler with the old designer...
You can migrate to the new GUI builder which will be a lot of work.
Alternatively you can try this but a word of warning you would want to backup everything...
Turn on File -> XML Team Mode then save and close the designer. Open all the relevant .ui files under the res directory and edit them appropriately.
Open the top level XML file of the resource file (usually theme.xml) and set the attribute useXmlUI=true in the top tag.
Finally reopen the res file in the designer and save.
Related
I want to move a big pile of code to a separate project and use it as a framework for where it came from.. and other stuff too.
I started a new vb.net wpf project and started adding files from the old project but when they get added, the wpf and its associated vb file are treated as separate things. What I mean is that when I add a new wpf usercontrol file(or whatever), the vb file gets nested in the xaml file but when adding existing, they get added side by side.
I'm not sure whether they work or not, still a lot to add and a little bit to rewrite but I'd like to do this properly from start to finish. Is there a more appropriate way to do this? Or if not then how would i nest the vb files into the xaml files?
Apparently I need to add the files one by one by selecting the xaml one, then it automatically adds the .vb as nested.
This seems like it should be pretty simple but I can't seem to make it happen. Lets say I have an existing project with a user control named uc1. I would like to use this user control in another project. I right-click the project name in the solution explorer and select add>existing item, change the drop down to all files and select the files uc1.xaml and uc1.xaml.vb. This of course adds the files to the project but there is no correlation between the xaml and the code behind file and there is no way to use the control. What is the proper way of doing this?
Reed's answer is a good architectural one. If you plan on creating a control that you will reuse in many projects then it's best to use a control library.
Your original question is valid in some situations though. Say you have some source code from the Internet that you've unzipped to your drive. This project contains a .XAML file and its linked .vb file that you want to add to a project.
As you seen, the Visual Studio Solution Explorer doesn't link the files when adding with the "Add Item" dialog. I think this is a bug. I find that if I reload the project, the affiliation is added.
Here's a workaround I use. I drag the files from Windows Explorer /File Explorer onto the project in Solution Explorer. That works correctly the first time.
This of course adds the files to the project but there is no correlation between the xaml and the code behind file and there is no way to use the control. What is the proper way of doing this?
Normally, you'd add a reference to the other project, and use the UserControl directly.
This allows you to build a single project with your UserControl, and use the resulting assembly (DLL) in multiple projects without duplicating the code.
If you want to reuse your user controls you need to create a new project and choose "Class Library" from the list of available projects. When compiled this class library can easily be used by any number of other projects and solutions simply by adding a reference to compiled DLL created when you build this class library.
Edit: As mentioned in other answer it's "WPF UserControl Library", not simple "Class Library"...
You just need to add the .xaml file and VS should auto add the code behind(nested). I've seen this not work a few times and as #Walt Ritscher said this is probably a bug.
I found simply restarting Visual Studio and reloading my solution worked.
I'd like the users of my touch app to be able to modify certain UserControl properties by editing a text or XML file (e.g border colors and thicknesses, that sort of thing).
What's the best way to include a file like that in my project so that users can edit it after it's been published? I think if they go in the app.config file they're not editable?
app.config is editable, but should only be edited by an admin in the event that system settings change in a way that makes the deployment settings no longer applicable.
Prefer instead to used a settings file.
This seems to be the standard method of handling it.
Has anyone else experience incredibly slow performance in the XAML editor in VS 2010? If I have a new project with a limited number of files, the performance is fine. However, if I have a project with a larger number of XAML files, the XAML editor hangs intermittently every few seconds, making it almost impossible to use.
I should also note that the performance is only slow in one particular project where I am referencing DevExpress 2010. I am not certain if this is related.
Any suggestions on solutions to this problem would be greatly appreciated.
Chris
In Visual Studio 2012:
Go to
Tools > Options > TextEditor > XAML > Misc
Check Always open documents in XAML view and uncheck Automatically populate toolbox items.
In Visual Studio 2015, 2017:
Go to
Tools > Options > XAML Designer
uncheck Automatically populate toolbox items.
This fixed my same problem.
If you don't need the visual designer, you can select a different editor in visual studio:
Right click the xaml file -> Open With... -> Source Code (Text) Editor
You will only lose the split view, intellisense etc. should still work.
If you need to check something in the designer you can still click 'view designer' to open the normal XAML editor again.
If you want to improve the performance of the visual designer, try checking DesignerProperties.GetIsInDesignMode in your code-behind. The visualiser instantiates your controls to know how to display them, thus executing parts of the code-behind.
Like the OP, I had extreme lag in the xaml editor on a project that relied heavily on DevExpress WPF controls. After trying unsuccessfully to resolve this issue with the other solutions posted here, I eventually tried deleting my Solution User Options (.suo) file, which is usually located in the same folder as the solution (.sln) file. This immediately resolved the issue. You may want to read this post about what visual studio stores in the suo file so you can reset anything important (such as build configuration - mine always defaults the active solution platform back to "Mixed Platforms" for example)
Short answer: if you do not use designer much, just replace the default editor for XAML, thus getting rid of XAML visual designer and speeding things up. Right click any XAML file, click Open with... and choose another default editor. Source code (text) editor works just fine.
Now it should be already fine. If you want to understand the details and completely get rid of the slow designer, read the long answer.
Long answer: Here is a nice explanation of what happens and why is it that slow.
A brief todo based on the aforementioned article in order to completely disable the visual designer of XAML:
Under Tools->Options->Text Editor->XAML->Miscellaneous->Default View check Always open documents in full XAML view
Open Task manager and end XAML Designer process XDesProc.exe (Note: for VS2013 right click this process and go to containing folder. Rename the exe to sth else, than end the process)
Standard XAML editor will load this process again (I guess it will not succeed with VS2013 and actions done in P.2). However, right click any XAML file, Open with... and choose another default editor. Source code (text) editor works just fine.
While using dev express, I've noticed some laggy response in the Visual Studio designer. This appears to be due to the license authentication of the DevExpress products.
If you delete the "Licenses.Licx" file (found in the project properties folder) you'll notice a marked improvement in performance.
Note: Removing the license file doesn't stop you from using DevExpress controls. But it does stop VS from constantly authenticating it.
I spend most of my time developing controls for both WPF and Silverlight using the same codebase. To do this I add existing files from one project (say Silverlight) "as links" to the other (say WPF). For minor differences I use preprocessor directives like
#if SILVERLIGHT
...
#else
...
#endif
The code in these blocks is grayed out depending on the type of project you've opened the file from. So if you open your file from Silverlight project (where SILVERLIGHT is defined) the else part is gray and Intellisense doesn't work in it.
In order for WPF part to be processed by IDE (with coloring and Intellisense support) you need to open the file from the WPF project. When you try to do that you get a message box saying that "This document is opened by another project" and when you click OK it displays that file in the context of the Silverlight project (not what I wanted to see). So I have to close the file, navigate to WPF project again and open the file again. This is very, very annoying.
So the question is this: is there some sort of setting or add-on that would make Visual Studio reopen the file from the project where I double-clicked on it instead of showing that stupid message box and showing me that file from the "wrong" project?
This has happened to me about twice in a month now, not in a WPF application. No idea why it happens but in both cases the fix was to Clean the solution, reboot the PC (not just restart Visual Studio) and then build the solution.
You could make this a little easier to work with by using partial classes and multiple files: shared code that is the same for both WPF and Silverlight in a shared linked file, and a separate file for each containing the code specific to one or the other (with identical method/property signatures), each of which is only in one of the projects. Doing this allows both the WPF and Silverlight versions to be opened at once (since they're separate files) at the cost of adding a bunch of extra file management overhead.
Beyond that, get some extra memory and use separate solutions.
It occurred to me, when I had one project containing a linked file of other project under one VS solution. When I tried to navigate to the definition of a method in linked file, VS prompted with a message that this document is opened by another project.
To resolve this, I had to unload the project that owns the original file from the VS solution. After that navigating to method definition in normal time and debug time was not an issue.
Yes this is possible using Visual Studio Shell.
First instantiate EnvDTE80.DTE2 object:
private static EnvDTE80.DTE2 _dte;
public static EnvDTE80.DTE2 DTE
{
get
{
if (_dte == null)
_dte = ServiceProvider.GlobalProvider.GetService(typeof(DTE)) as DTE2;
return _dte;
}
}
and then:
// On Document Opening, close the existing instances.
// This event occurs when you double-click file in Solution Explorer.
DTE.Events.DocumentEvents.DocumentOpening += (s, e) =>
{
if(!DTE.ItemOperations.IsFileOpen(YOURFILENAME))
return;
foreach(Window win in DTE.Documents.Cast<Document>()
.FirstOrDefault(s => s.FullName == YOURFILENAME).Windows))
win.Close();
}
// next; VS itself will call DTE.ItemOperatins.OpenFile(YOURFILENAME);
HTH.