While developing the designer keeps expanding the namespace. Where it should simply instantiate Class1, it is expanding the instantiation to Namespace.Class1.
Is there a way of preventing this behavior? Namespace is a multi-dotted default.
Your question is not clear enough, what platform/UI do your app use?
If you develop ASP.NET, the control/component is registered using register tag, but the file designer.vb or the designer.cs will still contain full namespace.
If you develop Windows Forms, the control/component will always have full namespace in the designer.vb and designer.cs.
If you develop WPF/Silverlight, the XAML file will directly display only the class name of the control you use, but the generated g.cs or g.vb will display complete/full namespace.
This is the default behavior of Visual Studio designer, whether ASP.NET, WPF/Silverlight, Windows Forms.
There's nothing you can do to change this, unless you created the UI WITHOUT designer support, such as creating a pure Window in WPF or Form in Windows Forms purely by code.
Related
I have a C++/winrt project with a complex and dynamic xaml interface created in C++ code. Now I am moving to the latest VS 15.9.0 Preview 3, which has platform support for C++/Winrt and also allows use of the xaml designer in such a project. But I don't want to use the designer and have turned it off in Tools/Options/Xaml. The result is that none of my programmatic xaml elements appears. The project seems to expect me to enter these elements in a xaml code page, rather than using C++, e.g. Grid(), StackPanel(), view.RowDefinitions.Append(), view.SetRow() etc. The GeneratedFiles folder is now full of items that were not present in the previous project, yet can't be removed. Is it still possible to use the C++ interface for xaml, and what must be done to enable it if so? Thanks.
Ryan is correct: C++/winrt does support programmatic creation of xaml, and it works great. With the help of a couple of c++/winrt guys at MS I think I also know why my code was not doing anything. In the former version of my app I had declared MainPage as a C++ class, not a struct, and had assigned the starting Grid for the xaml by getting the current Window and setting currentWindow.Content(theGrid). But in the new template app MainPage is a struct, which might matter, and while setting window.Content that way no longer works, this does: this->Content(theGrid). Leaving aside some irrelevant issues about declarations in the BlankApp, this I think is the answer. Programmatic xaml works if you set that initial content as above.
Unfortunately, this is not the intended way to use this UI system. XAML-based UI systems are descendants of WPF, which relies on the Model-View-ViewModel (MVVM) pattern.
This pattern intends three types of classes to make up your application: Views, which are primarily written in XAML, and only deal with displaying data they are given; ViewModels, which are the wrapper and translator to give the views data, and to give the models commands; and lastly, Models, which are your backend business-logic classes.
Your instinct to not trust the designer is reasonable - it generates messy and unidiomatic XAML code. But it is an excellent way to preview the way your XAML code looks.
To get back to your specific situation, there are real problems in the library's API that will be serious roadblocks to programmatically define a UI in C++. Instead, you will want to use XAML to declare the UI. Adding and removing grid column definitions is not something that is well-supported, but using StackPanels and DockPanels is the normal way to do this.
If you have more specific questions, feel free to open a new question here, but do bear in mind that you may want to search first under the tags mvvm and wpf in addition to xaml, c++-winrt, and winrt.
If you have more questions that are rather broad and may be too broad for the main site here, feel free to join the WPF channel on chat, but bear in mind that most of us don't have experience in WinRT specifically.
I'm using pure WINAPI, and need to send the TB_GETMETRICS message. However, that message only works if you add a manifest file to your application with a reference to Common Controls version 6.0. I added it, the message is working, but now my application is using Vista/Windows 7 visual styles, which I do not want.
Is there any way to keep the Common Controls 6.0 reference while using Classic theme, either by modifying the manifest file or by calling some API function?
Note: I tried SetWindowTheme but the result was a mix of Classic and Aero.
EDIT: I hadn't read the SetWindowTheme function correctly, so I was thinking calling it for the parent hWnd would automatically call it for all its child. It turns out I need to call it for each control I want to use Windows Classic. It's working as it should now.
To disable visual styles for all controls, call SetThemeAppProperties(STAP_ALLOW_NONCLIENT) or SetThemeAppProperties(0) before you create your main window.
To disable visual styles per HWND you can call SetWindowTheme(hwndControl,L"",L"")
If you need to support systems without v6 common controls you can probably figure out which system metrics (or hardcoded values) are used in the toolbar control by playing with the system metric values and system DPI.
Solved by using SetWindowTheme (with L"" as parameters) properly: all I had to do was call it for each and every control my application creates. It feels hackish but gets the job done.
I have an application in Windows Phone 7.0 and now I want to make it multilingual supporting both English and French languages.
Could anybody guide me through the approach I should follow for supporting it in multilingul.
Thanks
SAM
The recommended approach is to expose any ResourceManager instances as XAML Resources (via a wrapper class, since the resources are only available at runtime). You can then bind to the properties of the strongly typed ResourceManager in XAML.
Here is some documentation that might help:
How to: Build a Localized Application for Windows Phone
Globalization and Localization for Windows Phone
And some other resources to help:
PhoneCommonStrings contains strings commonly used in WP7 applications, localized to all available languages (disclaimer: I'm the author of the library)
BindableApplicationBar allows you to bind the text (and command) of your application bar buttons
Look at my blog: I just wrote about this very subject a couple weeks ago. It gives you step-by-step instructions.
Basically:
Create the project
Edit the .csproj file in notepad to add the desired cultures to the tag.
Select a neutral culture in the project's properties
Add Resources to the project in Solution Explorer
Create a class to access those resources
Add that class to the tag of the App.xaml file
Put your strings into the Resources file
Bind to those strings using the resource binding in your xaml.
If using an ApplicationBar, you must do so in code, as it cannot be bound in xaml.
Create another resource file for each supported culture.
Create dll files for each supported language, so the title will be correct on the tile and program list.
We're working on creating a specialized graphical editor for our enterprise applications. We've looked at and rejected DSLs. Ideally I'd like to have the main interface of the editor be docked like the code windows and use WPF for drawing. Can anyone point me to some documentation to get me on the right path?
Thanks.
Colin.
UPDATE: It's beginning to look like "no." From http://msdn.microsoft.com/en-us/library/bb166228.aspx: "Document windows are created by implementing an editor. The IVsEditorFactory interface creates document windows as part of instantiating an editor. For more information, see Accessing the Editor By Using Legacy Interfaces."
Following the link to http://msdn.microsoft.com/en-us/library/dd885127.aspx gives this this bit of advice: "You can access the Visual Studio editor from legacy interfaces. The Visual Studio SDK includes adapters known as shims, which enable these interfaces to interact with the new editor. Nevertheless, we recommend that you update your legacy code to use the new editor API. Your code will perform better and you can use new technologies such as the Windows Presentation Foundation (WPF) and the Managed Extensibility Framework (MEF)."
So, to sum up: if you want to implement an editor you have to use the legacy interfaces, but you shouldn't use the legacy interfaces because then you can't use WPF or MEF.
Seriously Microsoft, WTF?
UPDATE 2: Now that I have the proper names ("custom editor"), I was able to find the following topic: http://social.msdn.microsoft.com/Forums/en-US/vsxprerelease/thread/9e605d0f-1296-47c9-a534-e54905251ebe
I still don't see why they couldn't have included that somewhere prominent in the MSDN docs. You know, like somewhere near where they tell you that you can't use WPF if you're using the legacy interfaces.
Creating a custom editor doesn't have to be terribly painful. Yes, a custom editor will require implementing a few interfaces, but you can still use WPF to actually create the control that is hosted in the VS document frame.
DiveDeeper's blog has some great resources for learning about creating a custom editor.
Creating a simple custom editor - the basics
Creating a simple custom editor - the first 10 meters
Creating a simple custom editor - under pressure
I'd recommend using a library like VSXtra to do a lot of the work for you. It will provide you with a nice base implementation of an editor factory, editor pane, package, etc. Istvan Novak writes about building a custom editor with his VSXtra library in this blog post.
Visual Studio allows you to design components visually. For example, you are designing a Windows form. You change its property in the properties editor. The IDE will generate the code in a partial class in xx.designer.cs file. We can customize this behavior by changing the UITypeEditor for the properties.
The question now is: Can we extend this code generation behavior? For example, we change a setting in the property window, and then the IDE will add a .NET attribute to the class?
To my knowledge, that is not possible. Sorry. Such a thing IS possible with Eclipse, however, because it's open source.