I have WPF application and i want to add the option to do my stuff in commend line instead of open the GUI.
Any way to send my Application exe arguments and in case the arguments length in > 0 continue with command line instead of open the GUI ?
You could edit the App.xaml.cs file and override the OnStartup method:
public partial class App : Application
{
protected override void OnStartup(StartupEventArgs e)
{
string[] args = e.Args;
if(args.Length > 0 && args[0] == "cl")
{
//...
}
else
{
base.OnStartup(e);
Window2 mainWindow = new Window2();
mainWindow.Show();
}
}
}
You should also remove the StartupUri attribute from <Application> root element of the App.xaml file.
But if you want to be able to write to the console you need to create a console window manually:
No output to console from a WPF application?
Then you might as well create a console application in Visual Studio and instead start your WPF application based on the command line argument(s), e.g.:
public class Program
{
public static void Main(string[] args)
{
if (args.Length == 0 || args[0] != "cl")
{
System.Diagnostics.Process.Start(#"c:\yourWpfApp.exe");
}
else
{
//...
}
}
}
A console application is not a WPF application and vice versa. So create two different applications.
In your App.xaml.cs implement the OnStartup method. So you can access the arguments passed via command line.
protected override void OnStartup(StartupEventArgs e)
{
var args = e.Args;
// do anything with arguments
}
Related
I want to observe certain information about all windows in my app. I have a window that shows (via Observables) lots of information, but I can't find anything short of polling that will let me know all the windows (and also all open windows in my app).
Is there somewhere I can subscribe that would be a good hook for any windows getting shown (.Show() or .ShowDialog()) ?
You have to add references to UIAutomationClient.dll, UIAutomationTypes.dll.
On my machine, they are in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.
CommonWindow is used as your common window, which keeps changing its owner. I create modal windows, which can further create more modal windows, and latest one owns CommonWindow, I also set latest window as DataContext of CommonWindow.
using System;
using System.Windows;
using System.Windows.Automation;
using System.Threading;
namespace WpfApplication1
{
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
CommonWindow _commonWin = new CommonWindow();
private void Application_Startup(object sender, StartupEventArgs e)
{
Automation.AddAutomationEventHandler(
WindowPattern.WindowOpenedEvent,
AutomationElement.RootElement,
TreeScope.Children,
(s, e1) =>
{
Application.Current.Dispatcher.Invoke(() =>
{
var windows = Application.Current.Windows;
Window w = windows[windows.Count - 1];
w.Closing += w_Closing;
// First modal window is shown, so count now is 2 (>1)
if (App.Current.Windows.Count > 1)
{
_commonWin.Owner = w;
_commonWin.DataContext = w;
_commonWin.Show();
}
});
});
}
void w_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
// Comparison to 3 is important as there would be 3 windows when first modal window is shown
if (Application.Current.Windows.Count >= 3)
{
_commonWin.Owner = Application.Current.Windows[App.Current.Windows.Count - 2];
_commonWin.DataContext = Application.Current.Windows[App.Current.Windows.Count - 2];
}
else
{
_commonWin.Close();
}
}
}
}
CommonWindow is just a Window as CommonWindow.xaml just like normal xaml file with its code-behind.
I am having trouble using the WPF Extended Toolkit (version 2.1.0.0) MessageBox from other threads. The namespace is: Xceed.Wpf.Toolkit.MessageBox
I replaced my regular MessageBoxs (System.Windows.MessageBox) with the Toolkit MessageBox and get errors when I launch one from another thread. The System.Windows.MessageBox has no such problems. I saw this posting that reports the problem, but there seems to be no follow up:
https://wpftoolkit.codeplex.com/workitem/21046
I'm guessing there is a work around. An example is presented there that shows the problem, but here is my simple example:
First, I wrap the Toolkit.MessageBox. I do this primarily because I'm applying style (although I've commented that out to show that's not the problem)
public class CustomMessageBox
{
//static DummyUserControl1 _ctrl = new DummyUserControl1();
public static MessageBoxResult Show(string msgText, Style styleArg = null)
{
Cursor saveCursor = Mouse.OverrideCursor;
Mouse.OverrideCursor = null;
//Style style = styleArg != null ? styleArg : _ctrl.FindResource("MessageBoxStyle1") as Style;
// MessageBoxResult result = Xceed.Wpf.Toolkit.MessageBox.Show(msgText, "", MessageBoxButton.OK, style);
MessageBoxResult result = Xceed.Wpf.Toolkit.MessageBox.Show(msgText, "", MessageBoxButton.OK);
Mouse.OverrideCursor = saveCursor;
return result;
}
}
The main window just has two buttons on it, and here's the code behind:
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
private void btnMainThreadMsgBox_Click(object sender, RoutedEventArgs e)
{
CustomMessageBox.Show("Hello on main thread");
}
private void btnAltThreadMsgBox_Click(object sender, RoutedEventArgs e)
{
Thread altThread1 = new Thread(new ThreadStart(AltThread1Proc));
altThread1.SetApartmentState(ApartmentState.STA);
altThread1.Priority = ThreadPriority.AboveNormal;
altThread1.IsBackground = true;
altThread1.Start();
}
public void AltThread1Proc()
{
MessageBox.Show("Hello on Alt Thread");
CustomMessageBox.Show("Hello on alt thread");
}
}
The problems occur in AltThreadProc() with CustomMessageBox.Show(...). The curious behavior I referred to is this: If you hit the main thead button and then the Alt thread button, you get the error:
Cannot access Freezable 'System.Windows.Media.SolidColorBrush' across threads because it cannot be frozen.
However, if you skip the main thread button and just hit the Alt thread button, you get the error:
The calling thread cannot access this object because a different thread owns it.
I'm curious what the "Freezable" error is all about and why you can get different errors based on what would seem to be an innocuous event: clicking/not clicking button that produces message box on main thread.
Ideally, it would be nice to just replace System.Windows.MessageBox with Xceed.Wpf.Toolkit.MessageBox, but if there is some sort of extra code to write, that might be acceptable. The documentation, and the link I provided hints at using a WindowContainer, but I can't really see any examples of how you do that. I was attracted to the Toolkit MessageBox as it allows one to do some cool stuff with MessageBox (which I don't show here) such as apply styles, change the text of the OK, CANCEL button, etc.
Any ideas would be much appreciated.
Thanks,
Dave
Extra info:
User1341210 suggestion works well if you just have one window. However, if you have a second window in it's own thread it doesn't work so well. Perhaps someone can tell me what I'm doing wrong. I use the suggestion of the TaskScheduler, but the code throws an exception if the TaskScheduler used is the one of the second window. That is, all works fine if I use the TaskScheduler of the first window, but throws an exception if I use the TaskScheduler of the second window. Here is the code behind for my second window:
public partial class AltThreadWindow : Window
{
private TaskScheduler _ui;
public AltThreadWindow()
{
InitializeComponent();
_ui = TaskScheduler.FromCurrentSynchronizationContext();
}
// This constructor is for passing in the TaskScheduler of the mainwindow and works great
public AltThreadWindow(TaskScheduler scheduler)
{
InitializeComponent();
_ui = scheduler;
}
private void btnWindowsMsgBox_Click(object sender, RoutedEventArgs e)
{
MessageBox.Show("Standard Windows message box");
}
private void btnCustomMsgBox_Click(object sender, RoutedEventArgs e)
{
MessageBoxResult result;
Task.Factory.StartNew(() => { result = CustomMessageBox.Show("Custom MessageBox on separate window"); }, CancellationToken.None,
TaskCreationOptions.None,
_ui);
}
}
Notice the two constructors. The default one assigns the TaskScheduler of the second window. The other constructor allows one to pas in the TaskScheduler of the main Window.
Here's the code I use to launch the second window from the main window. Again, I'm launching the second window on another thread, and I pass in the TaskScheduler of the main window. It would be nice to use the TaskScheduler of the second window instead.
_altWindowThread = new Thread(new ThreadStart(AltWinThreadProc));
_altWindowThread.SetApartmentState(ApartmentState.STA);
_altWindowThread.Priority = ThreadPriority.AboveNormal;
_altWindowThread.IsBackground = true;
_altWindowThread.Start();
And the actual threadproc:
[EnvironmentPermissionAttribute(SecurityAction.LinkDemand, Unrestricted = true)]
public void AltWinThreadProc()
{
// Create our context, and install it:
SynchronizationContext.SetSynchronizationContext(
new DispatcherSynchronizationContext(
Dispatcher.CurrentDispatcher));
_altWindow = new AltThreadWindow(_ui);
_altWindow.Show();
System.Windows.Threading.Dispatcher.Run();
}
Notice here I pass in the TaskScheduler of the MainWindow.
we had the same issue in our application (I created the work item on codeplex).
The error messages are quite confusing and I cant provide you an answer to that.
But:
We didn't used a separated WindowContainer to solve it. Instead came up with calling the separate task/thread with the UI scheduler:
Task.Factory.StartNew(
() => { result = CustomMessageBox.Show(messageText); },
CancellationToken.None,
TaskCreationOptions.None,
_ui);
Where _ui is assigned in a method that is executed from UI context (e.g. Constructor of your Window/Control:
_ui = TaskScheduler.FromCurrentSynchronizationContext();
Hope this helps for solving the "replace System.Windows.MessageBox with Xceed.Wpf.Toolkit.MessageBox" part of your question.
If you want that the messagebox shows up on another Window you have to set the "Owner" property of the message box to the other window.
Best regards.
I am launching an MVVM application with code in the App.xaml.cs like so:
protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);
//Set data directory
string baseDir = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + #"\BlowTrial";
if (!Directory.Exists(baseDir))
{
Directory.CreateDirectory(baseDir);
}
AppDomain.CurrentDomain.SetData("DataDirectory", baseDir);
//Application initialisation
AutoMapperConfiguration.Configure();
//Security
CustomPrincipal customPrincipal = new CustomPrincipal();
AppDomain.CurrentDomain.SetThreadPrincipal(customPrincipal);
// Create the ViewModel to which
// the main window binds.
var mainWindowVm = new MainWindowViewModel();
MainWindow window = new MainWindow(mainWindowVm);
// When the ViewModel asks to be closed,
// close the window.
EventHandler handler = null;
handler = delegate
{
window.Close();
if (!window.IsLoaded) //in case user cancelled close event
{
mainWindowVm.RequestClose -= handler;
}
};
mainWindowVm.RequestClose += handler;
window.Show();
}
I would like to test for the existence of entities containing important data for running the application, and if these do not exist, run a wizard (as a dialog) which obtains these settings:
if (BlowTrialDataService.GetBackupDetails().BackupData == null
|| !_repository.LocalStudyCentres.Any())
{
DisplayAppSettingsWizard();
}
static void DisplayAppSettingsWizard()
{
//testfor and display starup wizard
var wizard = new GetAppSettingsWizard();
GetAppSettingsViewModel appSettings = new GetAppSettingsViewModel();
wizard.DataContext = appSettings;
EventHandler wizardHandler = null;
wizardHandler = delegate
{
wizard.Close();
wizard = null;
appSettings.RequestClose -= wizardHandler;
};
appSettings.RequestClose += wizardHandler;
wizard.ShowDialog();
}
When I place this code in the MainWindow.xaml.cs, the application runs correctly. When it is placed in either the App.xaml.cs (before the code to instantiate the instance of MainWindow), or in the constructor for MainWindowViewModel, the wizard displays correctly, but the application ends without displaying the MainWindow on completion of the wizard. If there is no cause to display the wizard, MainWindow displays correctly in all cases.
Examining the debug output, there are no errors of note (a few first chance exceptions related to sql commands).
Is there a reason for this - having the code in the code behind MainWindow.xaml does not seem the most logical place (which to my mind would be the app.xaml.cs).
Thank you for your expertise.
The default value of ShutdownMode is System.Windows.ShutdownMode.OnLastWindowClose which means if the last window was closed App will shutdown.
You didn't put all in code in here, I suppose that setting wizard window didn't show before main window closed, this lead app exit.
I suggest you set shutdownmode to OnExplicitShutdown which you can decide when to close your app by your own.
New to WPF/XAML and looking to build a Command library for my application. Current version of my application is "flat" meaning all the code behind resides in my MainWindow.cs file. I've decided to separate things out into User Controls and all the UI part so far works great but....
I'm having trouble binding my commands to things now that I've done this. To make it simple I created a new WPF project, added my Menu control (Controls\Menu.xaml) and referenced this in my MainWindow.xaml. Now, I've gone ahead and added a CommandLibrary class and can't seem to get anything working. Here is my File -> New command code:
public static class MyAppCommands
{
private static RoutedUICommand _NewItem;
static MyAppCommands()
{
_NewItem = new RoutedUICommand("Create a new project", "NewItem", typeof(MyAppCommands));
}
public static RoutedUICommand NewItem
{
get { return _NewItem; }
}
private string filePath = null;
private bool dataChanged = false;
public static void NewItem_Executed(object sender, ExecutedRoutedEventArgs e)
{
if (dataChanged)
{
string sf = SaveFirst();
if (sf != "Cancel")
{
ClearState();
}
}
else
{
ClearState();
}
}
public static void NewItem_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
e.CanExecute = true;
}
public static void BindCommandsToWindow(Window window)
{
window.CommandBindings.Add(new CommandBinding(NewItem, NewItem_Executed, NewItem_CanExecute));
}
Where do I put the below in my class as a lot of my command will be using them...?
private string filePath = null;
private bool dataChanged = false;
Many Thanks!
I think you could benefit from setting up some design patterns like MVC or MVVM.
Check out these frameworks:
Caliburn (my favorite)
Prism
You can also follow MVC or MVVM just using a couple small helper classes, check out ariticles around the web, like this one MVVM.
Check this if you want a light-weight framework: MVVM Foundation
My application is only for me and co-workers, so I don't care if it's Click-Once or copy-the-exe. I want to be able to click a file with given extension in windows explorer and have my program launch and open that file. I can't get it to capture the file name.
Ostensible solution:
Link
The code I'm trying is below and at this point all I'm trying to do is put the name of the clicked file in a text box. I suspect my relevant ignorance is about how to reference the click-once application from windows explorer. When I build I end up with a file called setup.exe, a file called Wis.application, and when I click on "setup" to install it, I end up with a shortcut of type "Click-once application reference" in "C:\Users\ptom\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Wis". I've tried associating files with that shortcut created by install, and associating files with setup.exe. When I click on the file, the application launches but indicates that
AppDomain.CurrentDomain.SetupInformation.ActivationArguments is null. (By "indicates" I mean the text box gets filled in with the text from where I test to see if it's null). If I run the app from debug, or just by running it from the start menu, it does what I'd expect, following the code path that indicates that ActivationArguments is not null, but that its ActivationData (string[]) is of length 0.
Here is the code from app.xaml.cs
using System;
using System.Collections.Generic;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Windows;
namespace Wis
{
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
protected override void OnStartup(StartupEventArgs e)
{
// Check if this was launched by double-clicking a doc. If so, use that as the
// startup file name.
if (AppDomain.CurrentDomain.SetupInformation.ActivationArguments == null)
{
this.Properties["DoubleClickedFileToLoad"] = "There were no activation arguments AGAIN";
}
else
{
if (AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData != null
&& AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData.Length > 0)
{
this.Properties["DoubleClickedFileToLoad"] =
AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData[0];
}
else
{
this.Properties["DoubleClickedFileToLoad"] = "Type in a file name";
}
}
}
}
}
Thanks
First of all you should add file assoc for ClickOnce-publish (Select Project->Properties->Publish-Options->File Associations)
Then add Reference to "System.Deployment"
Then you could extract path in App.cs in such a manner, depending on type of startup (ClickOnce or Local)
protected override void OnStartup(System.Windows.StartupEventArgs e)
{
var path = GetPath (e);
}
private static string GetPath(StartupEventArgs e)
{
if (!ApplicationDeployment.IsNetworkDeployed)
return e.Args.Length != 0 ? e.Args[0] : null;
if (AppDomain.CurrentDomain.SetupInformation.ActivationArguments == null)
return null;
var args = AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData;
return args == null || args.Length == 0 ? null : new Uri(args[0]).LocalPath;
}
Have you checked Environment.GetCommandLineArgs()?
That shows the arguments with which your application was started.
If your application is associated with a file, it should contain the filename as one of the arguments.