|
You're going to have to describe what you mean by "three dimensional".
|
|
|
|
|
I would prefer to see one, rather than reading about it.
Will I need stereo glasses?
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
|
|
|
|
|
The funky white cardboard/paper ones work best!
|
|
|
|
|
I'm sure workable 3D displays will be with us soon.
Probably about the same time we get those 21st century flying cars...
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
|
Ah, by "workable" I meant one that doesn't need glasses. I remember trying out the some early LCD shutter glasses and hi-res projectors about 12 to 15 years ago, and it was impressive even back then, but things haven't really advanced much since.
I'm waiting for a proper hi-def, full colour 3D image I can move around, and / or rotate in any direction. A haptic interface to go with it would be nice too...
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
|
I mean with three dimensional is that..........
If i needed to use a fighter plane as a form for my windows application and I wish to generate different events on the clicks of body of plane. or any other event( else click ) .
|
|
|
|
|
Alright. This explanation isn't that great either. i'm just going to say that you cannot use a 3D model as a form. You can SHOW a 3D model IN a form and have various part of the model clickable. It would require DirectX to be able to do this. I would suggest starting with the XNA Framework and learning the basics of 3D modeling and using XNA first.
|
|
|
|
|
I have created one control in Vb.net in I am calling Webservice in the contorl.Now I using this control in VB 6 , but I am getting error as
"Coult not find default endpoint element that references contract "webservice name" in the Service Model Client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching the contract cout be found in the client element "
Please do the needful.
Paresh Gujararathi
|
|
|
|
|
Paresh Gujarathi wrote: This might be because no configuration file was found for your application
This should be the big hint. VB6 doesn't use app.config files, so you're going to have to setup every thing that would normally be done automatically by the app.config file yourself in your control. Though, since I haven't used VB6 is quite a long time, I'm just guessing here.
|
|
|
|
|
Paresh Gujarathi wrote: Please do the needful.
Done. [voted the question as 'Bad Question']
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
|
Ok, I've Googled myself silly...
In my base class I overload the == operator (including GetHashCode , != and Equals ) and when I do a customerA == customerB it works 100%, yet when I do a customersList.IndexOf(customerA) I always get -1 even though I can see a customer instance in the list that should return true in my overloaded operator, and when I place a break point in my operator overloader it stops when I do a == , but it does not break when I do an IndexOf() ...
Help please...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
|
Mark Nischalke wrote: You'll need to implement IEqualityComparer[^] in your base class
Hi Mark,
I found that implementing this in my base class did not give me what I needed, implementing it in my actual (child) class however gave me what I needed, does that make sense to you?
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Show what you have done and maybe someone can give you advice.
only two letters away from being an asset
|
|
|
|
|
Its a rather elaborate thing, would have to create a new project to explain in one shot.
Will have to try explain tomorrow, need to go now
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
hi
first what kind of type is your customer list ?? is it a generic list<customer> or just a arraylist containing objects?!? overload the customerlist operators too for correct comparing i would suggest
greetz
|
|
|
|
|
I'm using a ObservableCollection as generated for the Silverlight 3 Service in the Proxy...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Found the (strange) answer...
== , .Equals() and != works fine if you implement in the base object, but to be able to overload for Collection<T>.IndexOf() you MUST implement IEquatable<Customer> on the Customer object, not on the base...
If this makes sense to anybody please explain to me as I'n jealous...
PS: I'm working in Silverlight 3, please tell me this is not a SL 3 issue...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
I think I might be able to explain, but it depends on your current code. From reading your posts, you seem to have something like this:
public class Base : IEquatable<Base>
{
public static bool operator==(...)
{
...
}
}
public class Derived : Base
{
}
The question is, do you have Collection<Base> or Collection<Derived> ? If you use Reflector to dig through the EqualityComparer code, you will see that it checks for IEquatable<T> where T is the exact type of the collection. Thus, if you have a collection of Derived, I would expect you to need to implement IEquatable on Derived. Since you have only implemented IEquatable<Base> , the check for IEquatable<Derived> will fail and you will fall back to the default implementation. Though, if you overrode the Equals inherited from object, I would think it should get called from the default comparer.
|
|
|
|
|
Hi Gideon, thanks, that explains why it works the way it does, but doesn't explain why it doesn't use == or .Equals() Not sure why there are so many ways to check equality... Or why .IndexOf() has to use IEquatable<Derived> when other methods does not...
Anyway, thanks for the description, makes sense
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
I believe the C# operators like "==" are only visible to the C# compiler, and are not visible to the underlying .Net library. As for why there are so many different types of equality, I think the idea is that there are different 'qualities' of equality. For example, for some purposes, the string "ABC" may be regarded as equal to "abc" or even "åbç", while in others it must be regarded as different. I'm not sure the exact logic behind which functions are used where in .Net; I can certainly imagine that it would be useful to be able to specify a definition of equality which did not require two objects to have the same GetHashCode value (since such a value must be optimized for one particular definition of equality); I'm not sure whether any of the defined equality functions use such a definition.
|
|
|
|
|
Actually, the operators are visible to all languages. They are actually defined as methods with names such as op_Equality, op_Inequality, etc. and other languages can use their operators to call those methods.
You are on the right track as far as qualities of equality, though strings are a weird case where there are quite a few different "levels" of equality. My response below explains what I see as reasons for different equality methods if you are interested.
|
|
|
|
|
There are so many ways to check equality because there are so many situations that need to be handled. Jared Parsons wrote a nice set of articles that explain some of this topic. The link is to the last article in the set, each of which links to the article before (in typical blog fashion).
One reason to have more than just the operator is because the operator must be a static method. This means that which operator to call depends on the compile-time type of the variable instead of the using the runtime-type like a virtual method (such as Equals) would. Also, because they are static, operators cannot be defined on interfaces. So if you need equality methods on an interface, you have to have instance methods. An advantage of the IEqualityComparer interface is that you can have a different condition for "equality" in different situations for the same type. In one case, you may only check the name, but in another you may want to check both the name and the age. This would be impossible with just the operator or overriden virtual method, but is possible to do with the extra interface. (A similar reasoning can be given for having both IComparer and IComparable for sorting.)
C# has a particularly nasty problem when it comes to == vs .Equals(). In C#, if you write if (a == b) { ... } when there is no overloaded operator for the types of variables a and b, the compiler will check to see if the are both references to the same object. In VB however, writing If a = b Then ... when there is no overloaded operator, a compile error will occur. To see if a and b are references to the same object, you use the Is and IsNot operators.
Collection<Derived>.IndexOf has to use IEquatable<Derived> because it was written without any knowledge of what your classes will be. The alternative would involve a bunch of messy reflection code that would cause horrible performance and would probably not be useful in most situations. All the other places where you are using == and Equals, the compiler knows about and will use your methods since they are the best match. Out of curiosity, did you both implement the Equals for IEquatable<Base> and override the Equals from object?
public class Base : IEquatable<Base>
{
public static bool operator==(...)
{
...
}
public bool Eqauls(Base other)
{
}
public override bool Equals(object obj)
{
}
}
If you did, I would expect that before you implemented IEquatable<Derived> , the default algorithm used by IndexOf should have called the override and gotten what you wanted.
|
|
|
|