>It's possible that mbas could be extended to support VB6 syntax, but I >don't know how feasible/practical that is. It might be better to fork >mbas for VB6 support, assuming that it's practical to do that. >
The problem with VB6 is that it is built on a very old foundation, dating back to the days of QuickBasic. While MS tried to shave off many of its quirks and plain weirdness in its recent evolutions to version 6.0, the "old" VB6 remains a language which can't be easily adapted to CLI/CLR, because many assumptions about data types, conversions, declarations, etc. are no longer valid. It's not the big issues (classes, inheritance, module declarations) which are problematic, but the more subtle ones. Then there is a completely different issue: given the low learning and usage threshold of VB6 (which is a positive fact) many VB6 developers are simply unable to grasp and cope with more advanced concepts like OOP, delegates, etc. Personally I'm glad that VB has achieved the status of first-class language, instead of being considered, as it happened too often in the past, a second-choice language for sleazy programmers (not my point of view). In other words: it's not worth the effort; I have many VB6 applications which I'd like to convert to VB.NET and, possibly to mbas. But when you're done with that, you still have an old application, which can't exploit the more advanced features of the .NET/Mono architecture (OOP and assembly separation, just to name a couple). It's good to be able to transition an old app from VB6 to VB.NET with a few touches and the help of MS'Upgrade Wizard, but eventually, if you plan on upgrading and mantaining your app, you should move at least portions of it under .NET, and not rely on old programming models. All if this of course, IMHO Marco Ridoni _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
