|
Thanks, but I'm not sure that is suitable for my design.
I'm coding video surveillance application, server runs video capture and sends captured frames to connected clients.
There can be any number of clients connected to a server and a client can be connected to any number of servers.
There are video capture service and video data transfer service (the server).
As the frame is captured video capture service invokes send method from the video data transfer service which sends the frame to all clients connected.
WCF as I understood provides service contract and public methods to call.
In that case I need to add WCF logic to video capture service and declare public method as e.g. GetRecentFrame(). And a client needs to call that method.
I do not want to combine video capture and video data transfer services.
As video capture service is running on despite the fact if someone is connected to transfer it a frame. And network connection may be slow, video capture service may get 10 frames in a time 1 frame is finished with the transfer to the client.
Чесноков
|
|
|
|
|
Ah. I now understand why you prefer to be lower in the network stack.
/ravi
|
|
|
|
|
Chesnokov Yuriy wrote: I've seen those samples with a server getting back data from a client, sending back response and closing it.
I'm intrested in a server handing many clients connected and client connected to many servers architecture.
There is no multiple/multiple architecture, it's always one server/many clients. The fact that your browser can open multiple pages is due to having multiple clients, that each request data from a different server.
Chesnokov Yuriy wrote: There should be some ready described solutions to avoid common mistakes.
The All-in-one samples refer to the same page[^].
Bastard Programmer from Hell
|
|
|
|
|
I don't know if it counts as a design pattern but my sockets library[^] may be of some use to you (either to use it or to look at the code to adapt for your own solution). I don't use asynchronous writing (writing is de facto asynchronous, as it writes to the local buffer immediately, so you only need to use the methods if you want feedback), but I do use asynchronous accept and read and handle the various ways in which it can go wrong unexpectedly.
|
|
|
|
|
Hi All,
I know it is late on a Friday, but I am going to self-destruct if I don't find out this problem.
(.net 4.0)
Does anybody know a diffrence between a console application and a winforms application that would cause a difference between a DLL working correctly on 64bit Windows machine.
on local 32bit machine - both console and winforms work fine
on server 64bit machine - console don't work (error below), winforms works fine
error:
“Unable to cast COM object of type 'XXX' to interface type 'XXX'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{DE4DA901-EEF8-11D0-9E5F-008048AADD4E}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).”
please somebody know the answer...
Thanks
I may or may not be responsible for my own actions
|
|
|
|
|
Build the project using X86 instead of target any and see if that helps
Project - Properties - Build - Platform Target
I have a few 32 bit only dll's that are a nightmare and that helps.
|
|
|
|
|
Thanks for the reply, I have tried that thou and it did help with an earlier issue. The DLL is 32bit only by the way.
It is also an ActiveX COM DLL if that makes any difference. Their support suggests I try a small console application with another ActiveX COM DLL, I don't suppose you know any I could use? I don't know much about this ActiveX stuff to be honest
I may or may not be responsible for my own actions
|
|
|
|
|
On x64 systems, you need to register 32-bit COM components with C:\WINDOWS\SysWow64\RegSvr32.exe (32-bit version). By default, your path will use the one in C:\WINDOWS\System32 (the 64-bit version). Registering a 32-bit COM component using the 64-bit regsvr32 has a bunch of side effects and doesn't fully work.
|
|
|
|
|
Thanks but I had tried this already. I have now solved the issue and will post separate message with solution
I may or may not be responsible for my own actions
|
|
|
|
|
So I Installed the application that this SDK was for and that fixed the issue. The SDK is meant to work without the original application but I guess they have some set up issue they need to work out.
I am not sure about any specific files that get added/registered during install, but the following programs do get installed with it. These could provide the files that I needed to get around the error.
- Microsoft C++ Redistributable 2005
- Adobe Flash Player ActiveX
I may or may not be responsible for my own actions
|
|
|
|
|
Hallo,
I am reading a book on C# and I came to the following example.
class Employee { }
class ContractEmployee : Employee { }
class CastExample1
{
public static void Main ()
{
Employee e = new ContractEmployee();
}
}
So my question is maybe simple: which properties and methods does the object e has? Those from the base class Employee or of the derived class ContractEmployee? Maybe it is the syntax that confuses me... how should I read this? Let's create an Object which belongs to the Employee class but gets all its properties from the ContractEmployee class? Or maybe it's the opposite that is true? I really don't get it and I would appreciate an explanation. Thanks in advance.
|
|
|
|
|
If you did it like this
class Employee
{
public void Talk()
{
MessageBox.Show("I am an Employee.");
}
}
class ContractEmployee: Employee
{
public void ContractTalk()
{
MessageBox.Show("I am a Contract Employee.");
}
}
and then tried to do this
static void CreateEmployee()
{
Employee e = new ContractEmployee();
e.Talk();
e.ContractTalk();
}
you would see that e only has access to e.Talk(). The compiler throws an error when you try and access e.ContractTalk() because e does not have access to ContractEmployee's methods. I think the example in the book is misleading because you aren't doing anything by decalring an Employee and instantiating a ContractEmployee. It would be different if Employee was an abstract class and it implemented an interface. Then derived classes would be forced to implement the methods defined in the interface, something like this,
interface IEmployee
{
void Talk();
}
abstract class Employee : IEmployee
{
public abstract void Talk();
}
class PermanentEmployee:Employee
{
public override void Talk()
{
MessageBox.Show("I am a Permanent Employee.");
}
}
class ContractEmployee: Employee
{
public override void Talk()
{
MessageBox.Show("I am a Contract Employee.");
}
}
then it would make sense to do something like this
static void CreateEmployee()
{
Employee e = new ContractEmployee();
e.Talk();
e = new PermanentEmployee();
e.Talk();
}
Hope this helps
...and I have extensive experience writing computer code, including OIC, BTW, BRB, IMHO, LMAO, ROFL, TTYL.....
|
|
|
|
|
Since e is defined as an Employee then it only has access to the properties and methods of the base class. However, you should go back to the book to see what the author is trying to illustrate with this sample, as any comments made here will most likely be out of context.
The best things in life are not things.
|
|
|
|
|
The book is about casting and the author says that the above is legal instead the following is not:
class Employee { }
class ContractEmployee : Employee { }
class CastExample2
{
public static void Main ()
{
ContractEmployee ce = new Employee();
}
}
And this is ok for me, but still I do not understand why is such a declaration useful and what it actually means. If I declare
Employee e = new ContractEmployee()
and e has the properties of the Employee class, why then not write
Employee e = new Employee()
as we "normally" do? What is the difference between those two?
|
|
|
|
|
As I said before, you need to go back to the book and see where the author is going with this. There are often cases where you would do this when passing an object through some code that knows about Employee s but does not know about ContractEmployee s. Some common code could adjust the properties of e without needing to know what type of employee the object refers to. At some later point you could upcast e to a ContractEmployee and process as necessary.
The best things in life are not things.
|
|
|
|
|
nstk wrote: And this is ok for me, but still I do not understand why is such a declaration useful and what it actually means. If I declare
Employee e = new ContractEmployee()
and e has the properties of the Employee class, why then not write
Employee e = new Employee()
as we "normally" do? What is the difference between those two?
The first code line means you create a new instance of class ContractEmployee. This object in memory *is* a ContractEmployee. You then have a variable e which is an Employee. Since a ContractEmployee is specifically also an Employee (ContractEmployee derives from Employee) this is a valid assigment.
The difference between the two lines is that in the first, e behaves like a ContractEmployee and in the second e behaves like an Employee.
However, through e you can only access members of ContractEmployee which are also part of Employee.
The most important thing to distinguish in these examples is the difference between the actual object created (and in memory), which is specified by new, and the interface you are using to access it.
The actual object you create is different in both examples, but the interface you use to access them is the same.
To properly explain this sample, we'd need to explain almost everything about classes and inheritance, and it seems you're not there yet. So probably, it's best to keep those questions in the back of your head until you get to that subject and ask them again; probably, you'll find you know the answers
|
|
|
|
|
Nice explanation.
The best things in life are not things.
|
|
|
|
|
I thought of it, that maybe it is one of the questions that is going to be answered by itself with time. Nevertheless, thank you for your descriptive answer, it helps a lot. There is however one point regarding the following:
MicroVirus wrote: The difference between the two lines is that in the first, e behaves like a ContractEmployee and in the second e behaves like an Employee.
In that case shouldn't have been the same if we wrote:
ContractEmployee e = new ContractEmployee()
|
|
|
|
|
In short, such a declaration is useful because of polymorphism. Code which does not know about ContractEmployee can still call methods on it if they are overrides of virtual (or abstract or interface-defined) methods of a base class. For example consider the class hierarchy (another common OO tutorial one):
abstract class Animal {
public abstract string Noise { get; }
public virtual string Feed() { return "Mm, tasty."; }
}
class Dog : Animal {
public override string Noise { get { return "Woof."} }
public void GiveBone() { Console.WriteLine("Chomp."); }
}
class Cow : Animal {
public override string Noise { get { return "Moo."; } }
public override string Feed() { return "I'll only eat it if it's green."; }
}
Now, because the methods are virtual, polymorphism will ensure that the appropriate one is called when they are dispatched on an instance of Animal, and 'down-casting' to feed instances to a more generic (in the normal English sense of the word) method is appropriate:
void FeedAndListen(Animal animal){
Console.WriteLine(animal.Feed());
Console.WriteLine(animal.Noise);
}
static void Main(){
List<Animal> animals = new List<Animal>();
animals.Add(new Dog());
animals.Add(new Cow());
foreach(Animal animal in animals) FeedAndListen(animal);
}
Note how FeedAndListen produces the output from the derived methods, even though the instances are 'downcasted' into a List<Animal> and passed to it as Animal, not their actual declaration class. Also note how you can put the different subclasses into the one list. Finally, see how Dog inherits the Feed behaviour because it is not overridden. And you can't call methods which are not defined on the base class.
I agree with the other comment which says that as you complete your OO training you will naturally see how these concepts work.
|
|
|
|
|
BobJanova wrote: Code which does not know about ContractEmployee can still call methods on it if they are overrides of virtual (or abstract or interface-defined) methods of a base class.
This is also an answer that explains a lot. Thank you.
|
|
|
|
|
You have Employee instance and you assign an instance of the ContractEmployee to it. So you can do something like this (I'll take example from Wayne Gaylard):
class Employee
{
public void Talk()
{
MessageBox.Show("I am an Employee.");
}
}
class ContractEmployee: Employee
{
public void ContractTalk()
{
MessageBox.Show("I am a Contract Employee.");
}
}
Then you can do:
static void CreateEmployee()
{
Employee e = new ContractEmployee();
e.Talk();
((ContractEmployee)e).ContractTalk();
}
But you can't do:
static void CreateEmployee()
{
Employee e = new Employee();
e.Talk();
((ContractEmployee)e).ContractTalk();
}
On this example it seems useless, but it is sometimes useful. For example you can have a class structure of different user type, all inheriting from User , you can store them on in a collection of User s
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
|
|
|
|
|
Let's make a better example for this:
class Employee
{
public string Name { get; set; }
}
class ContractEmployee : Employee
{
public object Contract { get; set; }
}
class Program
{
static void Main()
{
Employee e = new ContractEmployee();
e.Name = "Ricky";
e.Contract = new object();
}
}
nstk wrote: which properties and methods does the object e has?
e object, at runtime, has the properties and methods defined within ContractEmployee class, because it is the object you have created with new, so it has Name (inherited from Employee class), and Contract (defined within ContractEmployee ). However, without any casting, from e object you will only be able to access those members defined within Employee class (Name property in this case), because it is the type you have used to declare the object. Why? Because e object is declared as Employee , and Employee does not define a member named Contract . Yes, e is a ContractEmployee instance and, yes, it has a Contract property, but the compiler does not know it. All the compiler knows is that e object is declared as Employee , so it allows you to access only the members defined in Employee class. So, if you want to access the Contract property of e object, in this case, you would need a previous casting operation:
((ContractEmployee)e).Contract = new object();
ContractEmployee ce = (ContractEmployee)e;
ce.Contract = new object();
nstk wrote: how should I read this?
Any ContractEmployee object is a Employee , always, so you can declare an Employee and instantiate a ContractEmployee , but not in the other direction, I mean, not all of the Employee objects have to be ContractEmployee .
|
|
|
|
|
The object refered to by e is a ContractEmployee and therefore contains all the trimmings of a ContractEmployee . However... because e has been declared as an Employee , it exposes only those properties and methods defined by the base class. In other words, the following test will succeed:
1 Employee e = new ContractEmployee();
2 Debug.Assert (e is Employee);
3 Debug.Assert (e is ContractEmployee());
For e to expose its ContractEmployee properties and methods, you'd need to first cast it to a ContractEmployee .
1 Employee e = new ContractEmployee();
2 ContractEmployee ce = e as ContractEmployee;
3
4 Debug.Assert (ce != null);
/ravi
|
|
|
|
|
nstk wrote: Or maybe it's the opposite that is true?
Yes. It is indeed the opposite that is true.
The sub class has access to all the protected members of the parent class but not the other way round.
Whenever we say we have a object deriving from something, we are always assuming that this object has properties of the parent and adds on some of its own.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
Hi,
is it possible use as argument of reused constructor something calculated in the constructor itself?
something like
Test(double b_):this(b_,c)
but where c comes from constructor itself. A simplified example:
lass Test
{
double area;
public Test(double b_)
{
double c = b_ * Math.Sqrt(44);
}
public Test(double b_ , double l)
{
area = b * l;
}
}
Thanks for your time
TheGermoz
|
|
|
|