I have been looking at some components Microsoft use for VS2012, attempting to learn and use there approaches to extensible component design. Despite being able to decompile the C#, I cannot seem to find any way of looking at the XAML mark-up, is this possible?
Note. I have attempted using Snoop but this does not seem to be able to provide the relevant XAML.
Thanks for your time.
You could use a commercial Reflector with BAML Viewer to convert BAML resource of assembly to XAML.
Also you could use a free dotPeek decompiler. Since 1.1 version it has a feature to view BAML resources without any additional plug-ins.
At last you could use a open source ILSpy decompiler to solve the same problem.
Related
I want to learn the solution in UWP to fix bug in wpf that I used the DotPeek to decompilate the UWP ListView control but I got the result without source code.
How to get the uwp control's source code?
I use some tool software to decompilate the control of uwp but I cant get the source code.
What I want is I can get the source code that can run in VisualStudio or you can support me a site like https://referencesource.microsoft.com/ that can see some source code.
As we know, WPF cant do some thing well but UWP can that I want to learn it.
Unlike .NET, UWP is not open-sourced as of now so there is no where to get the uncompiled source code.
You will have to somehow decompile the assemblies if you want to take a look at the code. Decompiling native code is tough though.
Update
Now we can find some source code in Windows UI Library repo.
I'm new to the Windows world, and I think I'm getting lost in the weeds on a problem. I'd love some advice from people with experience with C++/CLI and WPF and XAML.
I have some win32 code, and I need to run a WPF GUI. I found this MS walkthrough sample, which uses C++/CLI. I adapted it to my purposes, and it works great.
Next, I wanted to rip out the programmatic WPF stuff and use XAML instead. This is so I can hand off the XAML to a designer person and take myself out of the UI design loop, where I most assuredly don't belong. After reading the "WPF Interoperation Projects" section of WPF and Win32 Interoperation on MSDN, I decided to go with the XamlReader::Load option and load uncompiled XAML at runtime. My XAML markup is a Canvas UIElement which I programmatically add as a child of my root Grid C++/CLI element. This works great.
Now I want to add event handler to controls in the XAML. This is where I have started to run into trouble. I'm sure that my general ignorance of the Windows world is 95% of what's killing me here.
I started with Rob Relyea's page outlining the various XAML-and-event-handler options.
I decided to try compiling the XAML as a C# DLL. It's basically the same XAML as what I used in the runtime Load case. I instantiate the object and programmatically add as it as a child, just like before. But ... I get nothing but a black window. No exceptions get thrown either. I'm baffled.
My question is, am I even headed down the right path? The page on XAML-and-event-handlers says you can use event handlers defined in uncompiled XAML in .Net Framework 4. Should I bite the bullet and just go to VS 2010 (I'm presently on VS 2008) so I can use .Net Framework 4 and just stick with uncompiled XAML? Are there any gotchas with doing things that way?
Or, if you do think the compiled C# DLL is a reasonable path, do you have any ideas on how I can debug the problems I'm having?
Or, is there a better and completely different approach?
Thanks in advance for your advice.
Polly
I think the right answer for this depends on some issues that only you can decide, but I'll start with the assumption that your C++ code base is big and complex enough that it is worth preserving.
Beyond that the next decision point is do you have UI (perhaps GDI) code in the C++ your preserving or only non-UI code. If you are attempting to preserve only non-UI code then I would consider pushing more UI responsibilty into C#. Perhaps you go so far as to build your views, event handlers, and maybe even view models in C#. This will enable you to take better advantage of the VS tooling.
If you've got extensive UI code in C++ to preserve then your current path makes a more sense. I don't think it will be impossible, but you'll have quite a challenge ahead of you. The key example here is Visual Studio 2010. It is the premiere example of a mixed application and has GDI and WPF side by side unlike any other app I've ever seen or heard of. There is a series of blog posts that I found pretty interesting that describe some aspects of what the Visual Studio team did to achieve this integration at The Visual Studio Blog.
I also came across this video Henry Sowizral on Refacing C++ with WPF in Expression Design that I have not seen myself, but discusses putting a WPF UI on top of an existing MFC C++ app.
Good luck.
I don't have any specific advice on the first part of your question other than to say that putting more responsibility in C# would allow you to build a small stub app if necessary which could go a long way toward diagnosing problems.
Thanks to everyone for the responses. On the matter of getting stuck on the C# DLL, I found this C++/CLI sample: http://msdn.microsoft.com/en-us/library/aa970266.aspx. Using that, I found my error, and was able to load the WPF without problems.
However, the whole motivation for loading the C# DLL was that I had understood that that was the way to attach event handlers programmatically. Following AresAvatar's suggestion, I found that I could use FindName to attach the handlers -- both within the C# DLL, but it also worked with my original loose-XAML approach. So, I didn't need the C# DLL after all!
It's all working nicely now. Again, thanks for all of your help and suggestions.
When opening a XAML file in VS2010 Professional, the studio becomes unresponsive for 5-7 seconds and many local controls are marked with error bars, since they do not support design time usage. This also happens after a debugged application is terminated.
I've got a i5 CPU, 16GB RAM and an SSD, so I don't think my H/W specs are at fault.
I'm already opening documents in full XAML view (as suggested here) and I've closed all clutterboxes (Toolbar, Document Outline, Data Source) to no avail.
Currently I'm using the XML editor for my sanity, but of course this also means no IntelliSense at all.
Is there a way to completely disable the WPF Designer in Visual Studio 2010 without loosing XAML IntelliSense capabilities?
I don't know if there is a way to use a lightweight XML editor that preserves IntelliSense inside Visual Studio. However I suggest you to try kaxaml.
From the website:
Kaxaml is designed to be "notepad for XAML." It's supposed to be simple and lightweight and make it easy to just try something out. It also has some basic support for intellisense and some fun plugins (including one for snippets, one for cleaning up your XAML and for rendering your XAML to an image).
I had the same problem with WPF XAML. The only way I found so far is to use XML editor. Yes, you will not have IntelliSense anymore but there is no better way here. Using external editors like Kaxaml helps only for primitive XAML files which do not use anything from other XAMLs (Kaxaml doesn't support projects or at least didn't supported them, so it is not useful for real projects). You can also try using Expression Blend for editing XAML files but it is also not that good alternative.
Please add
if (DesignerProperties.GetIsInDesignMode(this))
return;
to Constructor, OnApplyTemplate and Loaded event handler, that will ignore all design time processing and make the controls load faster.
I have a Silverlight application that uses Kit3D and I want to convert it to WPF.
How would I do that?
Should I do that?
You could try downloading the source code from its Codeplex repository and recompiling with WPF as the target. No guarantees this will work without modifications, though, since WPF is not a complete superset of Silverlight. But according to the author's description on his web page, Kit3D is modeled after WPF's built-in Media3D namespace, so you could just use that directly rather than bother with a 3rd-party library.
Where to find Generic.xaml (or other code with the default look) for native WPF controls such as Button, CheckBox, TextBox, etc?
In Silverlight (and I know that your question is about WPF) this information is more accessible than in WPF. You can get this information from any of these sources:
Control Styles and Templates on MSDN.
You can look at the resources of the relevant Silverlight assembly and extract the themes/generic.xaml embedded in a resource. I use Reflector to do this.
You can extract the control template of a specific control using a tool. I use Expression Blend to do this. This also works for WPF.
Unfortunately the XAML for native controls is not directly available as a file. You need to use a program for peeking into the WPF assemblies and extracting that info. I personally have used the Mole for Visual Studio tool, which has done the job very well. It integrates as a debugger-visualiser, which is quite handy.