|
I am planning to create a Licensing Module which can be commonly used for all Desktop Applications. So i thought of making it so simple without any or less coding in the existing applications which are going to be activated by this Licensing Module.
So is there any way where if the user passes the exe location, the system should capture the exe available in the particular location, and the system should get all the windows forms available inside that exe?
Am not sure whether it is possible or not but i need to know whether there is any way to do it. It would be helpful for me to develop this with less complications.
|
|
|
|
|
Yes, that can be easily done.
First, load the assembly with Assembly.Load
Then, call GetTypes on the assembly that you just loaded,
Then, for each type in the Type array, check if it "is" a "Form" like so:
foreach ( Type T in typeArray)
if (T is Form)
Do stuff....
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Assuming the exe is a dotnet assembly, that is not implied by the question!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Boy, you're all over me today. In the lounge and here.
The fact that it's a dot net assembly is implied by two very strong factors:
1. The fact that this is the C# forum
2. The fact that he referred to the type "Form" which is a dot net type.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: you're all over me today
Ah I missed the assembly point, being in the c# forum I don't feel would have been conclusive!
Its not personal, I grump at everyone.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Its not personal, I grump at everyone.
No worries!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
thanks a lot buddy....it worked perfectly...i created the following method according to your idea...
Assembly SampleAssembly = Assembly.LoadFrom("Assembly Path Here");
// Display all the types contained in the specified assembly.
foreach (Type oType in SampleAssembly.GetTypes())
{
Console.WriteLine(oType.Name);
}
you saved ma day....thanks again buddy...
|
|
|
|
|
I'm inexperienced when it comes to creating my own interfaces in C#.
Why would one choose to A) implement or B) explicitly implement an interface?
I have read that an explicit implementation can only be called through an instance of the interface.
Why would this be desirable or not desirable?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Conflicting interfaces!
Suppose you have
public interface ISimpleCalculator
{
int Calculate(int num1, int num2);
}
public interface IFancyCalculator
{
CalculationResult Calculate(int num1, int num2);
}
Now, suppose I want to implement both these interfaces in a VersatileCalculator class. I can't implement both Calculate methods, though, because methods can't be overloaded on different return types alone - their names and parameter lists are identical!
So the way I'd handle this is to explicitly implement the interfaces, and then have a regular Calculate method which just calls one of the implementations or has an extra parameter to choose an implementation or something.
|
|
|
|
|
Oh, I see. So it makes sense to default to explicit implementation then, right?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I usually default to implicit and only use explicit when I have to; the syntax is a bit weird, and since explicit implementation requires casting to the interface type to call the method, it could be confusing to a consumer of your code.
|
|
|
|
|
One case would be if you have implemented multiple interfaces that have methods with same signature. The only way to differentiate to explicitly implement the method
No comment
|
|
|
|
|
So would you say that explicit implementation is something you do only when needed, or is it the usual?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Explicit implementation should be used when necessary
No comment
|
|
|
|
|
OK thanks!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The main reason why you would explicitly implement a method of an interface is when you already have a method with the same signature, or you need to implement another interface with a method that has the same signature. So, say you have a method in your class Foo(string bar) and the interface requires a method with the same name and signature, you would have to explicitly implement the interface member IFoo.Foo(string bar) . Another difference is in an implicit implementation, the method has to be declared as public, whereas in an explicit implementation, the method must be declared as private, meaning that the method can only be accessed by an instance of the Interface. Here is a quick demo:-
Say we have 2 interfaces IFoo and IFoo2:
interface IFoo
{
void Foo(string bar);
}
interface IFoo2
{
void Foo(string bar);
}
Then if we had a class that needed to implement both, one would have to be explicitly implemented:
class Foobar:IFoo , IFoo2
{
void IFoo.Foo(string bar)
{
MessageBox.Show("IFoo");
}
public void Foo(string bar)
{
MessageBox.Show("IFoo2");
}
}
Now when we create an instance of class Foobar and need to call these methods we have to do so like this:
Foobar f = new Foobar();
f.Foo("x");
IFoo y = (IFoo)f;
y.Foo("y");
Hoep this helps
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
Wayne Gaylard wrote: whereas in an explicit implementation, the method must be declared as private, meaning that the method can only be accessed by an instance of the Interface.
A ha! I wondered why the IDE didn't put "public" in front of my methods when I chose to explicitly implement from the shortcut menu.
Thanks for the terrific post.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
No worries - glad I could help.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
These MSDN sources have been helpful to me in my research on interfaces:
HopCroft's overview:[^]
Brad Abrams ideas about when to use explicit vs. implicit interfaces I find very helpful:[^]
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." Bjarne Stroustrop circa 1990
|
|
|
|
|
In general I'd only ever do this if there is a name clash with a method from another interface or which already exists in the class hierarchy. The commonest case is implementing IEnumerable<T>, when you need to provide two GetEnumerator methods.
However, the linked article from the answer above mine raises an interesting point: if the interface is only implemented for infrastructure reasons and you never expect an 'end user' developer to actually call the methods on your class manually, it might make sense to explicitly implement them. So one might argue that both GetEnumerators should be explicitly implemented, as they're there for infrastructure reasons (being able to enumerate over the class) and not to be called directly.
For a custom interface that would be true if it is something which has special meaning for a framework you have created, so all a class needs to do from an external point of view is implement it and some clever stuff happens. For example let's imagine a slightly cleverer version of my socket library which specified an interface thus:
public interface ITransferrable {
byte[] GetBytes();
void Restore(byte[] bytes);
}
... and some magic which I won't go into (restoring would be slightly non-trivial and writing that out wouldn't help the point) which allowed you to send and retrieve ITransferrables through the normal send/receive mechanism.
Apart from code inside Sockets.cs, no-one would ever explicitly call those two methods. So, even without a name clash, it might well make sense to explicitly implement that interface, because you don't need to see them when you are inspecting the implementing class in a domain context.
|
|
|
|
|
How do you handle this?
Girl girl = new Girl(Type.LovelyOne|Type.KindOne|PrettyOne);
Boy you = new Boy(Type.KindOne|Type.Married);
girl.Love(you);
girl.MakeLove(you);
you.IsInLove = true;
girl.ReturnedToHerBoyfriend = true;
girl.Leave();
you.Dispose();
Fatal Error!
Sojaner!
|
|
|
|
|
Does anyone know the incantation to save an excel workbook without having the "Do you want to save" popup appearing? I cannot have the confirmation appear because the alterations I am making to the file need to be seamless.
Application excel = new Application();
Workbook workbook = excel.Workbooks.Open(Filename);
var sheet = workbook.ActiveSheet;
Range column = sheet.Range["B1"].EntireColumn;
column.Insert(XlInsertShiftDirection.xlShiftToRight);
workbook.Save();
workbook.Close();
Marshal.ReleaseComObject(workbook);
Marshal.ReleaseComObject(excel);
This will save the file, but the popup is not suppressed.
"I need build Skynet. Plz send code"
|
|
|
|
|
|
Thanks, Mark.
"I need build Skynet. Plz send code"
|
|
|
|
|
Hurray! I get to answer my own question lol
excel.DisplayAlerts = false;
fixed.
"I need build Skynet. Plz send code"
|
|
|
|