Maybe you should start making use of the Document View window. It makes working with .PRG based classes much more tolerable.

>Actually I agree with you. I can't tell you the number of times others have said to me "I wish you'd quit putting your classes in a program! I hate working on classes in prgs..." That is why I made the comment I made. When you work as part of a development team, it is not always what you prefer personally but what is most acceptable to all. Of course, another programming team may prefer prgs. I'm fortunate at this time that where I am now it doesn't really matter as long as the class is well documented. We do try to stick with a standard but that is more about what goes in a class, calling the class, subclassing, and not so much whether the class exists in a prg or a vcx. Admittedly it is convenient to view all classes used in a project on the classes tab in the project manager. It is faster to create and modify the classes in a prg though.
>
>
>>>In addition to speed in development and runtime there is also the issue of later modifications. Let's say there are two developers and one prefers to code classes in prgs and the other to code them visually. If later one of them leaves the company which method allows for the most easily done modifications in the future? I know some developers that prefer to put their classes in prgs and others that prefer to do everything visually. I think that generally a new programmer coming on board would be more successful immediately having to modify classes designed visually. That has only been my experience though. Which method most benefits the company and the customers in the longrun?
>>>
>>For me the size of the methods also is an issue: when you have lots of small functions, I am faster using prg's, since the screen space is used better and without switching screens. When the method code of single methods nearly fills your screen I find the vcx based approach more productive.
>>
>>my 0.02 EUR
>>
>>thomas