Well<g> ... just like regular SBT. However, the upside is that there is some comfort in the consistency.

I know lots of people here on the UT criticize SBT for being a bit archaic in its code, but with the customer base that they have, I can see their desire to move forward slowly (okay, glacially).

SBT code evolved over many years and is an intricate 'house of cards', where there are many links from one module to another, etc.

Also you have to realize that there's lots more legal liability in mucking up an entire customer base's accounting system (i.e. 100,000+ installs) than there is in most of the VFP work being done by developers here. While I'm sure there is still quite a bit of liability from here on a project by project basis, SBTs liability for a serious bug would be astronomical. This liability leads to a very conservative approach. And I can't fault that -- the 'well, let's try this and see what happens' approach won't work for their model. The other option is tripling their QA department and therefore the price -- something nobody wants.

They are slowly moving toward true OOP, but it's still a ways off...

SET LONGWINDED RESPONSE OFF

>When you say that it is written in exactly the same way as SBT do mean that it is written in the bizarre hard to trace speghetti code of Pro series 5 or is it more like the closer to true object oriented style of pro series 6 or is it just that the look and feel of the finished product is the same??
>
>As for TIW, I agree. I'm not impressed.
>
>Thanks for the input!