|
Yes.. I would need 3 arc (one for each corner). I need to figure out how to do the arc so I can eliminate the sharp corner of the triangle. I think I need to use the AddBezier method. I'm working on that now with the calculations.
|
|
|
|
|
when you add arcs you don't have to add lines.. the are added automatically..
Blubbo wrote: I think I need to use the AddBezier
you can but as you started with arcs you can try getting a proper angle so the transion between arc and line wouldn't be visible..
life is study!!!
|
|
|
|
|
Ahh now that makes more sense! I'll try that!
|
|
|
|
|
I used AddBezier method for each of 3 curves (per my calculations) and it worked great!
Thanks a heap! 
-- modified at 13:43 Wednesday 16th May, 2007
|
|
|
|
|
hi i have devoloped windows application,
i wanna update that perticular developed version with my current(yet to develop)windows application
can u please let me know how to fine and compare the versions,
i got my current(yet to develop-update version's) assembly by using Assembly.GetExecutingAssembly().ToString()
but, i want knw the current deployed version's assembly name
so that i can find and update if its lower version else give a prompt saying this is already updated version..
hope u got my requirement
thnx in advance
prashanth
|
|
|
|
|
Assembly myAssembly = Assembly.GetExecutingAssembly();
FileVersionInfo info = FileVersionInfo.GetVersionInfo(myAssembly.Location);
// info.ProductVersion gives you the complete version.
// fileVersionInfo also contains many other property for details.
Hope this helps.
Regards
|
|
|
|
|
Nice to find an expert on an important function. y any chance, do you know if the following snippet is how to get the hinstance we should pass to Bitmap.FromResource()?
<code> String s = "MT_ConfirmREFRESH";
IntPtr h = Process.GetCurrentProcess( ).Handle;
try
{
Glyph1.GMap = Bitmap.FromResource( h, s );
}
catch
{
throw new Exception( "Bitmap resource " + s + " not found from process handle " + h.ToString( ) + "." );
}
</code>Documentation indicates that hinstance is supposed to be "A handle to an instance of the executable file that contains the resource." The snippet is part of a method of a class belonging to a .DLL to which the resource(s) have been added by the visual Project.Properties... Add existing file... process. When this code fails, the FCL message only indicates that "the" (a) parameter is not valid. The resources ostensibly exist. I assume the handle value is the most probable candidate for the problem, unless there is some problem with the registration of the resources which I am not aware of.
Much thanks,
m
|
|
|
|
|
In other words, the following approach does identify the assembly I need to identify, but I run into a dead end trying to get an IntPtr handle from the "ModuleHandle" struct:
Type t = this.GetType( );
Assembly a = Assembly.GetAssembly( t );
ModuleHandle mh = a.GetModule( "APC" ).ModuleHandle;
Do you know of a way to get the IntPtr value that will return the resources we need to find with Bitmap.FromResource()?
|
|
|
|
|
Hello,
I'm not an expert at all, but I found this article, where it is done by an "Kernel32.dll" method call.
http://www.codeproject.com/cs/miscctrl/XPTaskBar.asp[^]
[DllImport("Kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern IntPtr LoadLibrary(string lpFileName);
Hope it helps!
All the best,
Martin
|
|
|
|
|
Thanks, Martin, but the problem here is the approach is not CLS compliant. We need to be able to do this with managed code. It's "as if" Microsoft left out a vital bridge so that, as we are obstructed from a managed solution, we are forced to write Microsoft-dependent approaches.
|
|
|
|
|
Ok, I see!
P.S.: Have no idea why somebody voted "2" for your statement?
Gave you "5" to bring it back in shape!
All the best,
Martin
|
|
|
|
|
hi all
i have a problem to show a picture or gif image b/w request and response (b/w server and the client).
what i tried was image visible false basically...
when button click when it request server i made the image visible true...
but the image is visible only after the response from the server ...
what should i do...???
bye
|
|
|
|
|
Hi All,
Am just learning things. Can you explain me whether an Interface is a super set to Abstract Classes?
In what way Abstract Classes can prove more useful than an interfaces? I know that it is not instantiable. Can you give me a small scenario were Abstract Class will be the only solution rather than using Interfaces?
Regards,
Panicker.
|
|
|
|
|
|
Thnx Stefan.
Regards,
Panicker.
|
|
|
|
|
An interface defines a contract. It contains only signatures of methods, properties, etc.
An abstract class can contain implementations, but cannot be instantiated.
A good way to determine if you need an abstract class vs. interface would be:
If you plan on having derived objects, all of which will need to do some of the same thing, you should use an abstract class.
Keep in mind, that abstract classes and interfaces can be used in conjunction where appropriate.
|
|
|
|
|
Can we say that Interface is pure virtual form of an abstract class? (similar to OOPS concept)
-rt
|
|
|
|
|
ArtiGujare wrote: Can we say that Interface is pure virtual form of an abstract class? (similar to OOPS concept)
Yes, you could, but I don't know if that would make it less or more confusing...
An interface contains no implementation, in much the same way that a pure virtual method doesn't contain any implementation.
However, an important difference is that you inherit a class, but you implement an interface. As .NET doesn't have multiple inheritance, a class can only inherit from one base class, but you can make a class implement as many interfaces as you like.
---
single minded; short sighted; long gone;
|
|
|
|
|
Another example you often see is an abstract class partially implementing an interface. A good example of this is System.Collections.DictionaryBase providing partial implementation of common functionality to System.Collections.IDictionary interface.
-----
Formerly MP(2)
If atheism is a religion, then not collecting stamps is a hobby. -- Unknown
|
|
|
|
|
Thnx Centriste nd Guffa.
Regards,
Panicker.
|
|
|
|
|
Paul,thnx fr the clarification.
Regards,
Panicker.
|
|
|
|
|
Hi..Let me make it clear to you that interface is not a substitue for abstract class..Abstract class simply act as a base for all the classes that are derived from it(for ex lets say class stundent,class teacher is derived from some class "xyz" which contains feild called organization name,which is reqd by both the derived classes).Since this base class alone itself is of no use so by adding keyword abstract it is restricted from getting Instansiate.
Now coming to Interface...since c# does not support multiple inheritance so we can use interface where we will mention method signature only..and the class implementing interface should define that method..now u might be thinking that how interface will be a solution for non supporting multiple inheritance nature of c#..well in a class you can implement multiple interfaces..
Well abstract class and interface are often seen together..reason is that we need not to implement interface for each class separetly..so implement interface for abstract class which acts as a base class and all the classes that derived from this abstract class can make use of interface implemented once for abstract class..
|
|
|
|
|
Rahul thnx fr ur detailed explanation.
Regards,
Panicker.
|
|
|
|
|
Difference between Abstract classes and Interface
Little background:
A real world entity is represented in an OOP world as object. Objects are defined as classes any language.
A class defines objects in two aspects
Object's characteristics - Data Members
Object's functionality - Member functions
So, when the classes that are forced to provide implementations of the functions prototypes that are defined in either ‘interfaces’ or a ‘abstract class’ are not belonging to the same family (having some inherited parental characteristics from same parent directly or indirectly) but are rather related through some functionalities then 100% we will go with interface and if above said classes are belonging to same family then we should go with abstract class inheritance.
Also in case of inheritance as everything is a specialization of base parent object so there is allowance of providing some default definitions of the functions that are needed to be implemented further by specialized classes. This is not any way allowed in interfaces because implementing classes are not belonging to same family and are not any way related by characteristics.
An Example:
We have four real world objects:
• Airplane
• Bird
• Sparrow
• Eagle
We have one method that is a functionality of all above objects
• Fly
Now all objects share common functionality flying in air but differ in the mechanism they use to fly.
Also by close look we see that in general there is some common characteristics (as well as some common functionalities) between Sparrow and Eagle that can be a part of common class Bird (that has to be abstract because there is no real thing like bird!). But any way Airplane can't be related to Bird or its specialized classes Sparrow and Eagle.
So if want to expose fly functionality to outer world and want their implementations in Airplane and Sparrow (or any bird), so I will 100% go for Interface and Abstract classes will be a big NO!
But if we exclude Airplane want that fly functionality is exposed to outer world and its implementing classes are Bird, Sparrow and Eagle then 'Abstract Classes' is the best of best choice.
Happy programming! Please feel free in writing to me for further clarifications on other OOP concepts (im.himanshu2006@gmail.com)
Himanshu
|
|
|
|
|
Difference between Abstract classes and Interface
Little background:
A real world entity is represented in an OOP world as object. Objects are defined as classes any language.
A class defines objects in two aspects
Object's characteristics - Data Members
Object's functionality - Member functions
So, when the classes that are forced to provide implementations of the functions prototypes that are defined in either ‘interfaces’ or a ‘abstract class’ are not belonging to the same family (having some inherited parental characteristics from same parent directly or indirectly) but are rather related through some functionalities then 100% we will go with interface and if above said classes are belonging to same family then we should go with abstract class inheritance.
Also in case of inheritance as everything is a specialization of base parent object so there is allowance of providing some default definitions of the functions that are needed to be implemented further by specialized classes. This is not any way allowed in interfaces because implementing classes are not belonging to same family and are not any way related by characteristics.
An Example:
We have four real world objects:
• Airplane
• Bird
• Sparrow
• Eagle
We have one method that is a functionality of all above objects
• Fly
Now all objects share common functionality flying in air but differ in the mechanism they use to fly.
Also by close look we see that in general there is some common characteristics (as well as some common functionalities) between Sparrow and Eagle that can be a part of common class Bird (that has to be abstract because there is no real thing like bird!). But any way Airplane can't be related to Bird or its specialized classes Sparrow and Eagle.
So if want to expose fly functionality to outer world and want their implementations in Airplane and Sparrow (or any bird), so I will 100% go for Interface and Abstract classes will be a big NO!
But if we exclude Airplane want that fly functionality is exposed to outer world and its implementing classes are Bird, Sparrow and Eagle then 'Abstract Classes' is the best of best choice.
Happy programming! Please feel free in writing to me for further clarifications on other OOP concepts (im.himanshu2006@gmail.com)
Himanshu
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
