I use the following code to show my WPF window from the new message window in Outlook:
private void DisplayWindow(Window window) {
var wih = new System.Windows.Interop.WindowInteropHelper(window);
wih.Owner = GetForegroundWindow();
window.ShowInTaskbar = false;
window.ShowDialog();
}
[DllImport("user32.dll")]
private static extern IntPtr GetForegroundWindow();
My problem is that when ToolTips and ComboBox drop downs become visible, the WPF window disappears behind the new message window, leaving just the "popup" content in front. Could anyone explain why this might be happening, and what the correct way to host the window might be?
EDIT:
This only happens once a recipient has been added to the Send box and seems to only be a problem when the foreground window is the new mail message window.
To replicate:
Add an Outlook Add-in project and a WPF project (targeting .NET 4.0) to a new solution.
Put a ComboBox with a few items in it on the MainWindow.xaml.
Remove the StartupUri from App.xaml and add the following to App.cs.
public void ShowWindow() {
MainWindow window = new MainWindow();
var wih = new System.Windows.Interop.WindowInteropHelper(window);
wih.Owner = GetForegroundWindow();
window.ShowInTaskbar = false;
window.ShowDialog();
}
[DllImport("user32.dll")]
private static extern IntPtr GetForegroundWindow();
Add references to WindowsBase, System.Xaml and PresentationFramework to the Outlook project.
Add a Ribbon (XML) to the Outlook project with the following in the .xml.
<customUI ...>
<ribbon>
<tabs>
<tab idMso="TabNewMailMessage">
<group id="MyGroup"
insertAfterMso="GroupMailNew">
<button id="myButton"
size="large"
onAction="myButton_Action"
imageMso="HappyFace"/>
</group>
</tab>
</tabs>
</ribbon>
</customUI>
Add the following to the ribbon code.
MyWpfApplication.App app;
public void Ribbon_Load(Office.IRibbonUI ribbonUI) {
this.ribbon = ribbonUI;
var appThread = new Thread(new ThreadStart(() => {
this.app = new MyWpfApplication.App();
app.ShutdownMode = System.Windows.ShutdownMode.OnExplicitShutdown;
app.Run();
}));
appThread.SetApartmentState(ApartmentState.STA);
appThread.Start();
}
public void myButton_Action(Office.IRibbonControl control) {
// Dispatcher used as cross thread operation.
app.Dispatcher.BeginInvoke((Action)(() => {
app.ShowWindow();
}));
}
Add the following to ThisAddIn
protected override Microsoft.Office.Core
.IRibbonExtensibility CreateRibbonExtensibilityObject() {
return new Ribbon();
}
Run the Outlook add-in, create a new message, add a recipient and click on the smiley face button. You will see the bug when you click on the ComboBox.
Perhaps you are encountering the infamous "airspace" issue. See here, here and here. There were high hopes that it would be fixed in .NET 4.5, but sadly these were dashed when MS announced that the fix itself was too buggy to release.
It may be the same issue described here:
The WPF dialog box disappears when it displays a tooltip or drop-down combo box in Windows 8 or Windows Server 2012
Source codes of .NET Framework 4.7.1 have comment in System.Windows.FrameworkCompatibilityPreferences class, saying there is a bug in the Windows desktop window manager which can cause incorrect z-order for windows on some conditions.
The suggested workaround is to add the following code to the WPF application’s app.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="UseSetWindowPosForTopmostWindows" value="True" />
</appSettings>
</configuration>
Related
The application is working fine when i run it from Visual Studio but if i run my application when its published it crashes. This is the first application i have published so i dont know where to start.
I have 2 combo boxes that let you choose the theme color of the application as soon as i choose one it crashes.
This is using Mahapps Metro
The combobox's item source is a metro thememanager
ItemsSource="{x:Static metro:ThemeManager.Accents}"
This is the Selection Changed code
private void ColorsSelectorOnSelectionChanged(object sender, SelectionChangedEventArgs e)
{
var selectedColor = this.ColorsSelector.SelectedItem as KeyValuePair<string, Color>?;
if (selectedColor.HasValue)
{
var theme = ThemeManager.DetectAppStyle(Application.Current);
ThemeManagerHelper.CreateAppStyleBy(selectedColor.Value.Value, true);
Application.Current.MainWindow.Activate();
}
When creating a runtime accent resource dictionary:
I have a WPF user control like this...
namespace WpfApplication1
{
public partial class MyControl : UserControl
{
......
}
}
I also have a win form to contain this WPF user control...
namespace WindowsFormsApplication4
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
ElementHost ctrlHost = new ElementHost();
ctrlHost.Dock = DockStyle.Fill;
WpfApplication1.MyControl win = new WpfApplication1.MyControl();
ctrlHost.Child = win;
this.Controls.Add(ctrlHost);
}
}
}
I have one more parent win form that has a button. Clicking the button will open the Form1 that contains the ElementHost.
namespace WindowsFormsApplication4
{
public partial class Parent : Form
{
public Parent()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form1 form1 = new Form1();
form1.Show();
}
}
}
My application runs the Parent form by default...
Application.Run(new Parent());
The problem I'm facing is strange. When i run the application, the parent form opens and on clicking the button the child window form containing the WPF control also opens. But the problem is the size of parent form window automatically shrinks(the window displaces, restores itself and the controls and font becomes smaller in it.) as soon as the WPF control form pops up. If I comment the content of the 'Form1_Load' function then the parent window does not shrink. To check the worst case i commented everything in 'Form1_Load' except
ElementHost ctrlHost = new ElementHost();
line. The mere presence of this line itself makes the parent form shrink as I mentioned earlier. I tried to search in internet for this problem extensively. I was not able to find a solution. Please help me with a answer. I'm exhausted....
I commented above that I had the same issue and have since resolved it. I'm writing up my changes here for anyone else.
As observed above, the behaviour seems to occur whenever using Windows UI scaling in an WinForms application and the Just In Time (JIT) Compiler processes anything from the WPF libraries. In my case, entering a method that contains code that opens the WPF version of MessageBox will make it happen.
Ordinarily Windows will handle basic scaling for you, rendering to a bitmap offscreen and then drawing it on screen but scaled up. When WPF loads it seems to take over, as if it's saying to Windows, "Hey.. i got this..". After that Windows stops scaling the WinForms for you and you end up with the 1x scale version and often some confused controls. The WPF portion however is handling its own scaling and looks fine.
So the way I went about solving it was to tell Windows that I would handle the WinForms scaling. To enable that you have to add this to your application manifest (dll manifest is ignored)
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
OR uncomment the following section if it is already in there:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
You can add a manifest file:
Right click on application project -> Add -> New item... -> Application Manifest File
Then in...
Application Project -> Properties -> Application -> Resources
Make sure "Manifest" is set to app.manifest
You can now find that file and add the XML above into the root <asmv1:assembly>element.
If you've taken the default application manifest and added that element it probably looks something like this
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetReference="Custom" />
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" ID="Custom" SameSite="site" />
</applicationRequestMinimum>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</asmv1:assembly>
Now when you start your WinForms app you will notice it's much crisper because it's being rendered at high dpi instead of 96dpi and then scaled up to fill the space.
You'll probably notice that a lot of your images have shrunk!!
In my case Buttons, MenuStripItems and ToolStripItems did not scale as desired.
What I found was that most controls have a method that you can override as below
protected override void ScaleControl(SizeF factor, BoundsSpecified specified)
{
base.ScaleControl(factor, specified);
}
This is called when the application launches and filters through your controls from the main form. My Windows is set to 200%, my main form's scaling mode was set to DPI and all the forms were designed at 100% scale (96dpi). I changed everything in my first attempts to fix the problem to inherit the scaling mode and this was what worked for me, if you're using font or none i suspect it will work just the same but I haven't tried it.
As mine was 200% UI scaling when this method was called factor was simply {2.0, 2.0} which I then used to recreate a scaled Image in Buttons, and to increase the ImageScalingSize on each of the Items of MenuStrip and ToolStrip since these do not receive the ScaleControl call. If you never added the XML above then this method is still called but will only ever have {1.0, 1.0} for factor, which isn't helpful.
Note: if you're using image list then don't dynamically set the image if in DesignMode or the ImageList will become unset and when you save then nothing will be set
Also not that factor is a factor from the current. What you will notice is if you move the application between different dpi monitors you will get 2.0, then 0.5, then 2.0, then 0.5, etc.
Now my WinForms application looks super crisp and it can call WPF ui elements without going crazy! yyayyyyy
Hope this helps someone
In Visual Studio 2010, Dockable Windows seem to work like expected in every situation.
If a "Floating" document is active and some menu is selected (e.g Edit -> Paste), then the "Floating" document still has Focus and the command will be executed against that "Floating" window. Also, notice how this is clearly visible in the UI. MainWindow.xaml is still active and the Main window in Visual Studio is inactive even though the Team-menu is selected.
I've been trying to get the same behavior using alot of different 3rd-party docking components but they all have the same problem: once I select the menu, the MainWindow is focused and my floating window does not have focus anymore. Does anyone know of a way to get the same behavior here as in Visual Studio?
At the moment I'm using Infragistics xamDockManager and the problem can be reproduced with the following sample code.
Right click "Header 1" and select "Float"
Click the "File" menu
Notice how MainWindow receives focus.
xmlns:igDock="http://infragistics.com/DockManager"
<DockPanel LastChildFill="True">
<Menu DockPanel.Dock="Top">
<MenuItem Header="_File">
<MenuItem Header="_New"/>
</MenuItem>
</Menu>
<Grid>
<igDock:XamDockManager x:Name="dockManager" Theme="Aero">
<igDock:DocumentContentHost>
<igDock:SplitPane>
<igDock:TabGroupPane>
<igDock:ContentPane Header="Header 1">
<TextBox Text="Some Text"/>
</igDock:ContentPane>
<igDock:ContentPane Header="Header 2">
<TextBox Text="Some Other Text"/>
</igDock:ContentPane>
</igDock:TabGroupPane>
</igDock:SplitPane>
</igDock:DocumentContentHost>
</igDock:XamDockManager>
</Grid>
</DockPanel>
The visual studio team has some good information on lessons they learned when making VS in WPF. One of the issues they ran into was related to Focus management. As a result, WPF 4 has some new features to help out.
Here's the info on the issue that sounds like your situation:
http://blogs.msdn.com/b/visualstudio/archive/2010/03/09/wpf-in-visual-studio-2010-part-3-focus-and-activation.aspx
Their discussion of the new "HwndSource.DefaultAcquireHwndFocusInMenuMode" property sounds very similar to what you're running into.
EDIT
After further investigation, it looks like Visual Studio might be hooking the windows message loop and returning specific values to make the floating windows work.
I'm not a win32 programmer, but it seems that when a user clicks a menu in an inactive window, windows sends the WM_MOUSEACTIVATE message to it before processing the mouse down event. This lets the main window determine whether it should be activated.
In my unmodified WPF test app, the inactive window returns MA_ACTIVATE. However, VS returns MA_NOACTIVATE. The docs indicate that this tells windows NOT to activate the main window prior to handling further input. I'm guessing that visual studio hooks the windows message loop and returns MA_NOACTIVATE when the user clicks on the menus / toolbars.
I was able to make this work in a simple, two window WPF app by adding this code to the top level window.
protected override void OnSourceInitialized(EventArgs e)
{
base.OnSourceInitialized(e);
var hook = new HwndSourceHook(this.FilterMessage);
var source2 = HwndSource.FromVisual(this) as HwndSource;
source2.AddHook(hook);
}
private IntPtr FilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
const int WM_MOUSEACTIVATE = 0x0021;
const int MA_NOACTIVATE = 3;
switch (msg)
{
case WM_MOUSEACTIVATE:
handled = true;
return new IntPtr(MA_NOACTIVATE);
}
return IntPtr.Zero;
}
In your case, you'd probably need to add more logic that would check what the user clicked on and decide based on that whether to intercept the message and return MA_NOACTIVATE.
EDIT 2
I've attached a sample WPF application that shows how to do this with a simple WPF application. This should work pretty much the same with floating windows from a docking toolkit, but I haven't tested that specific scenario.
The sample is available at: http://blog.alner.net/downloads/floatingWindowTest.zip
The sample has code comments to explain how it works. To see it in action, run the sample, click the "open another window" button. This should put focus in the textbox of the new window. Now, click the edit menu of the main window and use the commands like "select all". These should operate on the other window without bringing the "main window" to the foreground.
You can also click on the "exit" menu item to see that it can still route commands to the main window if needed.
Key Points (Activation / Focus):
Use the HwndSource.DefaultAcquireHwndFocusInMenuMode to get the menus to work stop grabbing focus.
Hook the message loop and return "MA_NOACTIVATE" when the user clicks the menu.
Add an event handler to the menu's PreviewGotKeyboardFocus and set e.Handled to true so that the menu wont' attempt to grab focus.
Key Points (Commands):
Hook the main window's "CommandManager.PreviewCanExecute" and "CommandManager.PreviewExecuted" events.
In these events, detect whether the app has an "other window" that's supposed to be the target of events.
Manually invoke the original command against the "other window".
Hope it works for you. If not, let me know.
I used the great answer from NathanAW and created a ResourceDictionary containing a Style for Window (which should be used by the MainWindow), contained the key pieces to solve this problem.
Update: Added support for ToolBar as well as Menu
It includes hit testing specifically for the MainMenu or ToolBar to decide if focusing should be allowed.
The reason I've used a ResourceDictionary for this is for reusability since we will be using this in many projects. Also, the code behind for the MainWindow can stay clean.
MainWindow can use this style with
<Window...>
<Window.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="NoFocusMenuWindowDictionary.xaml"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Window.Resources>
<Window.Style>
<StaticResource ResourceKey="NoFocusMenuWindow"/>
</Window.Style>
<!--...-->
</Window>
NoFocusMenuWindowDictionary.xaml
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="MainWindowVS2010Mode.NoFocusMenuWindowDictionary">
<Style x:Key="NoFocusMenuWindow" TargetType="Window">
<EventSetter Event="Loaded" Handler="MainWindow_Loaded"/>
</Style>
<Style TargetType="Menu">
<EventSetter Event="PreviewGotKeyboardFocus"
Handler="Menu_PreviewGotKeyboardFocus"/>
</Style>
<Style TargetType="ToolBar">
<EventSetter Event="PreviewGotKeyboardFocus"
Handler="ToolBar_PreviewGotKeyboardFocus"/>
</Style>
</ResourceDictionary>
NoFocusMenuWindowDictionary.xaml.cs
namespace MainWindowVS2010Mode
{
public partial class NoFocusMenuWindowDictionary
{
#region Declaration
private static Window _mainWindow;
private static bool _mainMenuOrToolBarClicked;
#endregion // Declaration
void MainWindow_Loaded(object sender, RoutedEventArgs e)
{
_mainWindow = sender as Window;
HwndSource.DefaultAcquireHwndFocusInMenuMode = true;
Keyboard.DefaultRestoreFocusMode = RestoreFocusMode.None;
HwndSource hwndSource = HwndSource.FromVisual(_mainWindow) as HwndSource;
hwndSource.AddHook(FilterMessage);
}
private static IntPtr FilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
const int WM_MOUSEACTIVATE = 0x0021;
const int MA_NOACTIVATE = 3;
switch (msg)
{
case WM_MOUSEACTIVATE:
if (ClickedMainMenuOrToolBarItem())
{
handled = true;
return new IntPtr(MA_NOACTIVATE);
}
break;
}
return IntPtr.Zero;
}
#region Hit Testing
private static bool ClickedMainMenuOrToolBarItem()
{
_mainMenuOrToolBarClicked = false;
Point clickedPoint = Mouse.GetPosition(_mainWindow);
VisualTreeHelper.HitTest(_mainWindow,
null,
new HitTestResultCallback(HitTestCallback),
new PointHitTestParameters(clickedPoint));
return _mainMenuOrToolBarClicked;
}
private static HitTestResultBehavior HitTestCallback(HitTestResult result)
{
DependencyObject visualHit = result.VisualHit;
Menu parentMenu = GetVisualParent<Menu>(visualHit);
if (parentMenu != null && parentMenu.IsMainMenu == true)
{
_mainMenuOrToolBarClicked = true;
return HitTestResultBehavior.Stop;
}
ToolBar parentToolBar = GetVisualParent<ToolBar>(visualHit);
if (parentToolBar != null)
{
_mainMenuOrToolBarClicked = true;
return HitTestResultBehavior.Stop;
}
return HitTestResultBehavior.Continue;
}
public static T GetVisualParent<T>(object childObject) where T : Visual
{
DependencyObject child = childObject as DependencyObject;
while ((child != null) && !(child is T))
{
child = VisualTreeHelper.GetParent(child);
}
return child as T;
}
#endregion // Hit Testing
#region Menu
private void Menu_PreviewGotKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
{
Menu menu = sender as Menu;
if (menu.IsMainMenu == true)
{
e.Handled = true;
}
}
#endregion // Menu
#region ToolBar
private void ToolBar_PreviewGotKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
{
e.Handled = true;
}
#endregion // ToolBar
}
}
Just out of curiosity, have you tried binding the MenuItem.CommandTarget to the XamDockManager.ActivePane?
Looking at the XamDockManager documentation, I also see a CurrentFlyoutPane property which returns "the Infragistics.Windows.DockManager.ContentPane currently within the UnpinnedTabFlyout or null if the flyout is not shown." I'm not sure which property would be appropriate in your scenario, but it's worth a try.
I know this is an old post, but Prism could make your life so much easier. Using the RegionAdapter created here:
http://brianlagunas.com/2012/09/12/xamdockmanagera-prism-regionadapter/
You can easily track which window is active, floating or not, by using the IActiveAware interface. Prisms commands also take this into consideration and can excute commands only on the active view. The blog post has a sample app you can play around with.
Im not sure about how to make this work, but I do know the Infragistics have a great support forum so it may be worth asking there question there too.
http://forums.infragistics.com/
If I use Application.LoadComponent() to load a UserControl, Page or Window, my application freezes when I try to close it.
The app apparently closes, but the process keeps running. Easy to notice when debugging.
I've tested it under Windows 7 64bit and Vista 32bit. In both cases I have used VS2008 and .NET 3.5.
A repro can be built by creating a wpf application as follows:
public partial class Window1 : Window {
public Window1() {
InitializeComponent();
}
public void LoadCopy() {
var uri = new Uri("/WpfApplication1;component/window1.xaml", UriKind.Relative);
var copy = (Window)Application.LoadComponent(uri);
MessageBox.Show(copy.Title);
}
private void Button_Click(object sender, EventArgs e) {
LoadCopy();
}
}
Does anyone know what might be happening? And how to solve it?
Try assigning the owner to the created assembly i.e.
copy.Owner = this;
I was able to close your example after doing this.
I think it is because you are calling LoadComponent() on what is also your Main Window ( http://msdn.microsoft.com/en-us/library/system.windows.application.mainwindow.aspx ), i.e. the startup uri, in your case Window1. The program is probably entering some loop when you close it because closing a Main Window by default shuts down the Application and your two instances of Window1 are waiting on each other (A.K.A. a deadlock)! Albeit seemingly only after making the Application invisible (so it seems to have closed).
If you still must use use LoadComponent() on Window1 I think you would need to not make it your startup uri by changing the StartupUri of your Application:
<Application
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="Window1.xaml"> <!-- change this -->
</Application>
Or change Application.ShutdownMode ( http://msdn.microsoft.com/en-us/library/system.windows.application.shutdownmode.aspx ) to OnLastWindowClose:
<Application
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="Window1.xaml"
ShutdownMode="OnLastWindowClose">
</Application>
I have build you application on Windows 7 32bit under .Net 4.0 and 3.5.
I works fine for me. I think you problem is configuration specific.
Which configuration do you have? Do you reference any assemblies except default WPF project references?
I have a strange bug with WPF Interop and an Excel Addin. I'm using .Net 3.5 SP1.
I'm using Add-in Express to create a Custom Task Pane for Excel 2003. Within that taskpane I'm using ElementHost to host a WPF UserControl. The UserControl simply contains a Grid with a TextBox and ComboBox. My problem is that whilst everything displays properly, the ComboBox won't stay dropped-down unless I hold the mouse down over the down-arrow.
I don't believe this is necessarily related to Add-in Express because I've had a similar problem when I tried displaying a WPF window modelessly in Excel.
A second problem is that the ComboBox seems reluctant to give up focus. If I click it, the text area goes grey to indicate that it has focus, but I can't move focus anywhere else in the window. The only way to wrest focus away is to move the mousewheel.
Anybody else had a similar problem, and managed to fix it?
Add-in Express looked into this for me, and it turns out to have something to do with the Window style of the Task Pane that gets added to Excel. If you turn off the WS_CHILD flag in the Windows CreateParams then Combo Boxes and other popups work as expected.
They gave me this snippet of code to add to my ADXExcelTaskPane:
private const uint WS_CHILD = 0x40000000;
private const uint WS_CLIPCHILDREN = 0x02000000;
private const uint WS_CLIPSIBLINGS = 0x04000000;
private CreateParams _CreateParams = new CreateParams();
protected override CreateParams CreateParams
{
get
{
_CreateParams = base.CreateParams;
if (!DesignMode)
_CreateParams.Style = (int)(WS_CLIPCHILDREN | WS_CLIPSIBLINGS); //| WS_CHILD
return _CreateParams;
}
}
I had the same problem. I have a WPF user control hosted in a WinForm user control and the whole is an Excel AddIn. I work with Visual Studio 2010 and Excel 2007 and Excel 2010.
My problem was that when I clicked once in the Excel sheet, the AddIn never gains focus again.
I found a workaround.
In the constructor of my WinForm user control, I register on the event MouseEnter of my WPF user control.
In the MouseEnter event handler, I give the focus to myself (this.Focus())
public WpfContainerUserControl()
{
InitializeComponent();
GpecsBrowserTabUserControl gpecBrowser = elementHost1.Child as GpecsBrowserTabUserControl;
gpecBrowser.MouseEnter += new System.Windows.Input.MouseEventHandler(gpecBrowser_MouseEnter);
}
void gpecBrowser_MouseEnter(object sender, System.Windows.Input.MouseEventArgs e)
{
this.Focus();
}