|
PIEBALDconsult wrote: But as you may have read in one of my articles (you've them all by now, right?)
Mercy, please: give me half-a-day to study them, here at UTC + 7, where my computer "day" begins at 5am (six hours ago), and is interrupted, about now, with business errands followed by, at high-temperature time in the afternoon, a shower and long siesta ...
Of course, "studying your articles," does not imply I will understand them !
But, learn from them: that I guarantee 
best, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
|
|
|
|
|
PBC, I read the "EnumTree" and "TypeTransMogrifier" articles: neither mentioned the use of a Hashset, although perhaps you use one somewhere in the code I didn't bother examining.
I do plan to study the "Enum Utilities" article, which was quite popularly rated compared to the first two articles.
Both articles I read seemed to me be over-engineered to the point of being "esoteric," and I could not imagine one real-world use-case where such techniques as you demonstrate are really required.
That analysis may simply be saying something about me, and my level of coding knowledge, and problems I deal with, rather than saying anything about you. For all I know, such complex solutions as you present in those two articles: are ideal in certain real-world situations.
Of course, I respect your achievements, five out of seven "platinums," on Code Project is very impressive !
best, Bill
p.s. the "using directives:"
using System;
using System.Windows.Forms;
using System.Collections.Generic;
are absolutely required, or the code I showed you will not build. Remember this is a stand-alone static-class, not a "partial Form."
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
|
|
|
|
|
Thanks.
BillWoodruff wrote: neither mentioned the use of a Hashset
Perhaps not, but if all you want to do is check for the existence of an item in a set, HashSet is "better" and a List.
BillWoodruff wrote: over-engineered
BillWoodruff wrote: problems I deal with
Most likely. In many cases they're not worth the overhead. Basically it depends on the duration of the application and the number of times the structure is accessed. Many apps (Web apps?) run for only a very short period and access such a structure once then stop. But I work on a lot of Windows Services that run 24/7 for months or years and can access the structure a great many times in rapid succession, so I feel it's worthwhile.
BillWoodruff wrote: the code I showed you will not build as written
FTFY. Everything can be fully-specified -- using directives are a matter of convenience.
BillWoodruff wrote: five out of seven "platinums,"
Hey, don't forget the MVP award!  I suspect I'm why they changed over to the new reputation system. 
|
|
|
|
|
This code is fine. You are overthinking it. If the 5 controls were somehow related, then I might give a different answer, but seeing as they are completely unrelated, this solution is perfectly fine.
|
|
|
|
|
BillWoodruff wrote: they are, indeed, "required."
You may find them convenient, but they are not required... unless some coding standard forced upon you says so.
|
|
|
|
|
Response to edit:
I think what he meant is the using directives are not required as everything can be written in full i.e.
private static System.Collections.Generic.List<System.Type> OkToModify =
new System.Collections.Generic.List<System.Type>
{
typeof(System.Windows.Forms.CheckBox),
typeof(System.Windows.Forms.TextBox),
typeof(System.Windows.Forms.Button),
typeof(System.Windows.Forms.Panel),
typeof(System.Windows.Forms.Label)
};
Personally, I think this is horrible and I always use usings wherever possible, but some will disagree...
|
|
|
|
|
Bill, the code you have there looks to be about as optimised as you are going to get. The only thing I would wonder about, though, is the extensibility of your model here. Basically, what you have here could end up violating the Open-Closed principal which states that a class should be open to extension but closed to modification.
So, what does that fancy term mean? Well, it simply means that if you decide to add another type in future, you have to crack open your code and modify it. It's up to you to decide whether or not this is acceptable to you. There are various ways to solve this problem, but one way could simply be to store the types in your configuration (comma delimited would do), and then parse them on the way in. So, suppose you store them in a key in app.config (for example), what would the code look like? Well, this should help:
private void PopulateOkToModifyCollection()
{
string types = ConfigurationManager.AppSettings["ModifiableTypes"];
if (string.IsNullOrWhitespace(types))
return;
string[] allowedTypes = types.Split(',');
foreach (string allowed in allowedTypes)
{
Type type = Type.GetType(allowed);
if (type == null)
{
throw new ArgumentException(string.Format("The type {0} is not a valid type", allowed));
}
OkToModify.Add(type);
}
}Note that when you add the type to your comma separated list in the AppSettings key, it should be the fully qualified type.
|
|
|
|
|
I am trying to use a GoTo type command in my WPF application. Right now it looks like this:
private void GoTo(string viewModel, int claimId)
{
switch (viewModel)
{
case "ECRsViewModel":
{
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is ECRsViewModel)
as ECRsViewModel;
if (workspace == null)
{
workspace = new ECRsViewModel(claimId);
_mainWindow.Workspaces.Add(workspace);
}
_mainWindow.SetActiveWorkspace(workspace);
}
break;
case "ManagePropertiesViewModel":
{
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is ManagePropertiesViewModel)
as ManagePropertiesViewModel;
if (workspace == null)
{
workspace = new ManagePropertiesViewModel(claimId);
_mainWindow.Workspaces.Add(workspace);
}
_mainWindow.SetActiveWorkspace(workspace);
}
break;
case "ClaimReportsViewModel":
{
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is ClaimReportsViewModel)
as ClaimReportsViewModel;
if (workspace == null)
{
workspace = new ClaimReportsViewModel(claimId);
_mainWindow.Workspaces.Add(workspace);
}
_mainWindow.SetActiveWorkspace(workspace);
}
break;
}
}
Obviously, this is a terrible solution. I wanted something where I could find the type of the viewModel string, how do I do this?
I want something like this:
{
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is typeof(viewModel)
as typeof(viewModel);
if (workspace == null)
{
workspace = new typeof(viewModel)(claimId);
_mainWindow.Workspaces.Add(workspace);
}
_mainWindow.SetActiveWorkspace(workspace);
}
Something nice and concise like that. Thoughts?
|
|
|
|
|
I recommend an enumeration:
private enum MyViews { ECRsViewModel , ManagePropertiesViewModel , ClaimReportsViewModel }
MyViews v = (MyViews) System.Enum.Parse ( typeof(MyViews) , viewModel ) ;
switch (v)
{
case MyViews.ECRsViewModel:
You can get fancy with it, but that's the basics.
I use enumerations extensively and have written a few articles about how I use them, here's one: Enum Utilities[^]
Another way would be to use something like my TypeTransmogrifier[^], but I don't know whether or not you'd get much benefit from it.
|
|
|
|
|
+5 Fascinating way to use Enums, got to go and study your articles !
thanks, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
|
|
|
|
|
PIEBALDconsult wrote: I recommend an enumeration:
I wouldn't. You are re-inventing the wheel by re-inventing something that already exists in .Net. .Net has full support for creating instances from types and/or type strings. I provided sample code in my other response. No need to "fake it" with enums.
|
|
|
|
|
You can re-write all of that code in one or two lines. You didn't mention who is calling the Goto function, but you can convert a string into a Type like this:
Type type = Type.GetType(viewModel);
Then you'd get the workspace:
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is type);
Then you'd create the VM from the type like this:
Activator.CreateInstance(type, new object[] { claimId });
|
|
|
|
|
So how do you restrict the allowable types?
|
|
|
|
|
Store the list of allowable types in a string array and check the array before the call to GetType, perhaps?
|
|
|
|
|
Check if the type is derived from the ViewModelBase or implements an interface, but that wasn't a requirement  .
|
|
|
|
|
This is what I was looking for. I had stumbled across the Activator but was not sure how to use it in this example. I have no need to restrict the allowable types in this instance, so this is perfect.
Cheers, --EA
|
|
|
|
|
Solution did not work exactly as I thought it might. This is where I am at right now:
GoTo call:
public ICommand GoToECRsCommand { get { return new RelayCommand(() => GoTo<ECRsViewModel>("ECRsViewModel", _claimId)); } }
Eventually it will be either the <t> or the viewModel argument, not both. Here is the function right now:
private void GoTo<T>(int claimId) where T : new()
{
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is T)
as T;
if (workspace == null)
{
workspace = new T(claimId);
_mainWindow.Workspaces.Add(workspace);
}
_mainWindow.SetActiveWorkspace(workspace);
}
Obviously the issue stems from my lack of understanding of generic types (Amongst other things). I can see the problem, I just don't know how to correct it.
Cheers, --EA
|
|
|
|
|
What is the real error that the debugger is putting out?
"var workspace" should be "T workspace" if you are going that route and you might be able to drop the "as T" part.
When you new up the workspace like that, is it actually returning the correct type and calling the proper constructor? I'm surprised that the compiler didn't error out on that line because it doesn't know that some random T has a constructor(int), although it may do that at compile time...
|
|
|
|
|
Having gutted out much of what was there, here is where I am:
private void GoTo(string viewModel, int claimId)
{
Type type = Type.GetType(viewModel);
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is type);
if (workspace == null)
{
Activator.CreateInstance(type, new object[] { claimId });
_mainWindow.Workspaces.Add(workspace);
}
_mainWindow.SetActiveWorkspace(workspace);
}
Error is "The type or namespace 'type' could not be found."
|
|
|
|
|
Change that line to:
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm.GetType().Equals(type));
|
|
|
|
|
Oh... DUH... you can't do the "is type" part because is expects an actual type, not a Type. How's that for confusing . I.e. you do blah is Window, not blah is window.GetType().
So you can either change it to:
vm.GetType() == type
Or go back to your generic method you had before and do:
vm is T
but with the above code, you need to do the vm.GetType() == type.
|
|
|
|
|
btw, you are missing a:
workspace = Activator.CreateInstance(type, new object[] { claimId });
|
|
|
|
|
Unfortunately making that changes causes an error.
An instance of type 'object' can not be assigned to a variable of type WorkspaeViewModel.
|
|
|
|
|
Ok, so you need the T casts
workspace = (T)Activator.CreateInstance(type, new object[] { claimId });
|
|
|
|
|
I needed that and also:
private void GoTo<T>(string viewModel, int claimId) where T: WorkspaceViewModel
However, this line:
Type type = Type.GetType(viewModel);
That returns null so everything else falls apart. How does it get a type from a string name? And can I pull out the string? It seems redundant since I am already giving it the type.
I can use T here:
var workspace = _mainWindow.Workspaces.FirstOrDefault(vm => vm is T);
and that gets rid of the need for type up until here:
workspace = (T)Activator.CreateInstance(type, new object[] { claimId });
Ayudame.
Cheers, --EA
Incidentally, without the "where T: WorkspaceViewModel I get an error on the workspace = (T)Activator... line.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
