Property and Delegate

wat about the property in the code, not as in the property of an object...
for example,

Public Property Name() As String
...
End Property

wat about a delegate?
 
Propery in code is an attribute of the object, so

Car is the object and Red is it's colour property.

I haven't got into using delegates yet, I think they are a kind of telling VB the makeup of a procedure. I'm sure someone will correct me:)

Lastly I think you should buy yourself a good starter book on VB to get you into it all.
 
er.....any really good books to recommend?
i have seen some from wrox and sams publications...
could someone recommend me a specific book?
 
Well I always prefer the SAMS Teach Yourself series, but have a few others:

SAMS Teach Yourself VB .NET in 21 Days (very good)
Visual Basic .NET How To Program by DEITEL
SAMS Teach Yourself Object Oriented VB .NET in 21 Days (very good)

To name but a few :)

Oh and Professional Crystal Reports for VS .NET ( but this I feel could be a lot better)
 
Properties are very good ways of calling and setting a variables using validation.

For instance, you can have a property that takes and integer, but in code you can test if the value is greater then 0, and if its less, put it at 0.

Also, you can easily tell when a variable has changed, so you know to save the data inside (if necessary).

You can override properites to allow future code to handle the data in different ways.

You can run functions based on the setting of the properties, like setting a home made control to "FollowData", and if the value = True then move to the end of a log box, etc etc...
 
Deciding when to use a Property verseus a function isn't always clear, but it will become clear over time. A good book will help explain their syntax (which is a good start), but only practice will let you know when and how best to use them. If you have a class to define a person, you might have an Age property and a Name property. You *could* define a method called GetAge() but it's generally bad practice. What makes it bad? Nothing but the fact that "professional" programmers call it bad - it's a standard to make code more readable and easier to understand (from your coding perspective and the from the perspective of the person using your class, even if you're both).

A delegate is completely different. It's a way for you to define what a function will look like. I've used them in two ways (though more exist - depending on what you need). First, an event is a delegate. Meaning, a click event is basically a function that gets called when a click is made. The function is not known when the user created the control. So a delegate is used to say "I want to call a function that takes two parameters". The control can then raise this event (basically, just call a function) and call your code.

Normally, you have code that calls a function that you know about. You call that function by name (if the function is named Test and it takes a string, you can use Test(string1) or Test(string1);). But in the case of events, the function being called isn't known but as long as it's known at runtime, ANY function can be called (as long as it's hooked). To get hooked, it MUST follow the exact syntax specified by the delegate definition.

The other main use is to define your own function - or rather, what a function will look like. You can decide later what function to call.

Suppose you have a function that takes a string and a DataSet and saves the DataSet. Before it can do the save, it needs to run a bunch of conversions on the data in the DataSet and the types of conversions are based on what the string contains. You could do this:
C#: 
private void DoAction(string code, DataSet ds)
{
    bool result = false;
    if(code=="A")
        result =DoActionA(ds);
    else if(code=="B")
        result =DoActionB(ds);
    else if(code=="C")
        result =DoActionC(ds);

    if(result==true)
    {
        // Do something on success
    }
    else
    {
        // Do something on error
    }
}

private bool DoActionA(DataSet ds)
{
    // Do some checking specific to action A
}
private bool DoActionB(DataSet ds)
{
    // Do some checking specific to action B
}
private bool DoActionC(DataSet ds)
{
    // Do some checking specific to action C
}

The above works fine. But, if you need to have an error handler in DoAction(), you might want/need to wrap it around the big IF. Or, you could write 3 error handlers, one for each call to DoActionX.

You could also simplify it (simplify is a relative term :)) by using delegates. Take this example:
C#: 
private delegate bool DoAnAction(DataSet ds);

private void DoAction(string code, DataSet ds)
{
    // Create the delegate like any other variable
    DoAnAction action = null;
    if(code=="A")
        action = new DoAnAction(DoActionA);
    else if(code=="B")
        action = new DoAnAction(DoActionB);
    else if(code=="C")
        action = new DoAnAction(DoActionC);

    // Use the delegate as if you were calling any other function:
    try
    {
        bool result = action(ds);
    }
    catch{/* Do something */}

    if(result==true)
    {
        // Do something on success
    }
    else
    {
        // Do something on error
    }
}

private bool DoActionA(DataSet ds)
{
    // Do some checking specific to action A
}
private bool DoActionB(DataSet ds)
{
    // Do some checking specific to action B
}
private bool DoActionC(DataSet ds)
{
    // Do some checking specific to action C
}

The above shows that you can create a delegate just like any other variable. It's constructor always takes a function name. Once created, you can call the delegate like any function only it will call the function you pointed to in the constructor. You can also create multicast delegates that automatically call multiple functions in ONE call. Events work this way since you might have multiple event handlers (for instance, when you see C# code that does "control1.Click += new ...").

I'd strongly suggest looking over a book and playing around with everything you read (don't just read through 3 chapters in one sitting). Playing around and tinkering with code is the best way to get familiar with (and remember) a language.

-Nerseus
 
Back
Top