@Schmidt

First of all: Thanks for taking the time to answer my post again!

I for one are not put off by your tone or take this personal because I think it is quite natural that a discussion about a topic several people have strong opionions about get's a little heated. A controverse discussion does not mean that I cannot respect other peoples views. Quite the oppisite: I really want to understand the different approaches and opinions, because I think it's a topic that deserves some real effort.

To clarify: I do have some knowledge about the component object model and TLBs and stuff, but I am by far no expert. I am able to query COM interface in source, call functions, use properties by name in code and stuff but I did not know that OCX Controls and ActiveX Dlls are from a technical standby a big difference in complexity. Thanks for putting it into some kind of perspective.

The support of ActiveX DLLs would make the proposed system a lot more interesting. I know this sounds again like a customers perspective. But I absolutly respect that this project - if it would be realized - would only be possible through hard work of a small team of very invested developers and that it would be crazy to "demand" anything from them. But I also think that it would be very good to have a broader base of support right from the start so that there are a lot of devs who - event if they cannot contribute directly - could help test the IDE, find bugs, promote the new system to other developers etc.

And like myself I am sure a lot of them need to see a viable approach for existing projects. You are kind of right when you write that the best VB6-compatible language today is VB6. But my point ist the following: I do have the fear that Microsoft may be one day stupid enough to break VB6 support and I do want to port our applications to another system before this happens. But this conversion also has to be affordable in terms of time and money. The support ActiveX-DLLs you said could be an possible without too much hassle would help a great deal: With something like this (source compatible + ability to use ActiveX-DLLs) I for one would be willing to port our software. Without OCX support this would still cost for our main application alone something around 750 hours of developer time (raw estimate of course), but at least that would be affordable (compared to around 2.500 hours). But this is just us. Other developers might have a different situation where they simply cannot afford to port without OCX support. I am sure most if not all of them would LIKE to though. I know that if Microsoft breaks support eventually I would still have to port the rest, but at least I would not need to do this all at once (which I cannot afford) but step-by-step (which I could afford).

If there was ActiveX-DLL support, that would really help out a lot of developers.
If there would be OCX support that would attract a whole lot of other developers to support the project (in some way or another)

This is why I am so interested in this aspect and persistent to "fight" for it ;-)

Regarding myself I would love to help out a project like this in any way I can - I do not think of this as a product and understand very well how much effort this thing would cost. However I do not know of how much help I could be given that I am mostly an application developer with some basic knowledge about compilers. What I AM good in would be: Helping develop a good framework library, developing and fine-tuning the IDE, helping to achieve a good user-experience, coming up with creative solutions, write widgets, help with translation, deliver graphics and contribute to language features (in my career I have developed about a dozen or so scripting languages for various plattforms and target groups).

Regarding the road map: I agree with you that the IDE and especially Debugging and Edit & Continue are essential key elements and need to be addressed right from the start. E&C in VB6 is still today one of the best regarding ease of use and performance.

Dominik