>Hi,
> I have a class which subclass OLE MSCOMM32.ocx. I have code as following:
>
>myclass.InitMy (MSComm32)
>
>this.CommPort=2
>this.Settings="9600,N,8,1"
>this.PortOpen=.t.
>this.InputLen=1
>**do whatever**
>
>When my application go through this method, I get "Invalid port number" ERROR.... it seem to be I don't install COM2 in my machine. Therefore, I place my error handle in myclass.ERROR().
>My question is how could I exit from myclass.InitMy() if error occur? At this moment, VFP will continue with the rest of code even error occurs, therefore user will get other error cause by the previous error!!!
>

Why not create a property, and if an error occurs, set the property to a value that will let you know that something went wrong. If something went wrong, return .F. from the Init method so that the object won't instantiate.

John, before you start putting together a class, you need to define the behavior of the class - the public interface, invocable methods, and what the class shpuld handle. Design the class before you try to implement it so that you at least know when something isn't working correctly.

Throwing together code without a coherent plan for class behaviors and how they interact is about as sure a method as I can think of to make a project fail. OOP requires that you analyse the problem and only start to implement when you know what the entities are that you will be working with, how they interact with each other, and what aspect of each object is exposed to the outside world.

It's important that you understand not only what things need to be done, but what entities are responsible for them. A well-designed class hierarchy can make life much easier by creating abstract models of behavior, which can then be inherited an specialized as needed. For example, salesmen, managers, customers and accountants all perform different functions, but they're all people, and have similar attributes and behaviors common to all people. By defining a People class with the generic common things shared by all of them, you put all the maintenance and attributes for people in one place, and anything in the system can be derived from the People class.

You have two distinct categories of people - customers and employees. Customer attributes and behaviors are different than emplyee information and behaviors, so you coulkd create a class Cusatomer from People, adding the special information and behaviors for Customers to the subclass. Similarly, you would create a subclass of People called Employees, with the special detail only applicable to Employees defined there. The common handling for People is inherited by both subclasses, but new attibutes and methods are added to the subclass that are specific to employees.

Employees specialize according to what they do, so you'd the subclass employees to derive salesmen, managers and accountants.

This idea of defining levels of abstraction is what makes OOP work. If you don't plan the object hierarchy before starting to implement, you end up duplicating behaviors unnecessarily, and often don't really understand the things that a given object is really supposed to do and contain.

Again, Jim Booth's Effective Techniques for Application Development with Visual FoxPro 6.0 is a good book to get and go through thoroughly. It addrersses VFP and OOP concepts well - I've read it, and keep going back and re-reading it to make sure I understand what Steve and Jim wrote.

>Any ideas?
>Thank you