Develop Reference

WPF Always On Top

Is it possible to make a window stay always on top even when other application is running on Fullscreen? I'm using right now TopMost = true but when other application is running on fullscreen mine becomes invisible. It's WindowStyle = None window by the way.
Edit: And do not let other window minimalize ofcourse

This won't work 100% of the time, but it will improve the situation somewhat. You can set Topmost = true in the handler for the Window.Deactivated event:
private void Window_Deactivated(object sender, EventArgs e)
{
Window window = (Window)sender;
window.Topmost = true;
}
The Deactivated event will be called whenever your application loses focus (often when another application requests to be Topmost) and so this will reset your application on top after this.

Try this solution from MSDN, it should work for you.
In the Window Activated Event add the following code:
this.Width = System.Windows.SystemParameters.PrimaryScreenWidth;
this.Height = System.Windows.SystemParameters.PrimaryScreenHeight;
this.Topmost = true;
this.Top = 0;
this.Left = 0;
in DeActivated Event add the following code
this.Topmost = true;
this.Activate();
Original post from MSDN

None of the solutions above for me worked, so here is what I ended up doing. It worked perfectly for me.
Basically, to keep it on top you just set the lose focus event to make it go back to top.
XAML:
PreviewLostKeyboardFocus="Window_PreviewLostKeyboardFocus"
Code Behind:
private void Window_PreviewLostKeyboardFocus(object sender, KeyboardFocusChangedEventArgs e)
{
var window = (Window)sender;
window.Topmost = true;
}

If you want your application to stay on top of EVERYTHING (including the start interface in Windows 8, previously known as "Metro"), then you can specify UiAccess="True" in your manifest file. This is typically used by accessibility applications such as onscreen keyboards.
From memory you need to do 3 things;
Request UiAccess="True"
Sign your application's exe file with a recognised certificate. I obtained a free code signing certificate from Certum as my project is Open Source.
Install your application to a "Trusted Location", which in my case was the program files directory. There is no official definition of "Trusted Location" that I could find.

So I ran into the same requirement recently. It seems the top rated answer as well as the second didn't properly work for me. I've found a solution that seems to work flawlessly and somewhat adheres to best practice using MVVM.
Using the below forces the window to the top and never lapses on change like the other solutions.
Step 1: I created a simple state manager class for my main client window. I used INotifyPropertyChanged to keep property in sync when using a direct binding to my window. (very important)
public class ClientStateManager : INotifyPropertyChanged
{
#region Private Variables
private bool isForceToTop;
private bool isClientEnabled;
#endregion
#region Public Properties
public bool IsForceToTop
{
get { return isForceToTop; }
set
{
isForceToTop = value;
NotifyPropertyChanged();
}
}
public bool IsClientEnabled
{
get { return isClientEnabled; }
set
{
isClientEnabled = value;
NotifyPropertyChanged();
}
}
#endregion
#region Private Methods
private void NotifyPropertyChanged([CallerMemberName] String propertyName = "")
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
#endregion
#region Public Methods
public void Lock() => this.IsClientEnabled = false;
public void UnLock() => this.IsClientEnabled = true;
public void SetTop() => this.IsForceToTop = true;
public void UnSetTop() => this.IsForceToTop = false;
#endregion
#region Public Events
public event PropertyChangedEventHandler PropertyChanged;
#endregion
}
Step 2.1: Added my state manager class to my ViewModel. (MVVM)
internal class MainWindowViewModel : INotifyPropertyChanged
{
#region Constructor
public MainWindowViewModel()
{
ClientStateManager = new ClientStateManager();
}
#endregion
#region Public Properties
public ClientStateManager ClientStateManager { get; private set; }
#endregion
}
Step 2.2: Then set your window data context to your view model.
private MainWindowViewModel model;
private MainWindow()
{
InitializeComponent();
this.model = new MainWindowViewModel();
this.DataContext = model;
}
Step 3: Add your data binding to your window.
<Window x:Class="Intouch_Work.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:ojects="clr-namespace:Framework.Object;assembly=Framework"
xmlns:materialDesign="http://materialdesigninxaml.net/winfx/xaml/themes"
mc:Ignorable="d"
Title="Intouch" Height="800" Width="1100"
x:Name="mainWindow"
Topmost="{Binding Path=ClientStateManager.IsForceToTop, Mode=OneWay, UpdateSourceTrigger=PropertyChanged}">
So now you can manage your window state using the state manager object initialized within the View Model. You can call SetTop() from you state manager to push it forward, or UnSetTop() to stop it.
Hope this helps anyone looking to do the same.

