Search Results

Search found 14034 results on 562 pages for 'interface inheritance'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 24/562 | < Previous Page | 20 21 22 23 24 25 26 27 28 29 30 31  | Next Page >

  • Implicit and Explicit implementations for Multiple Interface inheritance

    Following C#.NET demo explains you all the scenarios for implementation of Interface methods to classes. There are two ways you can implement a interface method to a class. 1. Implicit Implementation 2. Explicit Implementation. Please go though the sample. using System; namespace ImpExpTest {     class Program     {         static void Main(string[] args)         {             C o3 = new C();             Console.WriteLine(o3.fu());             I1 o1 = new C();             Console.WriteLine(o1.fu());             I2 o2 = new C();             Console.WriteLine(o2.fu());             var o4 = new C();       //var is considered as C             Console.WriteLine(o4.fu());             var o5 = (I1)new C();   //var is considered as I1             Console.WriteLine(o5.fu());             var o6 = (I2)new C();   //var is considered as I2             Console.WriteLine(o6.fu());             D o7 = new D();             Console.WriteLine(o7.fu());             I1 o8 = new D();             Console.WriteLine(o8.fu());             I2 o9 = new D();             Console.WriteLine(o9.fu());         }     }     interface I1     {         string fu();     }     interface I2     {         string fu();     }     class C : I1, I2     {         #region Imicitly Defined I1 Members         public string fu()         {             return "Hello C"         }         #endregion Imicitly Defined I1 Members         #region Explicitly Defined I1 Members         string I1.fu()         {             return "Hello from I1";         }         #endregion Explicitly Defined I1 Members         #region Explicitly Defined I2 Members         string I2.fu()         {             return "Hello from I2";         }         #endregion Explicitly Defined I2 Members     }     class D : C     {         #region Imicitly Defined I1 Members         public string fu()         {             return "Hello from D";         }         #endregion Imicitly Defined I1 Members     } } Output:- Hello C Hello from I1 Hello from I2 Hello C Hello from I1 Hello from I2 Hello from D Hello from I1 Hello from I2 span.fullpost {display:none;}

    Read the article

  • Getting the constructor of an Interface Type through reflection?

    - by Will Marcouiller
    I have written a generic type: IDirectorySource<T> where T : IDirectoryEntry, which I'm using to manage Active Directory entries through my interfaces objects: IGroup, IOrganizationalUnit, IUser. So that I can write the following: IDirectorySource<IGroup> groups = new DirectorySource<IGroup>(); // Where IGroup implements `IDirectoryEntry`, of course.` foreach (IGroup g in groups.ToList()) { listView1.Items.Add(g.Name).SubItems.Add(g.Description); } From the IDirectorySource<T>.ToList() methods, I use reflection to find out the appropriate constructor for the type parameter T. However, since T is given an interface type, it cannot find any constructor at all! Of course, I have an internal class Group : IGroup which implements the IGroup interface. No matter how hard I have tried, I can't figure out how to get the constructor out of my interface through my implementing class. [DirectorySchemaAttribute("group")] public interface IGroup { } internal class Group : IGroup { internal Group(DirectoryEntry entry) { NativeEntry = entry; Domain = NativeEntry.Path; } // Implementing IGroup interface... } Within the ToList() method of my IDirectorySource<T> interface implementation, I look for the constructor of T as follows: internal class DirectorySource<T> : IDirectorySource<T> { // Implementing properties... // Methods implementations... public IList<T> ToList() { Type t = typeof(T) // Let's assume we're always working with the IGroup interface as T here to keep it simple. // So, my `DirectorySchema` property is already set to "group". // My `DirectorySearcher` is already instantiated here, as I do it within the DirectorySource<T> constructor. Searcher.Filter = string.Format("(&(objectClass={0}))", DirectorySchema) ConstructorInfo ctor = null; ParameterInfo[] params = null; // This is where I get stuck for now... Please see the helper method. GetConstructor(out ctor, out params, new Type() { DirectoryEntry }); SearchResultCollection results = null; try { results = Searcher.FindAll(); } catch (DirectoryServicesCOMException ex) { // Handling exception here... } foreach (SearchResult entry in results) entities.Add(ctor.Invoke(new object() { entry.GetDirectoryEntry() })); return entities; } } private void GetConstructor(out ConstructorInfo constructor, out ParameterInfo[] parameters, Type paramsTypes) { Type t = typeof(T); ConstructorInfo[] ctors = t.GetConstructors(BindingFlags.CreateInstance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.InvokeMethod); bool found = true; foreach (ContructorInfo c in ctors) { parameters = c.GetParameters(); if (parameters.GetLength(0) == paramsTypes.GetLength(0)) { for (int index = 0; index < parameters.GetLength(0); ++index) { if (!(parameters[index].GetType() is paramsTypes[index].GetType())) found = false; } if (found) { constructor = c; return; } } } // Processing constructor not found message here... } My problem is that T will always be an interface, so it never finds a constructor. Might somebody guide me to the right path to follow in this situation?

    Read the article

  • Macbook Pro 8,1 - wireless interface not showing up

    - by Florian Margaine
    I've installed Ubuntu 11.10 on my Macbook Pro 8,1. Everything went fine and everything installs fine except for the wireless interface. I've installed the b43 module according to these instructions: https://help.ubuntu.com/community/MacBookPro8-1/Natty#Wireless I've tried compiling the module, ndiswrapper and also the last solution mentioned using this PPA: ppa:zwaldowski/ppa. With the three solutions, the module loads finely. It works smoothly. lspci shows the wireless card without problem. But there is no wireless interface. iwconfig or ifconfig both show eth0 and lo as interfaces, but no eth1 or wlan0 interface is showing up. I have no idea why, and I'm completely stuck there.

    Read the article

  • DIY Internet Radio Maintains Controls and Interface of Vintage Case

    - by Jason Fitzpatrick
    Updating an old radio for modern inputs/streaming audio isn’t a new trick but this DIY mod stands out by maintaining the original controls and interface style. Rather than replace the needle-style selector window with a modern text-readout or cover-flow style interface, modder Florian Amrhein opted to replace the old rectangular station selector with an LCD screen that emulates the same red-needle layout. Using the same knob that previously moved the needle on the analog interface, you can slide the digital selector back and forth to select Internet radio stations. Watch the video above to see it in action and hit up the link below for the build guide. 1930s Internet Radio [via Hack A Day] HTG Explains: Does Your Android Phone Need an Antivirus? How To Use USB Drives With the Nexus 7 and Other Android Devices Why Does 64-Bit Windows Need a Separate “Program Files (x86)” Folder?

    Read the article

  • When to use abstract classes instead of interfaces and extension methods in C#?

    - by Gulshan
    "Abstract class" and "interface" are similar type of ideas, while interface being more abstract. One need of abstract classes was to provide method implementations for the derived classes. But in C#, that need has also been reduced by lately introduced extension methods. So, in C#, when should we use abstract classes instead of using interfaces and extension methods associated with the interface? And now, we can use 'Properties' in interfaces also. A notable example of interface+ extension methods is the Heavily used IEnumerable and it's helper methods. You use Linq and it's all by this extension methods!

    Read the article

  • Java - What methods to put in an interface and what to keep out

    - by lewicki
    I'm designing a file handler interface: public interface FileHandler { public void openFileHandler(String fileName); public void closeFileHandler(); public String readLine(); public String [] parseLine(String line); public String [] checkLine(String line[]); public void incrementLineCount(); public void incrementLineSuccessCount(); public void incrementLineErrorCount(); public int getLineCount(); public int getLineSuccessCount(); public int getLineErrorCount(); } It is soon apparent to me that these methods can't be made private. I don't want incrementLineCount to be public. What is proper way to design an interface like this?

    Read the article

  • Disabling IPv6 on a single interface

    - by ijw
    I'm slightly weirded out by the fact that Ubuntu won't process ipv4 DHCP unless you explicitly tell it to, but will happily take ipv6 RAs unless you tell it not to. Is there any way to change the default behaviour to be 'do nothing unless I explicitly turn it on'? (Note to answerers: I'm not looking to globally disable ipv6, or completely turn off autoconf. I'm looking to disable autoconf by default (as in, I don't want ipv6 unless I say so in /etc/network/interfaces, in the same way that I don't just get a v4 address unless I've explicitly turned on dhcp). What's happening is that, for any interface that's up - e.g. has an ipv4 config - a v6 address tends to just turn up on the interface as well, despite the fact that I've not enabled that explicitly. The solutions to date are fine as far as they go, but if I disable v6 or autoconf globally, I can't then re-enable v6 on a per-interface basis with a simple command in /etc/network/interfaces. I'm fairly sure I'm asking for the moon on a stick, mind you.)

    Read the article

  • Use of keyword "Using" in C# interface

    - by Onno
    When I'm using C# to write some code and I define an interface using Visual Studio 2010, it always includes a number of "using" statements (as shown in the example) using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace TestEngine.TestNameSpace { interface ITest1 { bool testMethod(int xyz); } } I wonder what these are for and if they are really necessary. Can I leave these out? Are they only necessary when I'm using those parts in my interface description?

    Read the article

  • Google apporte une refonte à l'interface de son réseau social Google+, les développeurs mécontents

    Google apporte une refonte à l'interface de Google+ les développeurs mécontents Google est aux trousses de Facebook, et ne souhaite pas se laisser distancer par le réseau social. Après la mise à jour de Facebook avec l'introduction de Timeline, c'est au tour du réseau social Google+ de subir un lifting complet de son interface. Le géant de la recherche a annoncé dans un billet de blog une refonte du design du site qui se rapproche un peu plus de Facebook. L'interface conçue autour de la simplification et de la personnalisation, dispose désormais d'un ruban à gauche de l'écran donnant accès aux fonctionnalités les plus usuelles comme les photos et les profil...

    Read the article

  • Interface hierarchy design for separate domains

    - by jerzi
    There are businesses and people. People could be liked and businesses could be commented on: class Like class Comment class Person implements iLikeTarget class Business implements iCommentTarget Likes and comments are performed by a user(person) so they are authored: class Like implements iAuthored class Comment implements iAuthored People's like could also be used in their history: class history class Like implements iAuthored, iHistoryTarget Now, a smart developer comes and says each history is attached to a user so history should be authored: interface iHistoryTarget extends iAuthored so it could be removed from class Like: class Person implements iLikeTarget class Business implements iCommentTarget class Like implements iHistoryTarget class Comment implements iAuthored class history interface iHistoryTarget extends iAuthored Here, another smart guy comes with a question: How could I capture the Authored fact in Like and Comment classes? He may knows nothing about history concept in the project. By scalling these kind of functionallities, interfaces may goes to their encapsulated types which cause more type strength, on the other hand explicitness suffered and also code end users will face much pain to process. So here is the question: Should I encapsulate those dependant types to their parent types (interface hierarchies) or not or explicitly repeat each type for every single level of my type system or ...?

    Read the article

  • How to declare and implement a COM interface on C# that inherits from another COM interface?

    - by Carlos Loth
    I'm trying to understand what is the correct why to implement COM interfaces from C# code. It is straightforward when the interface doesn't inherit from other base interface. Like this one: [ComImport, Guid("2047E320-F2A9-11CE-AE65-08002B2E1262"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] public interface IShellFolderViewCB { long MessageSFVCB(uint uMsg, int wParam, int lParam); } However things start to become weired when I need to implement an interface that inherits from other COM interfaces. For example, if I implement the IPersistFolder2 interface which inherits from IPersistFolder which inherits from IPersist as I usually on C# code: [ComImport, Guid("0000010c-0000-0000-C000-000000000046"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] public interface IPersist { void GetClassID([Out] out Guid classID); } [ComImport, Guid("000214EA-0000-0000-C000-000000000046"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] public interface IPersistFolder : IPersist { void Initialize([In] IntPtr pidl); } [ComImport, Guid("1AC3D9F0-175C-11d1-95BE-00609797EA4F"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] public interface IPersistFolder2 : IPersistFolder { void GetCurFolder([Out] out IntPtr ppidl); } The operating system is not able to call the methods on my object implementation. When I'm debugging I can see the constructor of my IPersistFolder2 implementation is called many times, however the interface methods I've implemented aren't called. I'm implementing the IPersistFolder2 as follows: [Guid("A4603CDB-EC86-4E40-80FE-25D5F5FA467D")] public class PersistFolder: IPersistFolder2 { void IPersistFolder2.GetClassID(ref Guid classID) { ... } void IPersistFolder2.Initialize(IntPtr pidl) { ... } void IPersistFolder2.GetCurFolder(out IntPtr ppidl) { ... } } What seems strange is when I declare the COM interface imports as follow, it works: [ComImport, Guid("0000010c-0000-0000-C000-000000000046"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] internal interface IPersist { void GetClassID([Out] out Guid classID); } [ComImport, Guid("000214EA-0000-0000-C000-000000000046"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] internal interface IPersistFolder : IPersist { new void GetClassID([Out] out Guid classID); void Initialize([In] IntPtr pidl); } [ComImport, Guid("1AC3D9F0-175C-11d1-95BE-00609797EA4F"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] internal interface IPersistFolder2 : IPersistFolder { new void GetClassID([Out] out Guid classID); new void Initialize([In] IntPtr pidl); void GetCurFolder([Out] out IntPtr ppidl); } I don't know why it works when I declare the COM interfaces that way (hidding the base interface methods using new). Maybe it is related to the way IUnknown works. Does anyone know what is the correct way of implementing COM interfaces in C# that inherits from other COM interfaces and why?

    Read the article

  • Inheritance: when implementing an interface which define a base class property why cant the class im

    - by Deepak
    Lets create some interfaces public interface ITimeEventHandler { string Open(); } public interface IJobTimeEventHandler: ITimeEventHandler { string DeleteJob(); } public interface IActivityTimeEventHandler: ITimeEventHandler { string DeleteActivity(); } public interface ITimeEvent { ITimeEventHandler Handler; } Another Interface public interface IJobTimeEvent :ITimeEvent { int JobID; } Create a class public class JobTimeEvent : IJobTimeEvent { public int JobID = 0; public IJobTimeEventHandler Handler = null; } My question is .. when implementing an interface which define a base class property why cant the class implementing interface return a derived class type object ?? For ex in class JobTimeEvent, IJobtimeEvent needs a property of type ITimeEventHandler but why IJobTimeEventHandler type is not allowed which derived from ITimeEventHandler

    Read the article

  • Multiple Inheritance Debates II: according to Stroutroup

    - by asksuperuser
    I know very well about the traditional arguments about why Interface Inheritance is prefered to multiple inheritance, there has been already a post here : http://stackoverflow.com/questions/191691/should-c-include-multiple-inheritance But according to Stroutroup the real reason why Microsoft and Sun decided to get rid off multiple inheritance is that they have vested interest to do so: instead of putting features in the languages, they put in frameworks so that people then become tied to their platform instead of people having the same capability at a language standard level. What do you think ?

    Read the article

  • Is this Hybrid of Interface / Composition kosher?

    - by paul
    I'm working on a project in which I'm considering using a hybrid of interfaces and composition as a single thing. What I mean by this is having a contain*ee* class be used as a front for functionality implemented in a contain*er* class, where the container exposes the containee as a public property. Example (pseudocode): class Visibility(lambda doShow, lambda doHide, lambda isVisible) public method Show() {...} public method Hide() {...} public property IsVisible public event Shown public event Hidden class SomeClassWithVisibility private member visibility = new Visibility(doShow, doHide, isVisible) public property Visibility with get() = visibility private method doShow() {...} private method doHide() {...} private method isVisible() {...} There are three reasons I'm considering this: The language in which I'm working (F#) has some annoyances w.r.t. implementing interfaces the way I need to (unless I'm missing something) and this will help avoid a lot of boilerplate code. The containee classes could really be considered properties of the container class(es); i.e. there seems to be a fairly strong has-a relationship. The containee classes will likely implement code which would have been pretty much the same when implemented in all the container classes, so why not do it once in one place? In the above example, this would include managing and emitting the Shown/Hidden events. Does anyone see any isseus with this Composiface/Intersition method, or know of a better way? EDIT 2012.07.26 - It seems a little background information is warranted: Where I work, we have a bunch of application front-ends that have limited access to system resources -- they need access to these resources to fully function. To remedy this we have a back-end application that can access the needed resources, with which the front-ends can communicate. (There is an API written for the front-ends for accessing back-end functionality as though it were part of the front-end.) The back-end program is out of date and its functionality is incomplete. It has made the transition from company to company a couple of times and we can't even compile it anymore. So I'm trying to rewrite it in my spare time. I'm trying to update things to make a nice(r) interface/API for the front-ends (while allowing for backwards compatibility with older front-ends), hopefully something full of OOPy goodness. The thing is, I don't want to write the front-end API after I've written pretty much the same code in F# for implementing the back-end; so, what I'm planning on doing is applying attributes to classes/methods/properties that I would like to have code for in the API then generate this code from the F# assembly using reflection. The method outlined in this question is a possible alternative I'm considering instead of implementing straight interfaces on the classes in F# because they're kind of a bear: In order to access something of an interface that has been implemented in a class, you have to explicitly cast an instance of that class to the interface type. This would make things painful when getting calls from the front-ends. If you don't want to have to do this, you have to call out all of the interface's methods/properties again in the class, outside of the interface implementation (which is separate from regular class members), and call the implementation's members. This is basically repeating the same code, which is what I'm trying to avoid!

    Read the article

  • Oracle Applications Cloud Release 8 Customization: Your User Interface, Your Text

    - by ultan o'broin
    Introducing the User Interface Text Editor In Oracle Applications Cloud Release 8, there’s an addition to the customization tool set, called the User Interface Text Editor  (UITE). When signed in with an application administrator role, users launch this new editing feature from the Navigator's Tools > Customization > User Interface Text menu option. See how the editor is in there with other customization tools? User Interface Text Editor is launched from the Navigator Customization menu Applications customers need a way to make changes to the text that appears in the UI, without having to initiate an IT project. Business users can now easily change labels on fields, for example. Using a composer and activated sandbox, these users can take advantage of the Oracle Metadata Services (MDS), add a key to a text resource bundle, and then type in their preferred label and its description (as a best practice for further work, I’d recommend always completing that description). Changing a simplified UI field label using Oracle Composer In Release 8, the UITE enables business users to easily change UI text on a much wider basis. As with composers, the UITE requires an activated sandbox where users can make their changes safely, before committing them for others to see. The UITE is used for editing UI text that comes from Oracle ADF resource bundles or from the Message Dictionary (or FND_MESSAGE_% tables, if you’re old enough to remember such things). Functionally, the Message Dictionary is used for the text that appears in business rule-type error, warning or information messages, or as a text source when ADF resource bundles cannot be used. In the UITE, these Message Dictionary texts are referred to as Multi-part Validation Messages.   If the text comes from ADF resource bundles, then it’s categorized as User Interface Text in the UITE. This category refers to the text that appears in embedded help in the UI or in simple error, warning, confirmation, or information messages. The embedded help types used in the application are explained in an Oracle Fusion Applications User Experience (UX) design pattern set. The message types have a UX design pattern set too. Using UITE  The UITE enables users to search and replace text in UI strings using case sensitive options, as well as by type. Users select singular and plural options for text changes, should they apply. Searching and replacing text in the UITE The UITE also provides users with a way to preview and manage changes on an exclusion basis, before committing to the final result. There might, for example, be situations where a phrase or word needs to remain different from how it’s generally used in the application, depending on the context. Previewing replacement text changes. Changes can be excluded where required. Multi-Part Messages The Message Dictionary table architecture has been inherited from Oracle E-Business Suite days. However, there are important differences in the Oracle Applications Cloud version, notably the additional message text components, as explained in the UX Design Patterns. Message Dictionary text has a broad range of uses as indicated, and it can also be reserved for internal application use, for use by PL/SQL and C programs, and so on. Message Dictionary text may even concatenate together at run time, where required. The UITE handles the flexibility of such text architecture by enabling users to drill down on each message and see how it’s constructed in total. That way, users can ensure that any text changes being made are consistent throughout the different message parts. Multi-part (Message Dictionary) message components in the UITE Message Dictionary messages may also use supportability-related numbers, the ones that appear appended to the message text in the application’s UI. However, should you have the requirement to remove these numbers from users' view, the UITE is not the tool for the job. Instead, see my blog about using the Manage Messages UI.

    Read the article

  • Visitor-pattern vs inheritance for rendering

    - by akaltar
    I have a game engine that currently uses inheritance to provide a generic interface to do rendering: class renderable { public: void render(); }; Each class calls the gl_* functions itself, this makes the code hard to optimize and hard to implement something like setting the quality of rendering: class sphere : public renderable { public: void render() { glDrawElements(...); } }; I was thinking about implementing a system where I would create a Renderer class that would render my objects: class sphere { void render( renderer* r ) { r->renderme( *this ); } }; class renderer { renderme( sphere& sphere ) { // magically get render resources here // magically render a sphere here } }; My main problem is where should I store the VBOs and where should I Create them when using this method? Should I even use this approach or stick to the current one, perhaps something else? PS: I already asked this question on SO but got no proper answers.

    Read the article

  • Inheritance of list-style-type property in Firefox (bug in Firebug?)

    - by Marcel Korpel
    Let's have a look at some comments on a page generated by Wordpress (it's not a site I maintain, I'm just wondering what's going on here). As these pages might disappear in the near future, I've put some screenshots online. Here's what I saw: Obviously, the list-item markers shouldn't be there. So I decided to look at the source using Firebug. As you can see, Firebug claims that the list-style property (containing none) is inherited from ol.commentlist. But if that's the case, why are the circle and the square visible? When checking the computed style, Firebug shows the list-style-types correctly. What's the correct behaviour? I just did a quick check in Chromium, whose Web Inspector gave a better view of reality (the list item markers were also displayed in this browser): According to WebKit, list-style of ol.commentlist isn't inherited, only the default value of list-style-type from the rendering engine. So, we may conclude that the output of both browsers is correct and that Firefox (Firebug) shows an incorrect representation of inherited styles. What does the CSS specification say? Inheritance will transfer the list-style values from OL and UL elements to LI elements. This is the recommended way to specify list style information. Not much about the inheritance of ol properties to uls. Is Firebug wrong in this respect? BTW, I managed to let the markers disappear by just changing line 312 of style.css to ol.commentlist, li.commentlist, ul.children { When also explicitly defining the list-style of ul.children to none, the markers are not painted. You can have a look at screenshots of Firebug and WebKit's Web Inspector in this case, if you like.

    Read the article

  • Why can't I call methods within a class that explicitly implements an interface?

    - by tyrone302
    Here's the story. I created and interface, IVehicle. I explicitly implemented the interface in my class, Vehicle.cs. Here is my interface: Interface IVehicle { int getWheel(); } here is my class: class Vehicle: IVehicle { public int IVehicle.getWheel() { return wheel; } public void printWheel() { Console.WriteLine(getWheel()); } } Notice that "getWheel()" is explicitly implemented. Now, when I try to call that method within my Vehicle class, I receive an error indicating that getWheel() does not exist in the current context. Can someone help me understand what I am doing wrong?

    Read the article

  • Why would a static inner interface be used in Java?

    - by Mo
    I have just found a static inner interface in our code-base. class Foo { public static interface Bar { /* snip */ } /* snip */ } I have never seen this before. The original developer is out of reach. Therefore I have to ask SO: What are the semantics behind a static interface? What would change, if I remove the static? Why would anyone do this?

    Read the article

  • Designing the iPhone interface in a nib or in code?

    - by Jacob Relkin
    I've been pondering over this question for a long time already. On the one hand, Interface Builder offers a really easy way to design the interface and wire the elements up with objects in code. On the other hand, in larger projects, Interface Builder becomes a hassle to maintain. Any suggestions would be greatly appreciated.

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 20 21 22 23 24 25 26 27 28 29 30 31  | Next Page >