 On today's Visual Studio Toolbox is the triumphant return of Dimitri Leyland who will show us really cool things in the XAML Designer. Hi there and welcome back to another episode of Visual Studio Toolbox. Today I am your guest Dimitri Leyland and with me is our host Robert Green. Hey, Dimitri. Hey, how's it going? Thanks for having me on the show. I'd love to have you on the show. Thank you for coming on to host the show with me. So it's been a long time since you've been on the show. Yes. Welcome back. Thank you. In the meantime, you joined the XAML Designer team as a PM. Yes, so I am the PM for XAML Tools for Desktop Application Developers. So the WPF framework core UWP, that's all in my boat. And I look after designer hard reload and work with code editor and everything else that makes it possible. So all you guys doing XAML, you know who to pin with feature requests. Yes, so we know we're still dependent on the platform teams from Windows that build the frameworks, UWP, WPF. We've got our .NET team that builds the runtime and our team builds the tools. So there's three teams positioned to make all this come together. And then how does that work with Xamarin? Because Xamarin Forms also uses XAML. There's another team called Xamarin. So my team actually collaborates with them at the engineering NPM level. So at the engineering level, if you're using Visual Studio for Mac, for example, and you're building a Xamarin Forms application, that code editor experience comes from my team now. It used to be a different code base because they, you know, development was happening in parallel. We're optimizing it all together. We're working on collaborating in designers, hard reload, code editors. So over time, you're basically going to see anything Xamarin.xaml be powered by the code coming out of my team, but implemented by the Xamarin team on top of our frameworks and our extensibility framework. So does that mean different implementations, one design different implementations, or one design one implementation? It's one code base, one set of infrastructure, and slightly different implementations for the specific frameworks about it. So things might still appear in one place first, and then- Yeah, there's still some of that. Xamarin got hard reload first, right? Well, no, we had hard reload first. And then Xamarin built it in parallel for their stack, because they have a very different stack. They just talked about it first. And loudest. They talked about loudest, there you go. Okay. But we were collaborating. In fact, one of the changes I'm going to talk about today about my hard reload is that it wasn't called hard reload at first. It was called something else. Then Xamarin was going to launch their feature because we work at the PM level together. We're actually one team now at the PM level. So my team and the Xamarin forums team were in the same manager chain. This was a change that was recently made, and we basically talk on a regular basis, the weekly basis I talk to that team. So we collaborated on making hard reload the same name across both features, because they're the same feature. And now the engineering level will collaborate to make it the same code base, slightly cooler. All right. Even better. So the last time we have to rewrite the frameworks underneath everything, the better. Absolutely. So Visual Studio 16.4. 16.4. Just released. Preview three. Preview three. Yeah, because preview one and two were out already. And preview three just shipped that ignite. So just like a week ago. Preview three just shipped that ignite, okay. So the features, some of the features you're going to show today, all of the features are in 16.4. So we have features that we're going to show today, that I'm going to show today from all the way back from the GA release of 2019, some of them. I'll call it out when it's referenceable. But for the most part, you can think of it. If you have 16.4 preview three installed, you have everything that I'm going to demonstrate, except the two things that are going to be at the very end, which are slightly different. But everything else you have built in there. And we have release notes for everything. So if you're curious why is something missing from your version, just check release notes. You'll see that maybe a feature came a little bit later if I forget to mention. OK, cool. All right, so let's jump into it. I mean, it's a big list of features. I had to build myself a little checklist. So I'll be looking down occasionally. But I want to make sure we cover everything. So I want to start with talking about the tools in front of me. So here I have Visual Studio 16.4. And again, this is the same version as the public release that came out at Ignite. And right now, I'm going to talk to you first about the features that are here before you hit a five. So these are the features of Visual Studio that are the design time tooling experience. And this is a WPF application. Yes, so I have a WPF app. It's coming out of the samples repo at Microsoft Samples and GitHub called WPF samples. And that's why I'm using this expense app. Robert was making fun of me before the show. So we need another flip and expense app. Another flip and expense app. But it's OK. It's a real sample. I didn't want to show something that folks couldn't play around with as well. So here you go. It's a WPF core app. Just let's make sure that I'm not lying to you. There it is. .NET Core 3 is the target. So it's a converted app. And one of the things that wasn't working before 16.3, even though WPF core was around even before 16.3 came out, so the previous release of ES, was our designer wasn't first available, then it was available as a preview. So the designer for a WPF app that chooses to target core, that was the thing that we had to work on. We had to basically rebuild the designer for this experience. It was a lot of work on my team. And they had to make a choice. Did they start with the designer they had for .NET Framework? Or choose a slightly newer code base they had for the UWP designer. It's all XAML, but the code was different. And we chose the UWP one. So if you actually have the same app and you open it in two instances of ES, and you have both designers side by side, slight differences between framework on the left and core on the right. But for the most part, you shouldn't notice anything super missing or broken. In fact, please let us know if something in the .NET Core WPF designer feels like it's missing or not working. We need to know and be specific to report it via VS feedback because then we'll know which version you were using. We still support all the designers, so any bugs we find, we will try to fix all of that. So this is the core designer. It's on by default. It's working. The first thing that I want to talk about in terms of new features that came out back when Visual Studio 2019 was shipped was IntelliCode. So IntelliCode is something that we've enabled. That was something my team had to enable. And IntelliCode is all about making it so that as you start typing, there's a bunch of start properties that come up first. And those are the ones where we scan GitHub and we look for XAML projects and we based on taking learnings from GitHub on this open source set of projects, we figure out which properties you're most likely to type. And people are very likely to type margin, column span, name, with, et cetera. So these appear basically for any control you have, whether it's a list box, whether it's a label, you get star content. If you start typing something new, like let's say we were adding a button here, if I can type, the first one is name and that's very likely, right? Like I know myself, I would probably name this button and then I would wanna set the content. So having this appear here just makes a ton of sense. So IntelliCode is really cool and it's there for everything. We also have a new feature, this is a 16.4 preview three feature that has been asked for many, many times and we finally were able to implement it for you, which is this little new button right here. It's called pop out XAML. When you click this button, right now we have the designer above and we have the code editor below and when you click the button, we hide the code editor inside of your designer view, right there, the designer is now by itself and we pop out the window. So you can now dog this window with the code in a different monitor. Not exactly, it's an area for my lower solution machine here projecting. But certainly on my real desktop setup, this is awesome now. I can have it. That's a lot easier than looking at those three buttons on the lower right, clicking the one to the right and then clicking XAML if you just wanna see the XAML. In fact, the only way for this exact experience to make it a full pop-up window, it used to be that you had to know a trick. You had to right click on the code file and the XAML file and say open with and like it was a bunch of steps and then we had this epiphany, why not automate it to a button? Cool. And we made it a button and it actually took the lead dev there like a few days to implement this. It was a very quick feature too and it came from customer feedback. Like we got a ticket and we've seen these before, before I even joined the team and I said, please make this possible and I just turned to the dev lead, he sits behind me. I'm like, can we do this? He's like, yeah, there's this workaround we can probably automate and we just did it. So it was a beautiful moment as a PM to get that sort of execution. Now, I just closed the window. You might ask me, how do I get back to having the code editor in my file here in my view? It was never actually missing. It was just minimized. So you can still expand it. In fact, if you open it up and you expand it here, you'll have two of them and they're fully in sync. Any changes you make in one, they're basically the same instance behind the scene. So they're completely kept in sync. So you can have them both open if that's what you want for some reason. So that's a new feature that you will only get if you have 16 for preview three installed. Another thing that I want to point out that some folks get confused about and it's on us a little bit. Like I want to improve this in the future but I'll call out the existing experience. Some people have actually told me that this is live visual tree we'll talk about in a minute, right? And it only appears when your app runs. It shows you how your app is composed in a tree format, all the objects nesting, all the XAML objects elements. And they're like, well, I'd like something like that but without running the app. And we do have it. It's called the document outline. Some people just forget that it's there but here it is docked on the left side. It's showing you everything that is composing your screen here. And if you click and you say, you know what I want to make the grid invisible just to see what that looks like. Well, all your controls will go away. Like all that works. And it's a design time feature. If you click this I, it puts a D is hidden. So it's design time only. If you run this app, it would appear again. It wouldn't hide it, but it lets you kind of have a nice little playing with your visual tree to see which elements are here and what you can hide it. I'm looking to make document outline a bit more useful in the future but that's gonna be next year at the earliest. Just wanted to point it out because I've had two people ask me for this feature and I'm like, we have the feature. Yay, that was easy. Another feature that we added that's code editor specific. In other words, like tools before you run the application which will be our next segment here is a feature I've actually wanted myself. If you have a resource dictionary in your XAML application, that resource dictionary lives anywhere outside of your project like in some components. You have to know how to compose the path to merge it correctly back into your app. I'm not explaining what this is because I'm assuming that the XAML does know what I'm talking about. The resource dictionaries are needing to merge them to use them. In fact, the path was different in WPF instead of versus like UWP. So you're like, I have to remember different paths based on different apps. It's just something that really was annoying. Like I knew myself, I had to Google it every time and we realized why not make it a feature and we had customer feedback come in. We don't do anything without hearing from customers too. So customers were like, please make this a feature. We had quite a few tickets come in for that as well. So we do listen to your tickets as they come in. So let me show you that feature right here. So I'm gonna open up app.xaml and in here I already have a resource dictionary merged. I mean, look at this. You have to remember that it's the module name, then the word component, then a slash followed by the resource dictionary.xaml. Like it's a lot to remember. So you don't have to remember it anymore. If you have 16.4, preview three installed, you just have to open the file that's your target. In this case, app.xaml is where I'm merging. You have to select the valid resource dictionary. You have to right click on it and say, merge resource dictionary into active window. You click that. We're actually gonna change it right now after adding the xaml to select everything. That's not what we wanted. So we're gonna change that before 16.4. So it just added everything? Well, it only added these lines here, but it selected everything. Zootogy to the end of the file. That's kind of a mini bug we're gonna fix. But basically it put this code back in. And if it put the wrong thing back in here, you can just control Z away. It's not anything more than us typing the xaml for you, but it's really useful because now you don't have to remember how to build this stuff. So merge resource dictionary, that's really awesome. All right, so now that I have my app kind of composed back to a runnable state, let's go ahead and run the application and let's talk about our xaml live debugging tools that we have in Visual Studio. And I wanna describe all of them before I talk about what's new in each just to make sure folks know what this is all about. So now that I'm running the application, I have a couple of different things open. The first thing is there's a toolbar added to your application. This toolbar is there on by default. You can turn it off if it bothers you for any reason. In fact, there's a button right here in the live visual tree. If you click on the button and you go back to your app, it disappears. So it's really configurable that there could be a setting that you can choose in settings as well. Does it have to be docked to the app window? Can you drag it off the app window? It has to be docked. So for now we can't really change that. It's because of just how this works. That's my feature request. Yeah, but we'll get to these few things we made better here. So this is what we call the in-app toolbar. So if you ever hear me say in-app toolbar, I mean this little toolbar. Not in-app, in-app. In-app, in-app, there you go. My lawyer here will clear things up. Now, the other two tools we have is the live visual tree in the left that's this thing here and I've also opened something called the live property explorer in the right. Nice that you can turn it off in the live visual tree though. Yeah, you can turn it off and I'm going to talk about some new features. So we've always had this ability, which is to minimize. So you can always have minimized. But we had a bunch of people ask, can you make it movable? It's blocking stuff sometimes. Like we want it there. We like it, but we want it movable. 16.4, preview three is now movable, left and right. Now it has to be docked to the top. But it must be docked to the top. It's because we literally inject some XAML into your XAML to put it there. If this really bothers you that it's docked, if there's like a strong case to make it something else, please send this feedback. That's always what I'm going to tell people. For most people, this is good enough. Our team uses our own tools to build their own tools. So we use this feature all the time. Our design team uses it. So we hear a lot from our own people as well. And by making it movable, it solved this for a lot of people in terms of being problematic. The other thing we did was we made it so that it's themed. This toolbar used to be not themed. They used to have generic color. Now it follows your VS colors. Just make it easier on the eye to know that's a tool from Visuals coming from Visual Studio. Make it white, make it blue. It's going to follow along just as well. And another change that we made to this was the selector feature. So the element selector, select element, in fact, we fixed the tool tip. It used to be had a worse name. I think what it was was something that right. So now it's called select element. That's what it does. This is what allows you to go from your running app to a selection in the live visual tree. So you saw one, I'll do it again. When I clicked on something, the live visual tree updated to say label and the live property explorer updated to show you the live properties of that label as well. Now the other thing that it did was, well that it will do once I click this button here, is that it will go to the label in your XAML code as well. So it doesn't do that automatically? There's a button up here I could have done to track it, but I disabled it. So you could have shown a preview selected item, but I chose not to. It all depends how you want to flow. I'm not gonna, like this is in the training, so I won't go for every possible combination of stuff, but definitely good question. I'm gonna make this app top most. So let's do that. So that's the first thing I want to point out, hot reload. Lots of people still don't know we have hot reload. The app is running. I just used the selector to find something. So let's go for the flow again, call center. I'm gonna select it, then I click on the label. It went to the label. Now that we can see the app at all times, I'm gonna say, hmm, this label is, has the wrong background color. Just make it a silly case. I wanna make it black. So the app just updated to black. We allow you to change, using hot reload, you can change WPF core app, WPF framework app, or UWP app, it works for every framework. It works for almost anything. We have documentation. There are some limitations that are called out in the docs, but for the most part, you should be able to edit almost any XAML as your app runs. The only thing you can't do is like, let's say you wanna refactor some XAML out to a control that doesn't exist yet. So you'd have to stop Visual Studio to add the new control, but once you add it, you can run again and start moving your XAML. So you can do basically anything that's outside of changing the structure of your project. UWP apps have these as well? UWP apps have this as well. Yeah, it works for everything. So XAML hot reload, combined with the live visual tree that makes finding elements easy, lets you see your running app, and combined with another feature which is this live property explorer. So the live property explorer, the way that it works, is that it allows you to experiment. So changing the XAML will change the XAML. It also lets you experiment, but those experiments, unless you undo them, will go into your source code, right? When you do a commit. The live property explorer lets you make changes that are purely to be tested. So if you want to change something from here, let's say font size, you want to make it, what if this thing was font size 20, right? So you change font size 20, and now you see that, okay, font size 20, that's probably a bit too much, how about nine? Okay, that's maybe a bit too small, maybe 12 would have been right, 12 looks good. The only thing is now you have to go and change that style, still in XAML. So this live property explorer, I've gotten some people telling me that it's not clear that it's only an element for testing. It doesn't apply to my code. So we're thinking about that. Maybe next year we can make that experience better. But if you use this panel while your app is running, it's purely for experimentation. It will not change your real app. So you might possibly add a commit button or something. We're thinking something. But then it's, do you save the most recent thing? Do you save everything up to then? That's why it's so hard, and now. It's amazing how many times we hear from customers and we might even purely agree with the idea, we're like, great idea. And then we start sitting down in the room, a bunch of us, whatever, on board. And then we leave busy. We're like, oh my God, this is so much harder than we thought. And then we have to cost it, we have to say, well, is this change gonna be worth it for a number of people impacted, for the amount of productivity improved? So it's always a hard decision. But let us know what you think about these tools together. Another change that we actually have been using while talking right now, without explaining it, so let me go back and explain it, is this new feature called Show Just My XAML. This is part of the live visual tree and this is new in 16 and four preview three. I'm gonna click and I'm gonna go back to what it used to be. So this used to be the default. This feature didn't exist and therefore you had the whole tree. So if I go ahead and expand, wrong button, if I expand the whole tree, this is every single control that composites the app that you have running. It's a lot of controls. Some of them have a little button next to them. Most of them do not because those little buttons mean there's actual source code in your app for a text box. But the text box is composed out of a border, a content host, a grid, a rectangle and you don't have access to that source but we see it as part of the tree, so we show it to you. You can still have this view. If this is useful to you, you could view by unclicking this but we've added this as a new default. We talked to a bunch of customers. We talked to our internal teams and we made a judgment call for better or worse. We think that by default, people want to see this. So I'm going to click on it and I'm going to go back to just my XAML. As you see much smaller tree, this matches your document outline that I showed you before. This is the actual XAML in your app. Now let's say you're looking at, let's say radio button, right? And you think to yourself, okay, this was good. Like I like the change you folks made but I need to see how this radio button is put together. That's useful to me. If you unclick, we save your position. Now you can see below. You can do whatever you need to do by seeing that. And then you can go back to, this is just a quick review. So when you highlight radio button and click just my XAML again, does it show you all of the XAML for the whole thing or just for that radio button? We've chosen for this first implementation to just make it whole. The way that we think about it is we make changes that are simple first. This was a simple change. Either view everything or view just my XAML. We just made your position and then get lost in the selection and that expand collapse kind of maintain the same similar state. If people wanna see more improvements here, different kind of functionality, we need to hear. We need to hear from them, make sure we're not overthinking a problem because in the past that has happened and my whole division, developer division has really learned over the years not to be over thinkers and small changes like this. Make a change, meet the customer feedback, make sure the team feels good about it, make sure the feedback aligns and then see what people think. So let us know. So those are changes. Now in the in-app toolbar, I just wanna point out one more thing. There's a message here that says hard reload available. This was added for the sake of customers were telling us they don't know how to reload is working or not sometimes because there were certain things and we're expanding what hard reload can do all the time. Like if we're finding something doesn't work, we make it work. But before, there's been multiple cases where something doesn't work because not because the feature doesn't work, like hard reload would have worked, but hard reload wasn't available, because let's say you ran your app in release mode and we only attached this tool if it's debug mode. So we decided to add a message to make it very clear. If we see hard reloads working because we can see your tree and we can go down that infrastructure path, we'll show it available. If it's not always say unavailable. And if you click unavailable, and by click I mean this link, if it says hard reload unavailable, you click on it. It's gonna go to documentation. I'll show you what the doc looks like. In this case, I'm going to available because that's the state we're in. But we've built documentation. We have a troubleshooting guide for why it might be unavailable. And we have a documentation which if it is available and you click on it, tells you about what this feature, how it works, what are some of the limitations, what are some of the error messages, what they means, and also give you links to similar technology in Xamarin Forms, et cetera, right? So we're trying to build out docs. It's one of the things I'm working on as a PM making sure we have docs. So if something is missing from docs, please let us know. Cool. But yeah, that's the change before. Now, if you are annoyed by this message, we've had some people in testing, we were internally testing it, say, I don't care. I know how it's available. Go away. We made a little collapse here. You can just collapse it. The state will remember across restarts of your app. We'll never show this again unless you click the expander again. Okay. We also, in 16.4, made these slightly brighter. This comes from Visual Studio Theme and we literally had somebody tell me, I don't see the mover. Like, where's the mover? And I'm like, ooh, yeah. It's hard to see it at times. So because we get these colors from Visual Studio, we weren't controlling them. So we met with the Visual Studio team. We asked them to make them brighter. They agreed. They made it brighter for everywhere. There's a mover in Visual Studio, in fact. And in fact, they might even make it brighter again. They're doing another review, using some contrast tests that they do. So I know that these colors are constantly improving. You see something small like this that's bothering you? Please let us know. Like I'm always telling people, VS feedback really works. We really look at every single thing that you send us. Literally, some lead dev or PM will take a look at it. So please keep the feedback coming. All right, hard reload. Let me talk about hard reload a little bit more. So hard reload has had some limitations in the recent past. I already forget. Some of this was fixed in 16.0, some in 16.2, I think, or 16.3. When did it first show up? Oh, hard reload's been around for a while. I don't even know. Way before I joined the team. It was just not something we advertised enough. So we're advertising more. So we had it way before Xamarin Forms. But now that us and Xamarin Forms have the capability, we're trying to have the same name, cross-linking to each other, and just advocating for the feature because people using the feature really like it. And we really like it. We use it to build the feature. I love that part. Such a geek. So from that perspective, we had some features that were at the detail level not working. So for example, WPF changing a resource dictionary used to not work. That was a big, big oversight in our part. And it wasn't super cheap to do it. It wasn't too expensive, but it was a medium cost item. The team never got around to it. We never heard feedback. And then we started to hear feedback. And I joined the team, and I advocated for it, so we made that change. So now you can change a resource dictionary for WPF since 16.2 or 3, one of those releases. Definitely being in the latest version of ES has the benefit of having all these features. Another thing that we added back in 16.0 that I know for sure is Xbind. So if you have Xbind in the UWP app and you used to change Xbind when your app ran, it would say not supported below. If you make a change in XAML that we know isn't supported, we just put it as quickly across, and we say not supported. Now you can make that change in, I would say, about 60% of the cases. There's still some things like functions and other H cases that don't work. We're exploring constantly. We hear feedback, but we're thinking how to make that even better. So that's the thing we're working on. So hard reload behind the scenes is getting better. But we're also tweaking some of the tools around hard reload, just my XAML that I showed you a second ago, but also small changes that have, like I had somebody get upset at us for making this change. This change has been out since I think 16.3. And a certain customer said, you guys suck, like really, I used to love that this used to work a certain way and you changed it. We said really sorry, like it's on us. We should have added a setting from the beginning to give you back the previous functionality. We knew this would upset somebody. And so in 16.4, preview three, we added a setting. The change is back how it used to work, let me show you how it works now. Clicking the selector, if you think about like how this works in other products, other tools, F12 tools is a big example. You click the select my element and you click on an element and the selection stops. So you can continue interacting with your application. Before the way it used to work is that in our app, when you click this and you click something here, the selector would keep working. So a lot of people then did what they know from F12 tools, they would click on a button and it would select the button and move them away in the live visual tree away from what they wanted to select. Like it confused people, right? Why doesn't this work with other selectors? Select, select, and then back to normal. So we made that change, but if you want the old behavior, so this is the new default. Go to settings, there's a setting to change it. So yeah, I'll show you what that setting is. If you go to options and you go to XAML, so under, sorry, always forgetting where my own settings are, there you go. So if you go under here, and let's go highlight this again. So now there's a bunch of settings. So turn off selection mode when an element is selected. So this is under debugging general and in general, look for the enable UI debugging tree and then you can change this behavior. As you can see just my XAMLs in here as well, we learned from that mistake. We said not everyone would like just my XAML to be a default. So you can make it a default or you can make it not a default. You can change that here for these settings. If we're missing some setting customers, won't please let us know if some feature could use a flip. But settings are often cheap enough to add that we don't mind doing it, even if like one customer complains. So that's another change that we've made. All right, let's switch gears a little bit. We've talked about all the sort of high reload changes and talk about the code editor a little bit more. I mean, we started with the code editor, we talked about the pop-up feature, we talked about IntelliCode. But I'll talk about one more feature which is literally, I got three tickets for this when I joined the team. Three different people said, please add region support to XAML. And that was puzzled by that at first. I'm like, didn't we do that already? I just joined the team at that time and I wasn't even like I didn't have everything memorized, right? So I Googled it and I found a blog post where we talk about this in Visual Studio 2015. And I'm like, oh man, this is done us. We must be doing something wrong. People aren't discovering that the feature already exists. So I started checking on IntelliSense and I realized that when you would type this, so like if you type, you know, you activate IntelliSense with the open bracket here, regions wasn't coming up. It wasn't in this list. So there was a bug in IntelliSense. So we fixed the bug. Here it is. Regions is here in 16.4.3. So if you want to do a region, you can say region start and then you can do this. And you can say, hey, look, it's smart enough to know that you probably want to end your region. And now you can put some XAML in between and that XAML could be collapsed, expanded just like you would expect. This actually works on VS for Mac as well. Because my team now helps the Xamarin forums maintain the XAML editor across both VS for Mac and Windows. This works for every XAML application type. In fact, we're trying to do that between us and Xamarin forums team for every XAML feature that you come across. If you see us do something for desktop that you would love to see in Xamarin forums and it's not there yet, send us feedback that emphasizes this for us even more. Same thing back the other way. We want to make sure that if you're a XAML developer, the tools feel the same for you no matter where you go. You have the same features. But that's a feature that's there. Cool. Now, another thing that we realized is that this was one of those like, you get something, feedback, you respond, you find a bug, you fix it, but then you start thinking. One of the ways we started thinking about was, shouldn't we add a snippet for regions? Then our team said, well, we don't actually even show snippets inside of XAML IntelliSense. It's a how expensive would it be to fix that? Like we should, C-Sharp has it, XAML supports it, but we don't have it in IntelliSense. That's just weird. So we fix that. If you start typing and you type a row for example, rows now snippet we include out of the box. So we built like five snippets. So if you have a grid, let's do a grid, right? Then you grid here and then you have grid column definitions, and then you want to type column, you can do call and then you can do tab, tab and you have a column. Cool. So snippets are supported. Snippets are now in IntelliSense. There's a snippet for column, row, tag, setter, region. So here's like if we wanted to then put this grid inside of a region. So let's start typing region and region. There's another feature called surround with that we could have done it with. This is good enough. So there you go. Makes it just easier, right? Now we can collapse this grid and hide it away. So things like that are cool that we can do it. We got already feedback from internal teams who saw us add this feature. They're like, well in C-Sharp you can filter your IntelliSense to like snippets or methods or properties like there's a bunch of filters. So we know that we don't have that today. We show you everything in the list and we're thinking about how to improve that in the future. So everything is trying to improve. That's a really good thing. So we talked about regions and snippets and everything for that. Also, by the way, custom snippets, if you add your own we'll show up in IntelliSense because it's generic, right? We just included five just to give people an example really. The only thing we can't do with snippets is we can't make them platform specific. It's just not part of how snippets work. So we can't make XAML snippets that are only for let's say WPF Core or UWP. So we have to be really careful which ones we build in because we don't want to put a snippet that doesn't work in one platform or another, but we're always looking for feedback. All right. Let's talk about one more feature that will take us out of this flow of saying, if you have 16.4, preview three, you have everything. This feature is not in there. This feature is more prototypy than finished, but it's good enough of a direction like I feel like our team is moving in the direction to ship a feature like this in the future, that I'm going to show it to you because I need one feedback. So this is not in 16.4. It's not in any VS update. You have to install an extension. The extension is published by one of the developers that I work with. It's not even Microsoft. It's like a personally published extension, but I can assure the audience that this is from my team, and the developer publishing the extension is the person working on the real feature. But it's very rough, but I want to show it to you because it's so awesome. This is a feature I would have liked back when I was a WPF developer back in Microsoft consulting, when I used to build WPF apps for customers. So I have a long XAML background. So now I'm able to help bring the features. That's cool to go from being a customer to being a person to influence this. This feature is called the XAML binding errors window. We have never had a dedicated window to binding failures. Any XAML developer will tell you, I definitely would tell you if I was but me from seven years ago, I'd be like, oh my God, the output window sucks for triaging binding failures. I want to see them clearly. I want to see that something failed, and I want it in some list. In fact, I'd love to click on the failure and go to the code where it's failing. So you want to do all of that. How do you do it? I'm going to break a binding, and there it is. It's now showing up on this list. So this is an extension that we published in a marketplace. It's called the XAML binding debug output. It just worked with various versions of Visual Studio. Today, it only supports WPF framework and core. We're going to add EWP. We're going to add Xamarin Forms. We're working with all those teams when you are in the future. So this is a real window we plan to build. This window today is not close to feature complete. It's not even styled correctly. It might crash your Visual Studio. So worst case, uninstalled extension, like treated as a very early preview. But we are publishing it out there because I want people to install it and stare at it and give us feedback. There's in fact a feedback button we put inside of it. Since this is an out-of-band preview feature, we take you to GitHub. So we have put up a GitHub issue list, so folks can come in here and start filing issues against the suggestions, bugs. Again, really early, but we're going to take feedback this way. My team usually doesn't work on GitHub like this, but for this feature we felt the VS Feedback functionality wouldn't be right because this isn't built into VS. The team that routes stuff would become confused where to route the feature for a thing that doesn't exist and this makes it easy. So please let us know. We're super excited. There's one more feature I'm going to show that is not even available to anybody yet. We tried to ship it for 16.4, but we weren't happy. We were trying to the last moment and then we said, we're not happy enough, but we know we're going to ship it at some point. Probably 16.5. So I think it's going to come in the next release in the previous stage. So I'll show the feature because I want to hear from folks what they think, but let me show you what the feature is. I'm going to switch to another version of Visual Studio that is even hotter, that's not publicly out yet, and just talk about one feature, which is suggested actions. In the past, in the designer, so let me zoom in on the designer a little bit because in this resolution, this is a bit rough. Let me zoom in to 60 percent, a little more. All right, so in the designer, the way the flow of like, okay, your app is not running, you have the designer in front of you, you have a button. You click on the button and you want to change the content's property, right? So how do you change the content property? Well, you have to go to your property explorer and you have to find the content property. And we know which properties people choose, like we've done an analysis on this. We have some data which shows us like some examples of what people choose, especially since we have a lot of internal people who send us telemetry. Like if you work at Microsoft and you use Visual Studio, you send me a lot more telemetry than you do if you're an external customer. So we learn a lot from that. So we know the common things you want to do, content being one of the most common. And right now in my properties pane, I don't even see content. I can go in here and I can type content and hopefully it comes up, okay, there it is, okay, button, Dimitri is what I really wanted it to say, so okay, now I changed it. But that's a really bad flow we think. We want to make it easier. So we want to suggest common properties to you and make it super easy to do that. Light bulb, suggested action light bulbs. You click on this and we show you content as one of the top properties, background. Like these are all properties. Think of it similar like in telecode, we did analysis to choose these sets of properties. That's cool. And this is something like we're totally still exploring. Do we leave these properties? Do we make this pop up automatically instead of popping up when I click? By the way, the fact that it pops up on the left covering the control is a bug in this preview. So if this will be fixed, it'll pop up on the right side. So it'll never cover the control as long as we have enough space in the screen. But basically that's a feature we really want to make work super well. So let us know what you think, how can this be better? Some other things we're going to do that because again, this is super early, we're going to add like actions as well, not just properties. So for example, you click on a tab control, add a new tab. Today that's kind of hard. There'll be an action tab inside of suggested actions. So think of this UI, maybe getting two tabs or maybe getting some extra paint on the right or something early. We have to work with the UX team to figure all this out. But there'll be some way to execute common actions, change common properties. We're also brainstorming, do we add a toolbar to the top of the XAML designer, maybe for like Elemental Lyman, bold, italic, maybe move some of these, very common, like these common changes, bold, italic font, like style, these style changes are pretty much common to every single control that has the ability to be bold or italicized. So maybe we add something more generic, even we're really invested to make the designer flow better for folks because we know that kind of ruins the designer for a lot of people. They click on a control, they have to go to properties, they have to search. Like man, it's easier just to go change XAML at that point, especially if the properties are very far apart. By making this thing here, just be click, click, click, click, click, click, it, the flow speeds up a lot. We're testing it internally. And our time to change a screen can go from like five minutes to like one minute. Like that's super, super productive, especially for the folks that don't know XAML super well. So we're really excited to ship this as well. And there you go, the list is done. Yay, we went through all the lists. All right, cool stuff. So again, everything except the extension and this sneak preview is in 16.4 and much of it was in preview three, right? 16.4 hasn't shipped yet. 16.4 preview three. And often the stuff was in there before. Yes. Cool. Yeah. Thanks for coming back on the show. I'm excited to be back again. I hope to be back maybe every three months or something and talk about new features. We have so much for working on. All right, great. Hope you enjoyed that and we will see you next time on Visual Studio Toolbox. Thank you, folks.