I needed something similar for an industrial quality control application, where non-admin operators should not be able to minimize or use anything else on the dedicated computer while the application is running, not even Windows+D to bring up the desktop. And I found out that the cleanest and simplest way to achieve that is through:
Settings the correct Width, Height, WindowStyle, WindowState and Topmost properties.
Handling some related events: StateChanged, Deactivated, LostFocuse, LostMouseCapture, LostKeyboardFocus and PreviewLostKeyboardFocus.
Handling closing events with ALT+F4 or a custom button).
No need for P/Invoke, Here is the full code:
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
Loaded += OnLoaded;
Closing += OnClosing;
StateChanged += OnStateChanged;
Deactivated += (sender, args) => Activate();
LostFocus += (sender, args) => Focus();
LostMouseCapture += (sender, args) => Mouse.Capture(this);
LostKeyboardFocus += (sender, args) => Keyboard.Focus(this);
PreviewLostKeyboardFocus += (sender, args) => Keyboard.Focus(this);
}
private void OnLoaded(object sender, RoutedEventArgs e)
{
Width = SystemParameters.PrimaryScreenWidth;
Height = SystemParameters.PrimaryScreenHeight;
WindowStyle = WindowStyle.None;
WindowState = WindowState.Maximized;
Topmost = true;
// Other stuff here
}
private void OnClosing(object sender, CancelEventArgs e)
{
// You might want to allow only some users to close the app
if (MessageBox.Show("Are you an admin?", "Admin Check", MessageBoxButton.YesNo, MessageBoxImage.Warning) == MessageBoxResult.No)
e.Cancel = true;
}
private void OnStateChanged(object sender, EventArgs e)
{
if (WindowState == WindowState.Minimized)
WindowState = WindowState.Maximized;
}
}
You can also put some of this in XAML:
<Window x:Class="FullScreen.MainWindow"
...
Title="MainWindow"
WindowState="Maximized"
WindowStyle="None"
Topmost="True">
<Grid>
</Grid>
</Window>

