|
Have a look at this tip Find an open port on a machine using C#[^].
HTH.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
The problem with that approach is that it only works for the local machine. I believe the OP is looking to scan ports on remote machines.
|
|
|
|
|
Ahh! Reading the question right is generally a good start 
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
You asked this question already, less than a day ago.
|
|
|
|
|
Univote countered
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
What you are trying to achieve here is a port scanner. This[^] article should give you a decent head start - but there are a couple of things to be aware of.
1. If you are scanning all ports, you should consider running the checks via multiple threads. The reason for this is because checking a port is a time consuming process.
2. Just because the list identifies that a port is free, it doesn't mean that the port will be free when you come to request it. Another application could have taken that port before you get to it, so don't consider that the list is definitive.
|
|
|
|
|
If you are attempting to create a port scanner then I STRONGLY suggest that you consider the following....
Do not do this unless YOU own the network or you have PERMISSION from the owner of the network in WRITING to do this.
People have been expelled from school, lost their network connectivity, been fired from jobs, have had civil judgments rendered against them and even criminally prosecuted because they did this. Even when they thought they had a legitimate need for the functionality.
|
|
|
|
|
Current working code in a public static class: a List<Type> used internally:
using System;
using System.Windows.Forms;
using System.Collections.Generic;
private static List<Type> OkToModify = new List<Type>
{
typeof(CheckBox),
typeof(TextBox),
typeof(Button),
typeof(Panel),
typeof(Label)
};By "working:" I mean that I can use the List<Type> to test if a given Control passed into the public static class is okay for the uses I make of it. Through, simply:
if (OkToModify.Contains(cntrl.GetType())) { processControl(cntrl) };I keep thinking that somewhere in my reading (Skeet ? StackOverFlow ?), or here on CP, I have seen a "niftier" way to do this.
Appreciate any alternatives.
thanks, Bill
[1] edit: 'references changed to 'directives in response to feedback from PIEBALDconsult. However, they are, indeed, "required."
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
modified 7-Aug-12 23:56pm.
|
|
|
|
|
HashSet 
But as you may have read in one of my articles (you've them all by now, right?) that may not handle derived types and Interfaces as well as you might like.
BillWoodruff wrote:
They're neither required, nor references.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
