|
Yeah, I was trying to encapsulate "everything", but I guess there is no way around having a static Main() in the exe itself.
|
|
|
|
|
Heh, well encapsulating Main() might be a little overboard... I mean, you can always have your ApplicationEx do its initialization in the constructor, or even do a factory-style constructor instead to preserve command-line args (If you need them)...
Application app = ApplicationEx.Create(string[] args);
|
|
|
|
|
Yeah, I ended up having an ApplicationEx.StartupEx method (lol, you can totally tell I come from the MFC / Win32 world with all the "Ex" names) that takes the type for the user application class along with the args and then it creates the application and/or manages the single instance stuff. It does require the user to stub out a Main() and forward the call to my DLL though. I was trying to avoid that. Oh well.
Now I'm just having a bit of trouble figuring out a common place to process the command line for the first and subsequent instances since some of the WPF start up code is syncronous (Application.Run()). I've got it working for the second instance though. It does forward the args to the first instance.
I'm using the WindowsFormsApplicationBase technique to do the singleton app stuff. It does have the different entry points for the first / subsequent start ups (OnStartup / OnStartupNextInstance).
2nd+ instance is going through OnStartupNextInstance and calling a virtual method in ApplicationEx, but 1st instance is a bit trickier since I haven't quite convinced myself if that case should be passed in before the main window is created, but I'm thinking it probably should.
Its weird though... popping up a message box before the main window is created somehow creates the main window...
|
|
|
|
|
Heh, you're losing me here... Not sure exactly what you're trying to do, and I'd never even heard of WindowsFormsApplicationBase until now... Are you starting up multiple GUI threads? Usually don't want to do that in a WPF app, unless you have a really good reason for it.
But anyway...
Yeah, Application.Run() is synchronous. I generally handle command line apps by making a "Globals" static class to hold that and a few other properties... The kind of things that get set once on startup and then never ever ever ever EVER modified... Stuff like command line arguments, modes to turn off non-developer features or prevent external writes during testing... Just don't use something like that for read/write storage, or you'll just create all sorts of design issues.
|
|
|
|
|
I'm making an "ApplicationEx" class that encapsulates single application instance functionality and the WindowsFormsApplicationBase technique is one of the more popular ways to do that. No multi-threaded GUI threads  . WindowsFormsApplicationBase is just MSFT's wrapper for that stuff and they do all the inter-process communication like forwarding the new cmd line args to the previous instance.
Think about IE... if you type "start http://www.microsoft.com" at the cmd prompt, it starts up IE and goes to www.microsoft.com. Now if you type "start http://www.cnn.com", it keeps the same one instance of IE, but opens up a 2nd tab to www.cnn.com. Obviously a 2nd instance of IE ran and exited and somehow forwarded the args to the first process.
WindowsFormsApplicationBase provides a pretty clean mechanism to get the SECOND instance cmd line args to the singleton instance, but it doesn't provide a very clean way to get the original instance cmd line args out of the static classes.
I think I'm kind of going to do what you suggested and add a "LastCmdLineArgs" property to ApplicationEx. Kind of weird that Application doesn't have that already.
|
|
|
|
|
Ah, gotcha... I do that with a lightweight launcher EXE that sends args over a named pipe.
|
|
|
|
|
Why not just create this functionality as an extension method and use that?
|
|
|
|
|
Can't do that since ApplicationEx has some added virtual methods (i.e. ProcessCommandLine(...), etc.). You are right though, it would have been cleaner if I was just forwarding a single call. I could have had the user pass in a callback function instead of using virtual methods, but at that point, having an extension method vs. the ApplicationEx class... seems like the virtual method way is a bit cleaner.
|
|
|
|
|
Could you send me what you're trying to do and I'll see if I can get it to work? I've had some experience hacking around in the App class.
|
|
|
|
|
Hey All,
I'm just looking a spot of MVVM and I've written a little demo app with this interface in:
public interface IView<T> where T : ViewModelBase
{
T Model { set; }
}
So in my windows I can do this:
public partial class MainWindow : IView<MainWindowViewModel>
{
public MainWindow()
{
InitializeComponent();
}
public MainWindowViewModel Model
{
set
{
DataContext = value;
}
}
}
And it will automatically type my Model property for me ... amazingly lazy but I kinda like it. I'm just not sure how 'MVVM' it is ...
What are your objections? This isn't an interface for every ViewModel type but works well for Window / Region / Views (proper) type view models ...
Cheers,
|
|
|
|
|
It's probably not that useful: it's rare that you want to manipulate a view's view model – what a mouthful that is – in a generic way, through ViewModelBase. But I think it's quite elegant, and it clearly shows (and enforces!) the M-VM relationship.
|
|
|
|
|
Yeah, it really is a 'swings and roundabouts' kinda issue isn't it ...
Strictly speaking the view still doesn't now anything about the model. The only thing it does know in this scenario is the type it will accept as the view model.
99% of the time your unlikely to want to be switching the type of view model you inject into the view data context.
The only thing I don't like is you now only deal with concrete types for view models rather than an interface.
|
|
|
|
|
To be honest mate, if I were you I would use MefedMVVM instead. It gives you the type to interface, and takes care of hooking up the concrete implementation for you.
|
|
|
|
|
Hey Pete,
Will look into this. Looks good!
Cheers,
|
|
|
|
|
It is - I did a minor part of the development for Marlon. It's top notch stuff.
|
|
|
|
|
Nice! 
|
|
|
|
|
<slaps forehead=""> ...
I'm still on .NET 3.5 SP1 at work ... 
|
|
|
|
|
Personally, I'm more a fan of including a controller in there. I kind of mix MVVM and MVC together.
My class defenitions then look like this:
public class SomeController : Controller<ISomeView, SomeModel>
public class SomeModel : Model
public class SomeView : View<SomeController>, ISomeView
In the constructor of the view, I'll create the controller, which exposes a model property.
That model will then be set on the datacontext. When creating the controller, I'll pass the view to the constructor so that the controller has a reference to the view as well (under the form of an interface).
This way, you can unit test the controller and assert your model states while mocking the view... and, you won't have any ugly code-behind in your *.xaml.cs file, aside from some eventhandler methods like a button_Click. And in those methods, you'll only have 1 line anyway, which will be a controller call like Controller.XButtonClicked() or whatever.
For LOB applications, this works great.
This also opens up a lot of possibilities for standard control behaviour you may wish to have like automatic busy indicators etc.
modified on Thursday, April 28, 2011 8:10 AM
|
|
|
|
|
Hi,
I have a listbox.item template control like this in my application..
<ListBox Grid.Row="1" Grid.Column="2" x:Name="lbDirectiveList" MaxHeight="200" SelectionChanged="lbDirectiveList_SelectionChanged" SelectionMode="Single" ScrollViewer.VerticalScrollBarVisibility="Auto">
<ListBox.ItemTemplate>
<DataTemplate>
<Grid Margin="4">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="25" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<TextBlock Text="{Binding Path=DirectiveName}" Grid.Column="0" FontWeight="Bold" MinWidth="200"/>
<TextBlock Text=" - " Grid.Column="1"/>
<TextBlock Grid.Column="2" Text="{Binding Path=DirectiveDescription }" />
</Grid>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
I have to read the data from this listbox and display it in textboxes when user click on the list box, i have used a code like this, it is displaying the data in UI control, but when am clicked on delete by selecting the row from listbox, it is giving exception, so could u tell me the right way of doing it, it is needed for many validation in my application, i tried for some ex, but dint get a clear idea of how to do it, so any help on this...
private void lbDirectiveList_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
gDirectiveDetails.IsEnabled = true;
int i = lbDirectiveList.SelectedIndex;
if (i < listdata.Count && i >= 0)
btnDeleteDirective.IsEnabled = true;
Directive lstdata = (Directive)lbDirectiveList.SelectedItem;
txtDirectiveName.Text = lstdata.DirectiveName.ToString();
txtDirectiveDescription.Text = lstdata.DirectiveDescription.ToString();
}
private void BtnDeleteDirectiveClicked(object sender, RoutedEventArgs e)
{
int i = lbDirectiveList.SelectedIndex;
if (i < listdata.Count && i >= 0)
{
listdata.RemoveAt(i);
}
btnDeleteDirective.IsEnabled = false;
}
|
|
|
|
|
Can you tell what is the exception?
Anyway try this :
listdata.Remove((Directive)lbDirectiveList.SelectedItem);
I would like to suggest you to make few more changes.
You can remove the SelectionChanged event if you want to display the textboxes on selection. You should use the Binding concept of WPF. So you can use IsSynchronizedWithCurrentItem property of the ListBox. I will explain later its use.
This is how you can use it :
1) Set the DataContext of the panel(in your case its grid) to listdata, and remove the ItemsSource property that you have set earlier. So replace it with this :
myGrid.DataContext = listdata;
2) In the XAML of the ListBox, add this :
<ListBox Grid.Row="1" ItemSource = "{Binding}" IsSynchronizedWithCurrentItem = "True" Grid.Column="2" ..../>
3) In the textboxes of your XAML, add this :
<TextBox Name = "txtDirectiveDescription" Text = "{Binding Path = DirectiveDescription}"/>
<TextBox Name = "txtDirectiveName" Text = "{Binding Path = DirectiveName}"/>
4) Remove the SelectionChanged event, you won't be needing it!
With IsSynchronizedWithCurrentItem property, the current item of the DataContext selected on the ListBox will be set to the children of the Panel with which it has Binding. You will better understand by if you set this property to false.
Good luck!
People with high attitude deserve the standing ovation of our highest finger!
My Blog![ ^]
|
|
|
|
|
it is giving problem only when i used to display the data in a textboxes which is selected from listbox,
it will display data in the particular UI COntrol, but if i clicked on delete here by selecting a listbox data, it is giving exception,
Exception is Null Reference is Unhandled(Object reference not set to an instance of an object).
i dont know why it is giving exception like null refence when clicked on delete...
So any help in fixing this...
when it come back to btndeletedirective, it is taking the value of i as -1(i=-1) and its reading the i value as 0 in textchanged event if i select the data which is in 3rd row in a listbox..
private void txtDirectiveName_TextChanged(object sender, TextChangedEventArgs e)
{
string strDirective = txtDirectiveName.Text.Trim();
string strDescription = txtDirectiveDescription.Text.Trim();
int i = lbDirectiveList.SelectedIndex;
if (!string.IsNullOrEmpty(strDirective))
{
listdata.Insert(i, new Directive { DirectiveName = strDirective, DirectiveDescription = strDescription });
lbDirectiveList.SelectedIndex = i;
listdata.RemoveAt(i + 1);
}
}
private void txtDirectiveDescription_TextChanged(object sender, TextChangedEventArgs e)
{
string strDirective = txtDirectiveName.Text.Trim();
string strDescription = txtDirectiveDescription.Text.Trim();
int i = lbDirectiveList.SelectedIndex;
if (!string.IsNullOrEmpty(strDescription))
{
listdata.Insert(i, new Directive { DirectiveName = strDirective, DirectiveDescription = strDescription });
lbDirectiveList.SelectedIndex = i;
listdata.RemoveAt(i + 1);
}
}
private void lbDirectiveList_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
gDirectiveDetails.IsEnabled = true;
int i = lbDirectiveList.SelectedIndex;
if (i < listdata.Count && i >= 0)
btnDeleteDirective.IsEnabled = true;
Directive lstdata = (Directive)lbDirectiveList.SelectedItem;
txtDirectiveName.Text = lstdata.DirectiveName.ToString();
txtDirectiveDescription.Text = lstdata.DirectiveDescription.ToString();
}
private void BtnDeleteDirectiveClicked(object sender, RoutedEventArgs e)
{
int i = lbDirectiveList.SelectedIndex;
if (i < listdata.Count && i >= 0)
{
listdata.Remove((Directive)lbDirectiveList.SelectedItem);
}
btnDeleteDirective.IsEnabled = false;
ResetControls();
}
modified on Wednesday, April 20, 2011 9:43 AM
|
|
|
|
|
I am not able to understand why are you using the TextChanged events, and why are you inserting and removing items there. You seriously need to make changes in your code. That's really bad way of programming.
I think you don't want to use any button to add items, fine, you can use the LostFocus event of the TextBox so that after writing in the TextBox, when the focus on the TextBox is lost, you can then add items. TextChanged event is not the right way.
This maybe the reason for that exception.
People with high attitude deserve the standing ovation of our highest finger!
My Blog![ ^]
|
|
|
|
|
As Tarun tried to explain, this is really the wrong way to tackle this problem. You're trying to write a WPF application like a WinForms one, and that defeats the purpose entirely.
The key to WPF is Data Binding... The entire interface revolves around it, and if you switch your mind to the right track, it'll make your life much easier. All of that "glue" to connect controls, keep things synchronized, turn things on and off... All of that can be pretty much automatic.
First of all, you should try to AVOID giving names to your controls. If you have to refer to a control from the code-behind, you're either doing something really weird/original, or you're just doing it wrong.
1) Create a data model class... Just a simple class that contains a few properties to store the state of your GUI. In your situation, I think you'll need properties for:
a) A list representing the Directives. I'd type this as an ObservableCollection<Directive> to make sure updates are processed correctly.
b) A Directive representing the selected item ("SelectedDirective" maybe).
2) Set the DataContext of the window (Or anything that contains all of the related controls) to this model class, so the bindings will reference it
3) Bind the controls:
a) The ItemsSource of the listbox should bind to your list property
b) The SelectedItem of the listbox should bind to your SelectedDirective property, with Mode=TwoWay
c) The textboxes (txtDirectiveName, txtDirectiveDescription - Though you should un-name them after you do this) should bind to "SelectedDirective.DirectiveName" and "SelectedDirective.DirectiveDescription"
d) The delete button's "IsEnabled" property should bind to SelectedItem. For this, you need a converter that will take an object and return true if it's non-null.
e) The delete button's event handler can be as simple as Directives.Remove(SelectedDirective).
See how this works? The code-behind never refers directly to GUI controls, except to set the DataContext. The GUI does its own thing, and just reads and writes data to/from the underlying model.
|
|
|
|
|
That's a good answer. Rocky should use the powerful WPF features here. See his reply to my answer and the way he inserts the item.
People with high attitude deserve the standing ovation of our highest finger!
My Blog![ ^]
|
|
|
|
|
Yeah, I noticed... Definitely WinForms-style.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