I had a main window that I wanted to keep on top of everything (if the user checked "always on top".
This worked for me. Hope this helps someone.
// If we want main to stay on top, we set the rest of the menus to Not be top
if (mnuViewMainWindowAlwaysOnTopo.IsChecked)
{
this.Topmost = true;
foreach (var window in Application.Current.Windows)
// Don't change for main window
if (window.GetType().Name != this.GetType().Name)
window.Topmost = false;
}
else this.Topmost = false;

Can you fire events with automatic properties?

I was wondering if I can use automatic properties and still be able to fire events on property changed. Here are my current classes. (The actual User class got way more properties/fields of course).
public delegate void UserEventHandler(object sender, EventArgs e);
public class User
{
public event UserEventHandler Changed;
private string _UserName;
public string UserName
{
get
{
return _UserName;
}
private set
{
_UserName = value;
this.OnChanged(EventArgs.Empty);
}
}
protected void OnChanged(EventArgs e)
{
if (Changed != null)
{
Changed(this, e);
}
}
}
So I was wondering if there is a way I could take advantage of the automatic properties and still be able to fire the OnChanged events.
In other words : Are semi-automatic properties possible?

You can use PostSharp.
Example

Very late to the party, but this question still appears on google.
There's a package which works in much the same way as the PostSharp example, but is free: Fody.Propertychanged.
The project's README, and the wiki pages it links to, do a very good job of explaining it.

I modified your code a little for the event can be accessed and using the ready made EventHandler.
public class User
{
public event EventHandler AgeChanged;
private string _UserName;
public string UserName
{
get
{
return _UserName;
}
set
{
_UserName = value;
this.OnAgeChanged(this,EventArgs.Empty);
}
}
protected virtual void OnAgeChanged(object sender, EventArgs e)
{
if (AgeChanged != null)
{
AgeChanged(sender, e);
}
}
}
How to Set Events:
var user = new User();
//subscribe to events
user.AgeChanged+= (s,e) => Console.WriteLine("UserNamed changed to {0}",user.UserName);
//modify UserName and now event is fired
user.UserName="Jack";
see a working demo

Good or bad practice for Dialogs in wpf with MVVM?

I lately had the problem of creating add and edit dialogs for my wpf app.
All I want to do in my code was something like this. (I mostly use viewmodel first approach with mvvm)
ViewModel which calls a dialog window:
var result = this.uiDialogService.ShowDialog("Dialogwindow Title", dialogwindowVM);
// Do anything with the dialog result
How does it work?
First, I created a dialog service:
public interface IUIWindowDialogService
{
bool? ShowDialog(string title, object datacontext);
}
public class WpfUIWindowDialogService : IUIWindowDialogService
{
public bool? ShowDialog(string title, object datacontext)
{
var win = new WindowDialog();
win.Title = title;
win.DataContext = datacontext;
return win.ShowDialog();
}
}
WindowDialog is a special but simple window. I need it to hold my content:
<Window x:Class="WindowDialog"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
Title="WindowDialog"
WindowStyle="SingleBorderWindow"
WindowStartupLocation="CenterOwner" SizeToContent="WidthAndHeight">
<ContentPresenter x:Name="DialogPresenter" Content="{Binding .}">
</ContentPresenter>
</Window>
A problem with dialogs in wpf is the dialogresult = true can only be achieved in code. That's why I created an interface for my dialogviewmodel to implement it.
public class RequestCloseDialogEventArgs : EventArgs
{
public bool DialogResult { get; set; }
public RequestCloseDialogEventArgs(bool dialogresult)
{
this.DialogResult = dialogresult;
}
}
public interface IDialogResultVMHelper
{
event EventHandler<RequestCloseDialogEventArgs> RequestCloseDialog;
}
Whenever my ViewModel thinks it's time for dialogresult = true, then raise this event.
public partial class DialogWindow : Window
{
// Note: If the window is closed, it has no DialogResult
private bool _isClosed = false;
public DialogWindow()
{
InitializeComponent();
this.DialogPresenter.DataContextChanged += DialogPresenterDataContextChanged;
this.Closed += DialogWindowClosed;
}
void DialogWindowClosed(object sender, EventArgs e)
{
this._isClosed = true;
}
private void DialogPresenterDataContextChanged(object sender,
DependencyPropertyChangedEventArgs e)
{
var d = e.NewValue as IDialogResultVMHelper;
if (d == null)
return;
d.RequestCloseDialog += new EventHandler<RequestCloseDialogEventArgs>
(DialogResultTrueEvent).MakeWeak(
eh => d.RequestCloseDialog -= eh;);
}
private void DialogResultTrueEvent(object sender,
RequestCloseDialogEventArgs eventargs)
{
// Important: Do not set DialogResult for a closed window
// GC clears windows anyways and with MakeWeak it
// closes out with IDialogResultVMHelper
if(_isClosed) return;
this.DialogResult = eventargs.DialogResult;
}
}
Now at least I have to create a DataTemplate in my resource file(app.xaml or something):
<DataTemplate DataType="{x:Type DialogViewModel:EditOrNewAuswahlItemVM}" >
<DialogView:EditOrNewAuswahlItem/>
</DataTemplate>
Well thats all, I can now call dialogs from my viewmodels:
var result = this.uiDialogService.ShowDialog("Dialogwindow Title", dialogwindowVM);
Now my question, do you see any problems with this solution?
Edit: for completeness. The ViewModel should implement IDialogResultVMHelper and then it can raise it within a OkCommand or something like this:
public class MyViewmodel : IDialogResultVMHelper
{
private readonly Lazy<DelegateCommand> _okCommand;
public MyViewmodel()
{
this._okCommand = new Lazy<DelegateCommand>(() =>
new DelegateCommand(() =>
InvokeRequestCloseDialog(
new RequestCloseDialogEventArgs(true)), () =>
YourConditionsGoesHere = true));
}
public ICommand OkCommand
{
get { return this._okCommand.Value; }
}
public event EventHandler<RequestCloseDialogEventArgs> RequestCloseDialog;
private void InvokeRequestCloseDialog(RequestCloseDialogEventArgs e)
{
var handler = RequestCloseDialog;
if (handler != null)
handler(this, e);
}
}
EDIT 2: I used the code from here to make my EventHandler register weak:
http://diditwith.net/2007/03/23/SolvingTheProblemWithEventsWeakEventHandlers.aspx
(Website no longer exists, WebArchive Mirror)
public delegate void UnregisterCallback<TE>(EventHandler<TE> eventHandler)
where TE : EventArgs;
public interface IWeakEventHandler<TE>
where TE : EventArgs
{
EventHandler<TE> Handler { get; }
}
public class WeakEventHandler<T, TE> : IWeakEventHandler<TE>
where T : class
where TE : EventArgs
{
private delegate void OpenEventHandler(T #this, object sender, TE e);
private readonly WeakReference mTargetRef;
private readonly OpenEventHandler mOpenHandler;
private readonly EventHandler<TE> mHandler;
private UnregisterCallback<TE> mUnregister;
public WeakEventHandler(EventHandler<TE> eventHandler,
UnregisterCallback<TE> unregister)
{
mTargetRef = new WeakReference(eventHandler.Target);
mOpenHandler = (OpenEventHandler)Delegate.CreateDelegate(
typeof(OpenEventHandler),null, eventHandler.Method);
mHandler = Invoke;
mUnregister = unregister;
}
public void Invoke(object sender, TE e)
{
T target = (T)mTargetRef.Target;
if (target != null)
mOpenHandler.Invoke(target, sender, e);
else if (mUnregister != null)
{
mUnregister(mHandler);
mUnregister = null;
}
}
public EventHandler<TE> Handler
{
get { return mHandler; }
}
public static implicit operator EventHandler<TE>(WeakEventHandler<T, TE> weh)
{
return weh.mHandler;
}
}
public static class EventHandlerUtils
{
public static EventHandler<TE> MakeWeak<TE>(this EventHandler<TE> eventHandler,
UnregisterCallback<TE> unregister)
where TE : EventArgs
{
if (eventHandler == null)
throw new ArgumentNullException("eventHandler");
if (eventHandler.Method.IsStatic || eventHandler.Target == null)
throw new ArgumentException("Only instance methods are supported.",
"eventHandler");
var wehType = typeof(WeakEventHandler<,>).MakeGenericType(
eventHandler.Method.DeclaringType, typeof(TE));
var wehConstructor = wehType.GetConstructor(new Type[]
{
typeof(EventHandler<TE>), typeof(UnregisterCallback<TE>)
});
IWeakEventHandler<TE> weh = (IWeakEventHandler<TE>)wehConstructor.Invoke(
new object[] { eventHandler, unregister });
return weh.Handler;
}
}

This is a good approach and I used similar ones in the past. Go for it!
One minor thing I'd definitely do is make the event receive a boolean for when you need to set "false" in the DialogResult.
event EventHandler<RequestCloseEventArgs> RequestCloseDialog;
and the EventArgs class:
public class RequestCloseEventArgs : EventArgs
{
public RequestCloseEventArgs(bool dialogResult)
{
this.DialogResult = dialogResult;
}
public bool DialogResult { get; private set; }
}

I've been using an almost identical approach for several months now, and I'm very happy with it (i.e. I haven't yet felt the urge to rewrite it completely...)
In my implementation, I use a IDialogViewModel that exposes things such as the title, the standad buttons to show (in order to have a consistent apparence across all dialogs), a RequestClose event, and a few other things to be able to control the window size and behavior

If you are talking about dialogue windows and not just about the pop-up message boxes, please consider my approach below. The key points are:
I pass a reference to Module Controller into the constructor of each ViewModel (you can use injection).
That Module Controller has public/internal methods for creating dialogue windows (just creating, without returning a result). Hence to open a dialogue window in ViewModel I write: controller.OpenDialogEntity(bla, bla...)
Each dialogue window notifies about its result (like OK, Save, Cancel, etc.) via Weak Events. If you use PRISM, then it's easier to publish notifications using this EventAggregator.
To handle dialogue results, I'm using subscription to notifications (again Weak Events and EventAggregator in case of PRISM). To reduce dependency on such notifications, use independent classes with standard notifications.
Pros:
Less code. I don't mind using interfaces, but I've seen too many projects where excessiveness of using interfaces and abstraction layers cause more trouble than help.
Open dialogue windows through Module Controller is a simple way to avoid strong references and still allows to use mock-ups for testing.
Notification through weak events reduce number of potential memory leaks.
Cons:
Not easy to distinguish required notification from others in the handler. Two solutions:
send a unique token on opening a dialogue window and check that token in the subscription
use generic notification classes <T> where T is enumeration of entities (or for simplicity it can be type of ViewModel).
For a project should be an agreement about using notification classes to prevent duplicating them.
For enormously large projects the Module Controller can be overwhelmed by methods for creating windows. In this case it's better to split it up in several modules.
P.S. I have been using this approach for quite a long time now and ready to defend its eligibility in comments and provide some examples if required.

C# Variable labels?

Say I have a box that says ENABLED or DISABLED.
How can I make the text vary depending on a state?

public void CheckBox1CheckedChanged(object sender, EventArgs e)
{
if (checkBox1.Checked) {
checkBox1.Text = "Enabled";
}
else {
checkBox1.Text = "Disabled";
}
}

box.Text = (box.Enabled ? "ENABLED" : "DISABLED");

If I understand correctly, you are asking how to have a label or some other bit of UI text automatically update to reflect a "state variable". This is just one way to accomplish what you're describing:
I would do it by having a central state object which implements INotifyPropertyChanging and INotifyPropertyChanged. When your application initializes, attach event handlers to the events those interfaces expose, and one of those event handlers can change the text of the label when property (Foo) changes.
public class State : INotifyPropertyChanging, INotifyPropertyChanged
{
public event PropertyChangingEventHandler PropertyChanging;
public event PropertyChangedEventHandler PropertyChanged;
protected void OnPropertyChanging(PropertyChangingEventArgs e)
{
if (this.PropertyChanging != null)
{
this.PropertyChanging(this, e);
}
}
protected void OnPropertyChanged(PropertyChangedEventArgs e)
{
if (this.PropertyChanged != null)
{
this.PropertyChanged(this, e);
}
}
public bool Foo
{
get
{
return foo;
}
set
{
if (value != foo)
{
this.OnPropertyChanging(new PropertyChangingEventArgs("Foo"));
foo = value;
this.OnPropertyChanged(new PropertyChangedEventArgs("Foo"));
}
}
}
private bool foo = false;
}
protected void HandleStateChanged(object sender, PropertyChangedEventArgs e)
{
if(e.PropertyName == "Foo")
{
box.Text = state.Foo ? "Enabled" : "Disabled";
}
}

What jeffamaphone said, but I should add that any time that state changes you will have to make sure to run that same code. The easiest way to insure this happens is by binding the box.Text property to the state object that you are interested in. That way, any change made to the object is immediately reflected in the text.
This blog post
helped me get started with data binding.... because I love FAQs.

The last few months I have been going with a slightly lighter weight solution than implementing a whole class to manage state. I usually define an enum which indicates the types of states available in the UI, then I have a function that makes changes to the UI, based on the state selected. This approach has been very successful, and not too heavy in terms of the amount of code needed to be written.
If I want to know what states are available in the UI, I can check the values of the enum.
public enum SystemState
{
/// <summary>
/// System is under the control of a remote logging application.
/// </summary>
RemoteMode,
/// <summary>
/// System is not under the control of a remote logging application.
/// </summary>
LocalMode
}
public interface IView
{
void SetState(SystemState state);
}
//method on the UI to modify UI
private void SetState(SystemState state)
{
switch (state)
{
case SystemState.LocalMode:
//for now, just unlock the ui
break;
case SystemState.RemoteMode:
//for now, just lock the ui
break;
default:
throw new Exception("Unknown State requested:" + state);
}
}
//now when you change state, you can take advantage of intellisense and compile time checking:
public void Connect()
{
SetState(SystemState.RemoteMode);
}

How to Enable/Disable MenuItem and ToolButton together

I'm a newbie in C# bu I'm experienced Delphi developer.
In Delphi I can use same code for MenuItem and ToolButton using TAction.OnExecute event and I can disable/enable MenuItem and ToolButton together using TAction.OnUpdate event.
Is there a similar way to do this in C# without using external libraries? Or more - How C# developers share code between different controls?
Ok, may be I write my question in wrong way. I want to know not witch property to use (I know about Enabled property) but I want to know on witch event I should attach to if I want to enable/disable more than one control. In delphi TAction.OnUpdate event ocurs when Application is idle - is there similar event in C#?

Try the a modification of the command pattern:
public abstract class ToolStripItemCommand
{
private bool enabled = true;
private bool visible = true;
private readonly List<ToolStripItem> controls;
protected ToolStripItemCommand()
{
controls = new List<ToolStripItem>();
}
public void RegisterControl(ToolStripItem item, string eventName)
{
item.Click += delegate { Execute(); };
controls.Add(item);
}
public bool Enabled
{
get { return enabled; }
set
{
enabled = value;
foreach (ToolStripItem item in controls)
item.Enabled = value;
}
}
public bool Visible
{
get { return visible; }
set
{
visible = value;
foreach (ToolStripItem item in controls)
item.Visible = value;
}
}
protected abstract void Execute();
}
Your implementations of this command can be stateful in order to support your view's state. This also enables the ability to build "undo" into your form. Here's some toy code that consumes this:
private ToolStripItemCommand fooCommand;
private void wireUpCommands()
{
fooCommand = new HelloWorldCommand();
fooCommand.RegisterControl(fooToolStripMenuItem, "Click");
fooCommand.RegisterControl(fooToolStripButton, "Click");
}
private void toggleEnabledClicked(object sender, EventArgs e)
{
fooCommand.Enabled = !fooCommand.Enabled;
}
private void toggleVisibleClicked(object sender, EventArgs e)
{
fooCommand.Visible = !fooCommand.Visible;
}
HelloWorldCommand:
public class HelloWorldCommand : ToolStripItemCommand
{
#region Overrides of ControlCommand
protected override void Execute()
{
MessageBox.Show("Hello World");
}
#endregion
}
It's unfortunate that Control and ToolStripItem do not share a common interface since they both have "Enabled" and "Visible" properties. In order to support both types, you would have to composite a command for both, or use reflection. Both solutions infringe on the elegance afforded by simple inheritance.

You can enable or disable a control and all its children by setting its Enabled property.

You can hook the code for the MenuItem and the ToolButton in the same handler. For example:
menuItem.Click += HandleClick;
toolbarButton.Click += handleClick;
This way clicking both the MenuItem and the Button will execute the same code and provide the same functionality.