# Projects > Project Communication Area >  VB Classic (A True VB 7.0)

## Jacob Roman

*Introduction:*
Its been many years since MS dropped support for VB6, yet people continue to use it to this very day. Many users have switched over to VB.Net due to how powerful it is, and the fact that its truly object oriented. But some find the runtime too large, and their apps are too dependent on the .NET Framework. The on going battle between VB6 lovers and VB.Net nuts must come to an end. Its time we developers unite to create the ultimate VB language that's fast and easy to use. A language that is extremely RAD (Rapid Application Development). Its time for VB Classic.

*Why VB Classic?*
VB Classic if done right will be the solution to every VB developers problems. People as well as businesses continue to use VB6 for a reason. Either its too expensive and time consuming to switch to VB.Net and port all that code, or some people find VB6 easier to code for than VB.Net. Some people also find VB.Net lingering away from the BASIC syntax that we all once recognized. But people use VB.Net for a reason too. Its powerful, the latest technology, and actually object oriented. Some find VB.Net easier to code for than VB6. But what draws you in to stick with your favorite VB language regardless of version you use? What do you not like about it? If we all iron out the flaws of VB, we can create an improved VB language, and make it easy to migrate to from both sides of the fence without overwhelming you with a completely new syntax. A lot of people find both languages have very slow functions they would like to see execute faster for example. VB Classic will have very familiar commands execute as fast as humanly as possible so you will have no worries of slowdown in time sensitive projects such as games!

*Can I be a part of the Team?*
I will need a team of people to help me put this together. You can PM me or say you want in here in this thread, but you must be serious about joining. Before we even begin to jump into syntax, I would like help in putting together the IDE. Once we have an IDE to work with, then we can discuss syntax. The reason is because if we talk about syntax, we can go on and on until theres about 20 pages of a super thread going, but.... no IDE was made. I don't want to make the same mistake that happened with LightFusion, and its a must that progress must be made. The IDE will be designed in C++ starting with the basic window, the menu items, and the code window within the window. As we progress, then we can add special things such as a toolbox and such. The IDE is a must before a syntax can be formed. 

IMO I think eyeRmonkey did a better job in creating an intro for developing a new programming language  :Roll Eyes (Sarcastic): 
http://www.vbforums.com/showthread.p...ht=lightfusion

----------


## Schmidt

I like your approach, to come up with an IDE first (before tackling the compiler itself) because that's my opinion as well -
though I think I reached that point due to different reasons than the one you listed above (avoiding lengthy discussions).

My reasons, that a compiler needs to come last are:

- it's not the most complex part in the project (*if* the language and especially the *environment* shall be a "visual one")
- RADishness comes mostly from libraries (and a good, accompanying "visual IDE" is only the candy on top of a good GUI-framework) 
- community-projects who followed the other approach (compiler first, then "everything else") mostly remain with the compiler and don't achieve a tight integration with a "RADish, visual IDE" anymore
(-> because there never was an: "agreed upon, officially and tightly integrated GUI-framework to saddle on from the very beginning"...
(-> just see the already well-working Basic-compilers www.FreeBasic.net and www.OxygenBasic.org as an example, which are both badly in need of a "unified GUI-framework, ideally written in the language itself")

Flying over the thread you linked to, I discovered the contributions of CornedBee and I couldn't agree more - e.g. he wrote:



> Oh, once again we're at the language/library boundary. Making a language platform-independent is easy. The only problem is that you need more than compiler - but if you, for example, write the compiler as a GCC front-end, you get that for free.
> 
> The libraries, however, need to interface with the OS to do anything meaningful, so yes, there platform-independence would be a lot of work.
> On the other hand, it's not necessarily you who must do the work. If you simply design the libraries so that they don't clearly favour one OS, you can then implement them for the OS you're using and leave the porting to other people.
> 
> Take a look at C#, for example. Porting C# itself was simple and done in the Mono project within a few weeks, I think. Writing the CLR wasn't too hard either. The real issue is porting the .Net framework, especially the System.Windows.Forms namespace, which is extremely clearly modeled after the Win32 model, thus making implementation on top of X Windows all but impossible - the Mono project uses the WINE WinAPI implementation for this namespace.


So, I'm interested - because "writing an IDE" was also on my own personal agenda next (on my way to a new VB6-compatible compiler) - though I reached this point after doing
"a whole lot of additional groundwork over the last years" - in analogy to the statements of CornedBee above, I focused on a "rich, accompanying framework" first (www.vbRichClient.com).

Meaning, I've now brought the necessary and modern class-framework (a class-based runtime) for the new language into shape, which not only
- covers a modern vector-based GUI-approach (already platformindependent, due to a cairo-binding)
- but also all kind of List-classes are integrated (ArrayList, Collection, SortingDictionaries)
- Filesystem- and Stream-support is encapsulated behind classes too
- XML, StringBuilder, as well as all kind of other "StringCodecs" (Base64, Hashing, Compression, Crypto-Algos etc.) are contained
- basic Networking-classes (cTCPServer, cTCPClient, cUDP) are integrated
- higher-level Networking too (cRPC-Classes as a DCOM-replacement, cWebServer for InProcess http-Serving)
- and ADO-like Classes (cConnection, cCommand, cRecordset) are there as well, wrapping SQLite as a well-working alternative to ADO/JET

So that's what would be available (and IMO necessary to consider and integrate early on) for the new language, IDE and compiler... each and every Class above is implemented in VB6 - 
and thus would become immediately "recompilable in the new language" as soon as the new compiler reaches its selfhosting-state and is basically compatible to VB6.

I don't understand, why you would want to develop the new IDE in C++.
- if the new compiler will be nearly compatible to VB6 in the end - then why on earth not develop in the VB6-IDE?
(-> any code we write in VB6 - especially when we restrict ourselves to use only *.cls and *.bas modules, should become recompilable with the new language and thus selfhosting).

- second point: *any* GUI-development for the new IDE should go through a class-abstraction-layer for the GUI, to be able to port the new IDE later on also to other OS-platforms much easier.

So yeah - I'd join the efforts, when we would base the whole IDE- and Runtime/Compiler-idea on the already existing (VB6-based) class-abstraction-layer which comes with the RichClient-framework.

Such a "rich runtime-environment" is necessary for a modern RAD-language - not thinking about it beforehand will doom any attempts in
"writing a True Visual Environment, which integrates also a UserControl- or Widget-concept tightly".


Olaf

----------


## Jacob Roman

Thankfully someone stepped up to the plate.  :big yellow: 

I am doing the IDE in C++ because of a couple reasons: 

1) I want the IDE to not be dependent on the .NET Framework or the VB6 runtime library. I understand that the compiler can be in C++ and the IDE can be some other language while we work with the files in between such as the .bas, .cls, and .frm files which will contain the source code. Word has it that Microsoft will supposedly be dropping support for the .NET Framework in the near future (keyword supposedly, nothing is official) and target Windows RT based apps which are compatible with tablets, smartphones as well as PCs and laptops. If I was to design the IDE in lets say VB.Net, then what if my IDE no longer works in future OS's? Same holds true for C#. And VB6 programs are already getting harder and harder to run for every new OS due to the minor tweaks you must do such as registering obsolete dlls your program is dependent on.

2) C++ is extremely powerful and very very fast in execution. You have so much more control in everything you do. Yes its harder to code in, but the payoff in the end is what matters the most. You also can code low level inline assembly to speed up routines where they are needed. You have full control when you do multithreading. There are so many reasons why. 

I do have a possible good idea though. We could design the IDE with VB.Net first and build upon that until we have a basic foundation. And once its finally complete (the IDE) we can convert it to C++. It may seem double the work, but well have something to work off of. Sort of a blue print rather than play by ear. The compiler and linker is gonna be a separate program anyways (obviously written in C++).

----------


## Schmidt

> 1) I want the IDE to not be dependent on the .NET Framework or the VB6 runtime library.


That will be automatically the case, as soon as the *new* compiler is finished (and not emitting MSIL, but C-code instead) - and we recompile everything with it.

To be able to write a true selfhosting environment (which I would prefer - please google for the term if not yet entirely clear), 
we would need to program in the same language we write the new compiler for.
Sounds ambiguous a bit, but in our special case (since we don't want to design an "entirely new thing", but only a mostly compatible one) -
that becomes easy, since we can write "good old VB6-code" in the well-known and RADish "VB6-IDE as Initiator-platform".

Sure, you could write the new IDE in C++ (and the compiler too) - but this is not necessary at all.
VB6 offers more than enough to cover everything what's needed (for the new IDE as well as for a new C-emitting compiler) - and as said, 
the code-base we would generate (the IDE-sources as well as the Sources for the C-emitter) would remain in the realm of the target-language
(VB6-compatible) - and thus much better maintainable by VB-coders.

I would like to say (when everything is done in some years):
- Our new IDE is written in VB7 itself
- Our new (tightly integrated into the new IDE) VB7-compiler is written in VB7 itself
- Our new class-based Runtime/Minframework is written in VB7 itself

I mean, you propose in your opener-posting, that "the new language will be fast and does everything you always wanted from a VB7".
So why eaxctly do you prefer, to write the IDE and Compiler in C++, if the new target-language is "as fast and powerful as C++" (which is perfectly doable with a C-Emitter BTW).




> I understand that the compiler can be in C++ and the IDE can be some other language while we work with the files in between such as the .bas, .cls, and .frm files which will contain the source code.


As said, the compiler can be written in VB6 easily too - that's not rocket-science - only string-concats, If-condtitions and loops... ;-)
And as for *.frm files - those wouldn't be needed with my proposed approach (when we use the VB6-based class-framework for the GUI).




> 2) C++ is extremely powerful and very very fast in execution.


Believe me, for that task (IDE and new Compiler) the VC6++ compiler (C2.exe) which comes with VB6 offers more than enough performance.




> I do have a possible good idea though. We could design the IDE with VB.Net first and build upon that until we have a basic foundation. And once its finally complete (the IDE) we can convert it to C++.


Nope - that would not be the way to go for me.
VB.NET is not necessary at all (VB6 is more than enough) - and especially the final porting to C++ is entirely absurd for me - 
as already explained above - it is desirable to have the IDE, the compiler (the whole environment) available in the final target-language.
And if this target-language is a VB7 - and this new VB7 shall be "as compatible as it gets" to VB6 - then by all means, let's write the
first version of the IDE and the new compiler in VB6.




> It may seem double the work, but well have something to work off of.


That would be "triple work" from my point of view, since the ideal code-base "to have", would be neither VB.NET, nor C++  but the new language VB7 itself.




> The compiler and linker is gonna be a separate program anyways (obviously written in C++).


Not necessarily - the compilation and linking-step can also be performed by a Dll (in case of a C-emitter this could be libTCC.dll for example).
And as said, the C-emitter (as the Compiler-frontend for GCC/MingW or TCC) can and should be written in the new language.

Olaf

----------


## Kbre

I would love to participate in this project! 

I am already aware of the work done by Olaf in the vbRichClient Framework (I am using it in my projects with excellent results!) and I am already contributing to Olaf's vbWidgets project. I really recommend you to read the About section of the vbRichClient site, the whole story is summarized there. I think it's the way to go...

Kbre

----------


## Jacob Roman

Yes I'm aware of C2.exe but I don't think its possible for us to create our own low level assembler commands through it. For example. Lets say I want VB Classic to have a super fast Square Root thats a lot faster than the current square root function:



```
    float inline __declspec (naked) __fastcall sqrt2(float n)
    {
        _asm
        {
            fld dword ptr [esp+4]
            fsqrt
            ret 4
        }
    }
```

This alone is even faster than C++'s sqrt() function from the math.h library! Practically the fastest square root in existance Although its the float version, the double version is in this link and you can compare the different ones here: http://www.codeproject.com/Articles/...nction-Precisi

If C2.exe would accept this, I will go along with it. Because I want VB Classic to be very fast and efficient.

----------


## Kbre

I think that further in the future of this project, we could certainly add inline asm to our VB-written VB compiler. I don't see the need of super fast speed to develop the (initial) IDE. We simply need one place to start from until we get the thing seft-working, and after that we could do anything!

In the meantime, possibly you could use something like this.

----------


## Schmidt

> Yes I'm aware of C2.exe but I don't think its possible for us to create our own low level assembler commands through it. For example. Lets say I want VB Classic to have a super fast Square Root thats a lot faster than the current square root function...


Maybe to make things more obvious - let's introduce a new name-definition for the working compiler-binary we would end up with (currently it's not really clear what is meant with 'VB Classic' or VB7 when we use the terms).

Say, the new compiler which is producing the "new, small and fast" VB6-compatible-binaries is called cb7.exe.
Just to introduce a term, we can associate with "an action" (a compiler-run which produces a binary).

Now you have for example some code-input in "mySuperFastSqrtDemo.bas" and you call on the commandline:

> cb7.exe   mySuperFastSqrtDemo.bas   -o mySuperFastSqrtDemo.exe

The produced mySuperFastSqrtDemo.exe is now *not* dependent on msvbvm60.dll anymore (no matter if the cb7.exe-binary itself is still compiled with VB6) because:

- cb7.exe has parsed the contents of the passed file "mySuperFastSqrtDemo.bas" into Tokens and build a tree-like structure internally
- the treelike Token-Structure can be parsed lexically (already in the tokenizing-run, but also in additional runs), to be refined and in parts restructured (throwing out syntax- and compile-errors, if there are any)
- if after the Lexer-run we have a validated Tree-Structure, we traverse the tree and start firing out matching C-Code-snippets, according to the Tree-elements - all accumulated in a StringBuilder-Object (or a similar structure)
- now cb7.exe can start putting temporary files out (one per parsed and tokenized src-module) as e.g.: mySuperFastSqrtDemo.c
- then cb7.exe fires a C-compiler up under the hood (could be GCC or TCC) - to produce the final binary from the temporary c-Files (incorporating a few "environmental and runtime things" from cb7_runtime.h and cb7_runtime.c and a few static libs).

In all of the above actions which *cb7.exe* performs I see no heavy usage of "squareroot-functions, which need to be superfast".

cb7.exe could be programmed in VBScript for the tasks it performs (Ok, when the total amount of Lines-Of-Code in a larger project goes above 100000, we would need a fast parsing - but you get my point). 

So it doesn't really matter, if cb7.exe itself is based on VB6 still  - or was already compiled "with itself" (so that cb7.exe will not depend on msvbvm60.dll anymore).

When you talk about**: "I want the best performing Square-Root-function there is" - then you want to place a runtime-function-inline-snippet for that in  cb7_runtime.h or  cb7_runtime.c ( in case we are not satisfied with what math.h has to offer)

That's where it counts - and where the final C-compiler-run can find and apply it (because you want it in the end-result: mySuperFastSqrtDemo.exe and not in cb7.exe).

So in all the following postings I'd like when you keep the above in mind - and not intermingle the "binaries we want to produce with the new compiler" - and "the compiler-binary itself" anymore.

I was arguing to use VB6 as the initiator-platform to produce the first version of cb7.exe.
With the goal, to be finally able (after refining cb7.exe more and more), to do at the commandline:

> cb7.exe  cb7.vbp  -o cb7_selfhosted.exe

And until we are able to do (and celebrate!) the above compiler-run, I'd like to encapsulate within cb7.exe also a well-working IDE, with an Editor and Form-Designer in analogy to VB6.exe.

I hope you see the similarities:
VB6.exe is hosting both - an IDE as well as the (higher-level) commandline-interface (which under the hood in native mode fires up a C-compiler -> C2.exe)
cb7.exe will too host both - an IDE as well as the (higher-level) commandline-interface (which under the hood in native mode fires up a C-compiler -> gcc.exe or tcc.exe)

And as long as cb7.exe is not yet capable to "produce itself" (because our tokenizer is still lacking - or the C-Code-Emitter has still bugs) we will have to resort with our sources to do:
> VB6.exe  cb7.vbp  -o cb7.exe

I hope this clears things up a bit more on your end.

We don't need C++ to write a fast parser, a fast tokenizer/lexer/emitter.
We don't need C++ to write a nice IDE and a nice Form-Designer.
We can bundle and code everything, what ends up within cb7.exe with VB6.exe and whilst doing so...
we can save us a whole lot of additional work, and make our new visual-environment more platform-independent, when we avoid using platform-APIs (the WinAPI) whereever possible
and therefore work through a modern and timesaving VB6-based Class-Framework which offers a platform-independent GUI-approach for "all the visuals" and is later on recompilable with cb7.exe too (selfhosting-wise).


Olaf

----------


## jpbro

Count me in on this project as well if you need more contributors. I don't know if I could help too much with the compiler (might be too advanced for me to really contribute), but IDE programming, UI, and "regular" application logic are within my skillset. I can also do documentation.  When do we start?  :Wink:

----------


## jpbro

I'm also curious about what you think about extending the language. Obviously we want to be able to compile standard VB6 code, but what about new language constructs (say, try..catch blocks for example)?

----------


## SuperDre

> any code we write in VB6 - especially when we restrict ourselves to use only *.cls and *.bas modules, should become recompilable with the new language and thus selfhosting


Why restrict to only *.cls and *.bas, VB6 is more than those alone.. *.frm (and the usercontrol ones) are just as important.. I know *.cls and *.bas are the easiest to do, but one of the reasons people tend to stick with their vb6 instead of opting to go for vb.net is due to the investment in created forms and usercontrols (which normally don't port so well to .NET).. A lot of people have just stuck to using the stock components and commoncontrols, so making sure those are at least available in the visual basic classic is almost a must (for people to want to use this 'community' driven language, instead of MS's visual studio .net). Also a lot of projects are using WINAPI for doing a lot of stuff so it also must be able to 'mimic' those..

Just creating a new version of VB without supporting the already available 'commonly used' options for vb6 isn't a smart thing, as it still will keep a lot of developers of this new version as it will cost almost just as much time to port it to the new version as it is to porting it to VB.NET or C# (VS2013 even has a paste VB.NET code to C# code and vicaversa).





> So yeah - I'd join the efforts, when we would base the whole IDE- and Runtime/Compiler-idea on the already existing (VB6-based) class-abstraction-layer which comes with the RichClient-framework.
> Such a "rich runtime-environment" is necessary for a modern RAD-language - not thinking about it beforehand will doom any attempts in
> "writing a True Visual Environment, which integrates also a UserControl- or Widget-concept tightly".


Don't take this as an attack on your work as I only glanced over your site and I'm in the process of reinstalling vb6 on my home computer just to check it all out, but just speaking as the devil's advocate:
But you state yourself you're only interested in it if it's already using your RichClient-framework, whereas I think it should be (almost, at least like vb5=>vb6) 100% compatible so one can at least start with a large project they already have and port it to this RichClient-framework at their own pace after they're already using the new advantages of the new version.. Otherwise people could just as well use RealBasic/studio which as I heard also has all the advantages of modern OSses..




> I'm also curious about what you think about extending the language. Obviously we want to be able to compile standard VB6 code, but what about new language constructs (say, try..catch blocks for example)?


that ofcourse is also a must, being able to keep the old style of doing stuff, but also being able to do stuff in a more modern way.. Also stuff like shortcircuit IF's is something that would be high on my list, NOT by using stuff like 'AndAlso' or 'OrElse', but just letting the original 'And' and 'Or' do the same shortcircuit (by means of stuff like 'Option ShortCircuit' or something like that (we already have 'Option explicit' and some other).. Also support for unsigned integers is a must IMHO.. And Inheritance/function overloading/etc.. real multitasking etc.. All on top of the original VB6 language.. hehe..

But why even create your own IDE? there are already excellent (free) IDE's out there for use with any language, like Eclipse.. Creating your own IDE is great ofcourse, but you still have the big problems of Debug-and-Run of your code, that's the hardest part to creating the IDE, and it's one of the BIGGEST reason why a lot of people used VB. Having an IDE for only Intellisense/writing/refactoring/whatever code and being able to compile it, isn't an interesting IDE, it took MS a long time to get VS.NET up to the same level of userfriendlyness as the VB6 IDE (VC++ developers were jealouse at the vb6 IDE back then)..

Being able to use the current vb6 IDE and recompile to a new target would be a great thing already, there are already some examples of using that (vbthunder is a good one)..

Yes, I would want a real new VB7, but if it means having to invest just as much time as I have to when I go to another language, then it just isn't worth the time/effort profesionally speaking..
Don't get me wrong, IMHO there still isn't a language syntaxwise that I like better than vb6 (just needs a few extra's). But then again, I have my own views on what a language should be, and it does not seem to fit with the ideas a lot of other people..

I was also thinking about doing a real vb6 clone, so I'm definitly gonna keep my eye open for this project, and I'll certainly will speak my mind  :Wink:   So please don't take it as an assault on your work, it's just my opinion..

----------


## techgnome

> NOT by using stuff like 'AndAlso' or 'OrElse', but just letting the original 'And' and 'Or' do the same shortcircuit (by means of stuff like 'Option ShortCircuit' or something like that (we already have 'Option explicit' and some other)


Oddly... there's a reason why AndAlso and OrElse were added rather than shortcircuiting the original And and Or ... there is a great deal of code out there that (believe it or not) RELIES on that lack of shortcircuiting to work properly (bleh) ... personally I think thats bad architecting... but since you brought up the point of old code still needing to work the way it has, short circuiting And and Or wouldn't work... even with an appropriate Option... the Option wouldn't be fine enough... I might it in one spot in my code and not in another of the same code file.

I'm just saying. 

-tg

----------


## Schmidt

> Why restrict to only *.cls and *.bas, VB6 is more than those alone..


To bring up a very clearly defined and somewhat easier to reach *first goal* which the new IDE/compiler-environment should accomplish only.

I'd very much like when everybody could delay "dreaming about new features" (and also their implementations, if they are not "cheap" as e.g. unsigned integer-types and other, easier stuff which could go in already in a first throw)
until this clearly defined first goal is reached.
Jacob is absolutely right with his attempt to "put the whole thing to the test, just by starting somewhere"...
I was trying (in what could be seen as a hijacking-attempt) to give the whole thing a reasonable "frame".

*
0. Start an IDE-Project in VB6, which consists only of *.bas and *.cls modules and relies on a new, modern (already VB6-based) GUI-framework which is easily portable to Linux and other OS later on.
(I numbered it as Step 0, because that would be the condition under which I would be willing to tackle that - everything else just does not make any sense, because there's already alternatives)

1. Make *.bas and *.cls modules compile with this new IDE in a way as compatible to old VB6 as possible!
Nothing more - but also nothing less ... recompile everything with the new compiler (selfhosting-state is reached).

2. Discuss everything else after step 1 is finished ... (*.fm and *.ctl  Import-Tools, enhanced ErrorHandling- and Stack-Reporting-functionality, Inheritance, ... )
*

So, point 1 alone is challenging enough as a first step - but if it is reached, we could already compile the whole new GUI-framework,
the whole new IDE (relying on that framework) and the new Compiler itself with what we produced so far (compiler-wise).

The decoupling from the VB6-mothership would be reached.




> *.frm (and the usercontrol ones) are just as important..


For those who see value in that and want to write VB6-compatible Widget-Control-Classes for at least the intrinsic (vbRuntime-contained) Base-Controls - 
this task should not be *that* difficult - this could be accompanied by Form-Designer-enhancements which understand (can parse and import) the older *.frm format.




> I know *.cls and *.bas are the easiest to do, but one of the reasons people tend to stick with their vb6 instead of opting to go for vb.net is due to the investment in created forms and usercontrols (which normally don't port so well to .NET).. A lot of people have just stuck to using the stock components and commoncontrols, so making sure those are at least available in the visual basic classic is almost a must (for people to want to use this 'community' driven language, instead of MS's visual studio .net). Also a lot of projects are using WINAPI for doing a lot of stuff so it also must be able to 'mimic' those..


If we support *.bas and *.cls in a VB6-compatible way, then we offer already more than VB.NET, since a whole lot of VB6-code-investments would run without change ... 
Also (automatically) a given (with VB6-compatible *.bas and *.cls support) would be full Win32-API- or more generally spoken "Dynamic-Link-Library-Calling-support per Declare-Statement".
(here one of the "cheap things, which could be newly introduced already in the first throw of the compiler" would be e.g. support for the  __cdecl-calling-convention).

As for "CommonControls-support" - this is a platform-dependent API, available per Win32-Dll-calls - and thus entirely possible to use, since "Dll-calls are supported".
However, my vision of a new VB7 is "as much independence from MS or any other vendor as possible" - and I'd like to ask, what's wrong with "community-driven" languages or developer-platforms?
Only those can avoid "further surprises with suddenly deprecated things" - or "new unwanted stuff, though forced down anybodys throat anyways".




> Just creating a new version of VB without supporting the already available 'commonly used' options for vb6 isn't a smart thing, as it still will keep a lot of developers of this new version as it will cost almost just as much time to port it to the new version as it is to porting it to VB.NET or C# (VS2013 even has a paste VB.NET code to C# code and vicaversa).


I don't see much value in a roughly VB6-compatible new platform, when it is "Windows-only".
I want to be able to move with a "VB6 compatible new IDE-and-compiler" to other platforms, should "Steve" decide, that Win10 will come with "Nose-Touch-only" (or some such thing).

And in case we would base our new IDE and the whole GUI-concept of the new VB7-runtime on GDI/GDI+ and MS-CommonControls, then this platform-move would be extremely difficult (nearly impossible).

So, what would you suggest instead of my (later on also opened and community-maintained) GUI-framework (which is already based on only VB6 *.cls and *.bas modules)?

RealBasic is already platform-independent, True - but not community-driven - (and a bit bloated - we can do better in my opinion).




> Don't take this as an attack on your work as I only glanced over your site and I'm in the process of reinstalling vb6 on my home computer just to check it all out,


Please do so - I can assure you, that the Framework is as powerful as GTK but (as said) already based on VB6 - and with a third of the binary-size of GTK.




> but just speaking as the devil's advocate: But you state yourself you're only interested in it if it's already using your RichClient-framework, whereas I think it should be (almost, at least like vb5=>vb6) 100% compatible


As said - "True 100% compatible" it could be made in a second step - in the first step I'd be happy with a 99%-compatibility with regards to *.bas and *.cls.
This simpler task will be something like a "touchstone" - and if we cannot even accomplish that as a community (gathering enough experienced Developers who really invest time and *implement that*),
then everything else is just "cheap talk".




> But why even create your own IDE?


Because I'm convinced that we can achieve a very *tightly* integrated IDE, which interacts in the same nice and raddish way with the compiler *and* the visual editor, as the old VB6-IDE does - 
only by implementing the whole thing ourselves.




> there are already excellent (free) IDE's out there for use with any language, like Eclipse..


If you think, that it would be easier to write appropriate plugins for a (Java-driven and huge) IDE,
which then achieves the same tight integration as the current (old) VB6-IDE, then you're mistaken (IMO).

I'm absolutely convinced, that we can accomplish the same task in VB6! (not in Java) much easier (and in a final deployment-volume of under 5MB).




> Creating your own IDE is great ofcourse, but you still have the big problems of Debug-and-Run of your code, that's the hardest part to creating the IDE, and it's one of the BIGGEST reason why a lot of people used VB. Having an IDE for only Intellisense/writing/refactoring/whatever code and being able to compile it, isn't an interesting IDE, it took MS a long time to get VS.NET up to the same level of userfriendlyness as the VB6 IDE (VC++ developers were jealouse at the vb6 IDE back then)..


I have a very clear notion (and done appropriate tests already) for Edit&Continue (based on Co-Routines and the tinycc-library, which will offer something like the current InIDE-PCode-Compiler, though C-based).
But before we go into detail with regards to stuff like *that* I'd like to see, if the whole thing lifts off at all.




> Being able to use the current vb6 IDE and recompile to a new target would be a great thing already, there are already some examples of using that (vbthunder is a good one)..


I'm not aware, that vbthunder ever accomplished a "recompilation to a new target" - in my opinion it was always the VB6-compiler (finally producing a x86-PE-binary only).
Care to explain what you meant?




> Yes, I would want a real new VB7, but if it means having to invest just as much time as I have to when I go to another language, then it just isn't worth the time/effort profesionally speaking..


If that is a somewhat blurred "but why not just use VB.NET and be done with it" statement - I think this cake is already eaten.
Those who want to (or have to) use .NET,  have switched already.




> I was also thinking about doing a real vb6 clone, so I'm definitly gonna keep my eye open for this project, and I'll certainly will speak my mind


Not much to speak or "criticise" then, since all I would like to do at the moment is absolutely compatible with your wish to achieve "a real clone":
Come as near to 100% VB6-compatibility as possible (and to ease things a bit, let's start with *.bas and *.cls only in a first step - then let's talk further).


Olaf

----------


## sten2005

Hi Olaf,

I don't read SuperDre's comment




> Posted by SuperDre
> Yes, I would want a real new VB7, but if it means having to invest just as much time as I have to when I go to another language, then it just isn't worth the time/effort profesionally speaking..


as




> If that is a somewhat blurred "but why not just use VB.NET and be done with it" statement


It is more of a plea not to make the same mistake that Microsoft did with VB.Net (and the same mistake that RealBasic/Xojo, Basic for QT and the rest make). If you can't take a VB6 application and compile it it the new language without any significant coding changes (a migration tool or wizard would be acceptable) then it simply isn't going to attract VB6 developers.

*If you can't attract VB6 developers then this project will fail.*

Microsoft couldn't attract VB6 programmers to VB.Net despite 10 years of trying. Any language (no matter how much "better" than VB6 you tell us it is) needs to be upward compatible with VB6.

That doesn't mean it needs to be able to compile for other platforms without change (developers accept that changes will be needed for different platforms) but it must be able to compile for Windows 32 bit as a minimum requirement. And it must be able to support ActiveXs/OCXs on Windows 32 bit.

I agree with your plan of writing the IDE in VB6 then recompiling in VB7 as soon as possible (points 0 and 1 on your list). But point 2 should be a 100% upward compatible Windows 32 bit version.

I, for one, wouldn't be interested in a product that offered me the ability to upgrade my VB6 programs with 'just a few months development work to get them running' - VB.Net has already made me that offer and I turned them down.





.

----------


## Schmidt

> [SuperDre's comment and my reply]
> 
> It is more of a plea not to make the same mistake that Microsoft did with VB.Net (and the same mistake that RealBasic/Xojo, Basic for QT and the rest make). If you can't take a VB6 application and compile it it the new language without any significant coding changes (a migration tool or wizard would be acceptable) then it simply isn't going to attract VB6 developers.


Maybe I misread his statement (interpreting too much into it - sorry if that was the case) - 
but I wanted to make entirely clear, that I see this project as an entirely non-commercial community-effort - 
with open sources throughout - most of the open sources based on "upwards-compatible" VB6-code - 
later on "impossible to take that away" from the developers who engage themselves in this project  
(or will just use it as "consumers" and base their own code-investments on the compiler and new IDE).

So what we have here (or should attempt here) is more comparable to FreeBasic/FreePascal-Lazarus  than to VB.NET or RealBasic.




> *If you can't attract VB6 developers then this project will fail.*


I'm not that sure about that, because the larger part of the project is already completed and was done without any help - 
if there's no people who will start working on "the rest of it", then I will drive it further on my own again.




> Microsoft couldn't attract VB6 programmers to VB.Net despite 10 years of trying. Any language (no matter how much "better" than VB6 you tell us it is) needs to be upward compatible with VB6.


The reasons why MS couldn't attract *me* to .NET was less the obvious compatibility-issues than the loss of trust in the vendor.
For example I found Silverlight (with its "reduced runtime-concept") very appealing technologically - but forbade myself to use it  - because of the just mentioned "trust-issue" - 
and good thing that I did so, since it is just another deprecated thing now - code-investment and learning-efforts would have been "blown away just like that" for a second time...

That said, please let's not drag this thread into a .NET debate ...

As mentioned above, it will certainly help, when the new language is as compatible as possible to VB6 - 
and this will be automatically the case, when *.bas and *.cls will compile without larger changes.

The rest you're talking about is "calling-compatible libraries" - and in this regard at least the basic runtime-functions (String-functions,
math-functions, format- and convert-functions, etc.) will and have to be certainly compatible, to achieve the goal of *.cls and *.bas compatibility ...

But then there's the whole topic of especially GUI-Components - and here I would like to use the
occasion and provide and "upgrade" the "new VB" with a modern GUI-framework (which, as said, - is already finished and completely wrapped behind VB6-Code and -Classes).

Now it would depend on the community - how compatible to the "existing and often used" GUI-components
these new Widgets (as I call them) will be implemented.
This project (vbWidgets) is already "started and in progress" on GitHub 





> That doesn't mean it needs to be able to compile for other platforms without change (developers accept that changes will be needed for different platforms) but it must be able to compile for Windows 32 bit as a minimum requirement. And it must be able to support ActiveXs/OCXs on Windows 32 bit.


I'd like when we would end up with a lot of (roughly) compatible GUI-Widgets which don't require CommonControls.ocx or FlexGrid.ocx anymore.
The new Widgets will be portable to other platforms - we can take the new (Widget-based) IDE and make it work without larger problems on other platforms -
and we can take "entirely Widget-based Apps" and those will run on other platforms (when the classbased runtime is ported) too.

Sure - COM-support will be interesting for the Win-platform - and I'd like to support it not only for Win32 but also for Win64 (since compilation of true 64Bit-
binaries is not really difficult, when we work over a C-Emitter).





> I agree with your plan of writing the IDE in VB6 then recompiling in VB7 as soon as possible (points 0 and 1 on your list). But point 2 should be a 100% upward compatible Windows 32 bit version.


No problem - after all we start this whole project already on Win32 and not on Linux - so Windows will be the "first covered platform" in either case - 
but let's talk about details of point 2 after point 1 is finished.

I for my part would not want a new VB7 which doesn't offer a new and modern GUI-concept (vector-based, antialiased Drawing, zoomable Controls) - 
those who want to use OCXes further (on Win32 only) could use VB6 further without problems.




> I, for one, wouldn't be interested in a product that offered me the ability to upgrade my VB6 programs with 'just a few months development work to get them running' - VB.Net has already made me that offer and I turned them down.


The "driving force" behind my efforts is, to decouple from MS and 3rd-party dependencies as much as possible - 
to avoid anything like the "VB6-code-investments-disaster" in future projects.

I take a "very long-term view" here - and want to achieve a really modern VB7, which is as backward-compatible as it gets - 
starting with full *.bas and *.cls compatibility - but already in this step using the new GUI-concept (which only requires *.bas and *.cls-support).

And if "along the way" there's enough Developers who write 100% compatible Widgets for a lot of the "bread and butter-VB6-Controls" which are used
and referenced in existing *.frm and *.ctl Files - then it shouldn't be that difficult, to parse those infos out of those File-Types and map the
properties to the existing Widget-companions more or less 1:1.

Existing VB6-projects will work as "existing and compiled VB6-projects" further (using the old compiler and IDE), as long as MS supports COM and the Win32-API.

But in a new VB7 - I for my part would love to be able to apply my gathered VB6-skills further in *new* projects, which are behaving exactly 
as the old VB6-project - deterministic freeing of refcounted Class-instances - a Long being a signed 32Bit and an Integer 16Bit wide, etc. - 
API-Declares defined exactly as they were - absolute compatible BSTR- and Variant-Types... and so on.

And I would like to compile those new projects to 64Bit - would like to run them also on different platforms - and would like
to produce a modern an nice looking GUI with only a few lines of code, using the new capabilities of the cairo-based framework 
all bundled in a new, modern IDE.


Olaf

----------


## sten2005

When I said "If you can't attract VB6 developers then this project will fail." I didn't mean you wouldn't get people to help develop a "VB7".
I meant that when you have a finished and working VB7, you won't get VB6 developers to use it if it isn't truly upward compatible. 
That means taking an existing VB6 application and re-compiling it under "VB7" with little or no (manually coded) changes. 

I'm all for replacing Microsoft's common controls, but you can't replace every ActiveX that is still in use. In each and every VB6 application there may be specialist third party ActiveXs that it is not practical to replace, there may be widely used ActiveXs that no one has written a replacement for. And you need to support ADO and DAO too.

Your "market" is those (tens of thousands ?) of VB6 users who want an updated language but require the update to be painless. Those developers have legacy VB6 applications to support and extend.
If a VB6 developer can't compile the application they will (as you say) stick with VB6 on Win32. Most simply don't have the time or resources to do otherwise. What would be the point of a VB7 used by only a handful of developers whilst most VB6 developers stay with VB6 ?
You need to offer a step-by-step approach, first show that all existing VB6 applications will work on VB7/Win32. Then add extra features. Then let us move forward to other platforms.
  "VB7" needs to (on 32 bit Windows) be able to use existing VB6 code as it is now (and if the 64 bit version could run 32 bit ActiveXs that would be even better). 

I note what you said about "loss of trust" in Microsoft. For the same reason I haven't used SilverLight or any other Microsoft developer tools since they dropped VB6.  But the main reason I and many others didn't move to VB.Net was the lack of upward compatibility.
If Microsoft launched their own VB7 tomorrow I would buy it.


I haven't looked at your https://github.com/vbRichClient/vbWidgets but I will do.

I have tried the http://www.vbforums.com/showthread.p...mmon-controls)
and been very impressed.

----------


## jpbro

I agree with Olaf's assessment of the steps to take to move forward. Based on Olaf's talents and vision for the project, I also propose that he should be the project "leader", insofar as we need someone to keep the project on task, and to have a final say in terms of controversial decisions and what gets committed to the main branch. Or are we looking to employ a more democratic approach?

That said, I still have more questions at this point.

Is the plan then to get started with a Git repository for the new VB6 programmed IDE project? 

What methodology should we have for accepting code modifications to the main branch? Should any particular developer interested in contributing create their own branch for making their own changes, which can then be merged into the main branch if accepted? 

Do we need some kind of coding standards document? We need to agree on naming conventions, how many space characters a tab should represent, etc...?

What is the vision for the look of the IDE? Are we trying to replicate the old VB6 IDE, or create something new?

Is the plan to use vbWidgets for the UI? If so do we need more widgets developed first before we have everything we would need to create an IDE?

----------


## Schmidt

> When I said "If you can't attract VB6 developers then this project will fail." I didn't mean you wouldn't get people to help develop a "VB7".
> I meant that when you have a finished and working VB7, you won't get VB6 developers to use it if it isn't truly upward compatible.


I don't see it as extreme as you - please -  just ask yourself: when there'd exist a "VB7" today, which is nearly 100% VB6-compatible in *.bas and *.cls .- 
completely "free and opensourced" - and totally easy to install and use (smaller 5MB download) - comes with a modern IDE/compiler which can create 32 and 64Bit Binaries 
and offers a new GUI-concept + a nice overhauled (but still small) Class-Runtime as well as a principle which promises true platform-independence - 
how many VB6-devs (even those who didn't help creating it) would not start experimenting with it? 

And if it indeed "delivers" (without crashes or otherwise "funny behaviour") how many would keep using it?
Enough to establish a small (but growing) community I think (as e.g. Python which becomes more and more
popular the more years "go by"...).





> That means taking an existing VB6 application and re-compiling it under "VB7" with little or no (manually coded) changes.


Why would anybody want to recompile such a complex and fully working VB6 application?
If you want to add a few modern GUI-gimmicks, then you can use appropriate COM-libs for that.




> I'm all for replacing Microsoft's common controls, but you can't replace every ActiveX that is still in use.


I agree - and that's the reason why there will never be a 100% compatible "coverage" at the GUI- and Control-level.
That's something one has to accept and swallow - maybe a good thing, when the alternatives to "established controls"
are either (more or less) compatible - or offer other advantages (as: saving lines of code) which makes it "a snap or a relief to change over to them".




> In each and every VB6 application there may be specialist third party ActiveXs that it is not practical to replace, there may be widely used ActiveXs that no one has written a replacement for. And you need to support ADO and DAO too.


But where do you see a problem there exactly?
Maybe best, to bring a small and very concrete scenario, which explains where you see larger problems 
(as said, the new VB7 should support "external COM" at least for non-visual COM-Interfaces and -Classes).




> Your "market" is those (tens of thousands ?) of VB6 users who want an updated language but require the update to be painless. 
> Those developers have legacy VB6 applications to support and extend.


Best done further in VB6 then - if MS breaks something - then also the new (COM-supporting) VB7 would break for the same reasons.




> If a VB6 developer can't compile the application they will (as you say) stick with VB6 on Win32. Most simply don't have the time or resources to do otherwise. 
> What would be the point of a VB7 used by only a handful of developers whilst most VB6 developers stay with VB6 ?


I brought reasons, why VB7 could be attractive "nonetheless" already in my first statement (formulated as a question) at the top of this posting here.




> You need to offer a step-by-step approach, first show that all existing VB6 applications will work on VB7/Win32.


No - that's not why I'd try to write (and later on use) a new VB7.

How long do you think e.g. OLE/COM is still supported?
Wouldn't you agree, that a Class-concept, which is roughly compatible with COM (and can use COM-classes, but is not dependent on COM)
would be nice to have?

Wouldn't you agree, that (in case OLE/COM-support vanishes from the OS) that it would be nice, to have roughly compatible Widget-Controls in 
a COM-independent (and also CommonControls or GDI-independent) encapsulation available?

And wouldn't it be nice, when we could glue "all this new but roughly compatible GUI-stuff" together in the same way as we currently glue things together
in the original VB6-IDE - and with nearly full compatibility in *.bas and *.cls modules?

I'd be happy to have this option.

One also doesn't know, how long the Win-platform will remain "open" for "other compilers or IDEs" at all - 
if it will be allowed in the future to compile your own "Standard-Executable" and run it ... or if "AppStore-Uploads" 
are the only way in future Win-Versions, to express ones creativity (with "MS-Tools only" then of course).

If that is the case, then I want a VB7, which I can use with only smaller changes in the Class-Runtime-also on
other platforms which don't have those restrictions.





> I note what you said about "loss of trust" in Microsoft. For the same reason I haven't used SilverLight or any other Microsoft developer tools since they dropped VB6.  But the main reason I and many others didn't move to VB.Net was the lack of upward compatibility.
> If Microsoft launched their own VB7 tomorrow I would buy it.


Well, I'd do the same perhaps...
But I doubt that they come up with a new VB7 "after all those years".




> I haven't looked at your https://github.com/vbRichClient/vbWidgets but I will do.


To check a few Demos out, you will need to download the BaseDlls first, followed by installing the latest vbWidgets.dll (from the GitHub-Repo).
http://www.vbrichclient.com/#/en/Downloads.htm
The above URL has the appropriate Links and hints for installation.

Then you can check out a few of the higher-level Demos (to see what I mean with *.cls and *.bas only GUI).
http://www.vbrichclient.com/#/en/Demos/GUI/




> I have tried the http://www.vbforums.com/showthread.p...mmon-controls)
> and been very impressed.


That's a lot of (decent and well-done) work by Krool there... 

But as good as it is for existing VB6-Apps - in the new VB7 I would really like to stay away from deeper dependencies to MS-GUI-libs, 
to keep the platform-portability-option alive and "doable with not that much effort".


Olaf

----------


## Schmidt

> That said, I still have more questions at this point.
> 
> Is the plan then to get started with a Git repository for the new VB6 programmed IDE project?


Yes, will set an appropriate Repo up the next weeks.




> What methodology should we have for accepting code modifications to the main branch? Should any particular developer interested in contributing create their own branch for making their own changes, which can then be merged into the main branch if accepted?


Yes, that's easy enough with "forking a GitHub-Repo online" (into your own. previously created GitHub-account, which you can maintain and change against your local HardDisk independently).
If you have "nice changes to contribute", then start a "Pull-Request" - (such Requests become visible on the GitHub-WebPage of the originator-Repo - and can be commented on - and later on 
merged into the main-branch ... thereby fulfilling this "Pull-Request" of the contributor with a "Merge-Response", so to say).




> Do we need some kind of coding standards document? We need to agree on naming conventions, how many space characters a tab should represent, etc...?


Yep, perhaps good to explain those things on the Main-Repo-page in a small "how-to-become a contributor" article (the GitHub-pages offer a Wiki for such things).




> What is the vision for the look of the IDE? Are we trying to replicate the old VB6 IDE, or create something new?


I'd try to mimick the old IDE (maybe just introduce some nicer Icons) as far as possible (the non-SDI-version I mean).




> Is the plan to use vbWidgets for the UI? If so do we need more widgets developed first before we have everything we would need to create an IDE?


[/QUOTE]

From my point of view: Yes definitely - just look at other OpenSource IDEs as e.g. SharpDevelop - 
that's quite a code-volume which was accumulated there over the years - and if such a code-base is (overly) dependent on platform-libs and does 
not work through a GUI-Class-Layer (which offers a level of abstraction), then it becomes very difficult to port to other platforms (as Linux for example).




> If so do we need more widgets developed first before we have everything we would need to create an IDE?


The only two things which are missing in this regard is a cwPropertyGrid- and a cwEditor-Widget.
The cwPropertyGrid is not that difficult - and the cwEditor-Widget could be wrapped by a simple Mockup first (based on a cwTextBox) for the first weeks - 
later on then replaced by a real Editor-Implementation, which interacts more tightly with the Tokenizer-result-structures.

Olaf

----------


## techgnome

I'm largely trying to stay out of this .... heated discussion... but I'd like to just quickly address one question ... at least from my own perspective as a spectator in section 212....
"Why would anybody want to recompile such a complex and fully working VB6 application?"
Let me pose it like this... Why WOULDN'T I want to? Let's say I've got this grand application... it's been carefully maintained over the years... along comes VB7... I like it... it does what I need it to do... I want to port that application over to it... to help ease maintenance in the future... wouldn't it behoove me to first compile the existing app to make sure it can handle it? I'd be plenty ticked (maybe even fleaed) if I go to make some code changes only to find out that it won't compile now in the new and improved VB7.... no? 

-tg

----------


## Schmidt

> I'm largely trying to stay out of this .... heated discussion...


Is it really heated already ... so far I thought not.




> "Why would anybody want to recompile such a complex and fully working VB6 application?"
> Let me pose it like this... Why WOULDN'T I want to?


Because you shouldn't ... because VB6 is enough with regards to maintenance and the only thing which will ever be really "bug for bug-compatible".

And if VB6-compiled Apps ever break, then they will break because MS changed something with regards to OLE/COM - or switched to 64Bit-only OSes.

A "new VB7" which would support: "the whole ton of complex 32Bit-OCX-controls from 3rd party-vendors" fully (with all bells and whistles, bug for bug).
would break too in this case.

So let me ask you again, why would you force the "VB7-team" to come up with "full OCX support", 
when in the outlined case above (MS breaks OLE/COM) all those efforts would be for naught.

Wouldn't it be better, to promote the other approach - and let the "VB7-team" state very clearly early on:

- Look guys, we have achieved nearly 100% compatibility in *.cls and *.bas. ... that should help a great deal whilst you write and type code and copy&paste old routines or re-use whole modules and classes.
- With regards to GUI-compatibility we recommend to use the *.frm-importer, which currently understands (and maps to) all intrinsic VbRuntime-Controls ... +
- plus the following CommonControls: TreeView, ListView, ... also supported in the meantime is the MS-FlexGrid... more to come, please help us with other Control-Mappings...

... or something along those lines.

If such a mapping-approach would be used, then one cannot guarantee a 100% compatibility anymore, because only the very basic Controls would behave in a similar way as the originals
e.g. the VB-intrinsic controls like CommandButton, Label, PictureBox, List- and Combobox, TextBox shouldn't make larger problems ... 
But more complex controls - especially when those "got tuned" (sending Win-Messages to the hWnd of the underlying MS-Control-Class), then things get tricky and very messy, because the vbWidgets are Windowless Controls.

Still this approach would be more "desirable over all" (IMO), because it cannot get broken by MS that easily.
I can only repeat, if MS doesn't break anything - then VB6-compiler-output runs just fine with the old OCXes.

I'm just trying to be realistic here - I have no interest in a heavily MS-dependent VB7, which will break along with VB6 (at the same time, when MS pulls the plug on a certain dependency).

I'd like to invest the limited developer-resources we have into something which "remains", and can survive also on other platforms.

If that means, that I cannot re-use "old OCXes" - then so be it - and as said, there will be options to map some OCXes against existing WidgetControl-classes - 
which could be enough for many smaller or midsized Applications, to make a potential porting-effort easier.




> I'd be plenty ticked (maybe even fleaed) if I go to make some code changes only to find out that it won't compile now in the new and improved VB7.... no?


As I tried to explain above - for me "a new VB7" is apparently something different from what you expect from such an effort (we are not MS and 
have much less developer-resources and will not be able to work full-time on something like that - so we have to choose carefully where we invest time).

So again, to make it more clear for potential helpers too - this project (when finished) will not be able to read and import large and complex
VB6-projects when those contain "a ton of 3rd-party-OCXes on 100dreds of Forms"...
There will be mappings, which will sufficiently support simpler *.frm and *.ctl imports, especially when those contain intrinsic controls only - 
but everything else will get tricky and would cause larger efforts.

Though it shouldn't be *that* difficult to e.g. fork the project at a certain point in time - and then use the MS-VC++ compiler 
(in conjunction with ATL and other COM-helpers) as the final backend which produces the binaries.
In this case you could achieve a much higher OCX- compatibility in a new "VB7WinOnly" - but as said - this would then break along with VB6-produced binaries.


Olaf

----------


## mjohnlq

I think move our vb6 project slowly to linux and mac is more important than 100% VB6-compatible. 
Because vb6 is enought before 2022, vb6 can run in win8, maybe can run in win9.
But microsoft will downfall and even die before 2022. 
So we need move our vb6 to vb7 to other platform slowly, better before 2022. 
Microsoft can die,  this is he deserved, because he has abandoned so many developers.
But our vb6 projects should not die, because we have invested so much time in it.

But I think a command line vb7 compiler is important too.

----------


## ColinE66

I haven't posted in this thread as yet but I am happy and willing to contribute to the VB7 IDE development effort. I am already a vbRichClient user and contributor to the vbWidgets repository on GitHub.

----------


## Kbre

I am personally far more interested in having a good open source multi-platform VB7 to start new projects with, that in having a full upward-compatible one that relies in MS and other third-party OCX dependencies.

----------


## WhyWontIEdieAlready

This is a really interesting topic and discussion.

As a long-time VB6 developer who maintains several strong business applications with a small dev team I would like to tell you my thoughts on all of this:

*Compatiblity*
Of course a 100% compatiblity (binary+source) would be ideal. But of course that will be extremly hard to achieve without having access to the soruce code of the internal compiler and C2. All VB6 developers could be GLAD if a project like this would work and even if it only had 80% compatiblity - because it would mean that the language (and all the knowledge and invested time) would not be wasted. What I would think is a realistic goal is this:
Let the plain source code be as compatible as possible, add a good converter for forms and try to add OCX support (even if not 100% compatible).
OCX (not only controls but also libraries) is still heavily used to interact with 3rd party libraries and a lot of applications are simply depended on those libraries because they are either closed-source or the dev team just cannot afford to re-implement those features themselves. But, that being said, I for one would be absolutly willing to go bug hunting for a month and have some smaller incompatiblities to fix in the long run if that means I would gain longlivity and independence from Micrsoft for my applications, code base and. But without at least a solid OCX support a lot of apps can simply not be ported to VB7 and it can only be used for small-scale projects or new projects. Of course, event then I would prefer it to .NET.

*IDE*
I love the VB6 IDE because it's lightweight and extremly fast. So I would go for simple & fast first and later add support for 3rd party addons which could deliver all those nice features other monolithic IDEs have accumulated over the years. Fast is good!

*Framework*
A fast and good framework which would implement basic functions would completly suffice. Do not overdo this! More features can easily be added by 3rd party libraries. And if the component model allows for statically linked libraries that would be even easier to use 3rd party frameworks without a lot of hassle when it comes to redistribution.

*Language evolution*
I think this should be handeld very carefully - what we all DO NOT want is another .NET clone which is a clone but a tool that is easy to pick up for Beginners and powerful enough for real developers.

*Funding*
I am absolutly sure that there are a LOT of VB6 developers that would donate good money to bring a project like this on the road. I for one would gladly donate several hundred euros to a project like this if it seems to be a realistic and feasible solution to Microsoft horrible treatment of one of their strongest languages ever.

*Legal*
Do not forget about MS long arm. Try to check at least the most basic legal issues before starting a project like this. It would be devastiting if a project like this would be completed only to be shattered by Microsoft.

I would love to see this project being a success.

Dominik

----------


## sten2005

I'm going to look at http://www.vbrichclient.com/#/en/Demos/GUI/ and reply more fully when I have done so.

But at this stage my thoughts are:

If you are telling me that to convert my applications (with many forms and some third party OCXs) I am going to have to spend a long time rewriting them for VB7 then it isn't likely to happen.  Microsoft suggested the same 10 years ago with VB.Net.

If you are telling me I have to keep VB6 and keep my source code in VB6 that is just what I will do. I certainly won't keep one version in VB6 and another version in VB7. That would mean I would have to do every modification twice, once in VB6 and again in VB7. Don't forget that maintaining legacy applications doesn't mean just keeping them running. It means modifying and enhancing them, adding in the latest features (including nose-touch support if that's what the user wants) and giving them the look and feel of modern applications.

I don't really see what you are offering that I can't do now using NSBasic AppStudio.  With this you code using VB source code and it converts this to JavaScript. The approach seems to be similar to what you are advocating. You create forms and place controls on them (in a VB6 like IDE), then cut and paste VB code from VB forms into them. It has the usual controls, such as a TextBox (enhanced to let you specify if the input is numerical, text, dates, etc). You do modifications and enhancements in VB, it isn't a one-time convert and you don't need to know JavaScript. It doesn't support OCXs either. It targets iPad, iPhone and Android.

My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility. It didn't work for Microsoft. RealBasic put themselves forward as a VB6 replacement, PowerBasic tried the same. But again they weren't compatible. So we still use a 15 year old product - VB6.
We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.
I believe that without offering a truly compatible (it doesn't need to be identical, you can use a migration tool & convert to your inbuilt widgets) upgrade so that existing VB6 source code (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled on VB7 (for at least 32 bit Windows) you will lose the bulk of VB6 developers.
I note you suggest a VB7 Win only fork using the C++ compiler to support OCXs.  This may be the way forward. But I wouldn't have any real interest in VB7 until this was available.

You ask if I would experiment with VB7.
Yes of course I would.
And after a day or so I would put it to one side, just like I did with VB.Net, with RealBasic, with Jabaco, with Basic for QT, with Gambas and the rest.

If it ain't upward compatible it ain't VB.

----------


## Schmidt

> I'm going to look at http://www.vbrichclient.com/#/en/Demos/GUI/ and reply more fully when I have done so.
> 
> But at this stage my thoughts are:
> 
> If you are telling me that to convert my applications (with many forms and some third party OCXs)
> I am going to have to spend a long time rewriting them for VB7 then it isn't likely to happen.  Microsoft suggested the same 10 years ago with VB.Net.
> If you are telling me I have to keep VB6 and keep my source code in VB6 that is just what I will do. I certainly won't keep one version in VB6 and another version in VB7.


I was suggesting that, when you have a big fat VB6-application to maintain - then it is best to keep it in VB6.

In addition you can program in VB7 all your "new Apps for the Desktop" with much better performance, more comfort than in e.g. NSBasic - 
and at the source-level fully compatible to old VB6-code.
But if NSBasic is your tool of choice, because you only need "Buttons and TextBoxes and Labels" - and if JS-performance is entirely sufficient for you,
then you surely don't need a native (optimizing) Compiler and also no modern GUI-framework.




> That would mean I would have to do every modification twice, once in VB6 and again in VB7.


No, not if you use VB7 for new stuff and VB6 for old stuff.




> Don't forget that maintaining legacy applications doesn't mean just keeping them running. It means modifying and enhancing them,


I know this scenario well enough - and so far cannot imagine where the problems are with that.
Could you describe exactly (assuming a new VB7 took over your old project without problems), what you 
would do differently now (coding-wise) with regards to maintenance (modifying and enhancing existing code).
In what way exactly would your VB7-based maintenance differ from VB6-based maintenance.




> adding in the latest features (including nose-touch support if that's what the user wants) and giving them the look and feel of modern applications.


Sorry when it gets unnerving - but I'd really like to know, what kind of "latest feature" you are badly in need of - and would expect a new VB7 to offer to you.
If it's only the "look and feel of modern applications" - then choose OCXes or other COMponents which offer that - sometimes just a manifest is enough.
And the current vbRichClient5.dll is (in its current incarnation) a COM-lib - so you can use this new GUI-framework in good old VB6 too.




> I don't really see what you are offering that I can't do now using NSBasic AppStudio.  
> ...
> You do modifications and enhancements in VB, it isn't a one-time convert and you don't need to know JavaScript. It doesn't support OCXs either. It targets iPad, iPhone and Android.


As already said above, when this is entirely sufficient for you (with iPad, iPhone and Android-targets) then you're a happy guy - not much to say anymore.
For me it would not be sufficient, I need e.g. a fast compiler and I want to write full-blown Desktop-Apps for Notebooks and PCs.




> My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility.


I think you overlooked (although already mentioned a few dozen times), that the new language will be nearly 100% compatible to VB6.
And that language-improvements are not on the Todo-list currently - the compatibility in *.bas and *.cls (and coding-wise therefore also in Forms) is priority #1.




> It didn't work for Microsoft. RealBasic put themselves forward as a VB6 replacement, PowerBasic tried the same. But again they weren't compatible. So we still use a 15 year old product - VB6.
> We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.


As just mentioned above - the language itself will not be incompatible.




> I believe that without offering a truly compatible (it doesn't need to be identical, you can use a migration tool & convert to your inbuilt widgets) 
> upgrade so that existing VB6 source code (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled on VB7 (for at least 32 bit Windows) you will lose the bulk of VB6 developers.


I can only state that again ... your list here:
" (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled ... (for at least 32 bit Windows)"
is exactly what VB6 currently supports until MS decides to pull the plug.

I don't really get, what is so difficult to understand in, that *if* a VB7 supports the above list in exactly the same way as VB6, that it is exactly as vulnerable (breakable) as VB6.

An new VB7 should be source-compatible (and it will be that) - and "working in the IDE" should feel like working in VB6 - 
but otherwise it should encourage VB6-users, to decouple from MS-dependencies - and to also decouple from overboarding Win32-API-usage - 
to make it easier to shift to another OS-platform in case that becomes necessary.




> I note you suggest a VB7 Win only fork using the C++ compiler to support OCXs.  This may be the way forward. But I wouldn't have any real interest in VB7 until this was available.


I mentioned this "just for completeness" - if there's enough developers who support such a fork and bring it to an end successfully - why not.
I for my part would consider that a waste - because you will end up with not much more than VB6 currently offers. It is not "the way forward" - 
it is the opposite in my opinion - it binds you to MS and it will make a platform-move much more difficult.




> You ask if I would experiment with VB7.
> Yes of course I would.
> And after a day or so I would put it to one side, just like I did with VB.Net, with RealBasic, with Jabaco, with Basic for QT, with Gambas and the rest.


See, I don't even understand you in *that* regard (or behaviour) - if I don't have the intention to change to another development-tool,
if I know already beforehand that it will be put aside finally, then I wouldn't even start experimenting with it.

Olaf

----------


## techgnome

Olaf - I think the point that sten has been trying to make... and maybe I have this wrong... is that you're motivation for doing this (and let me add that I tip my hat off to you on this as I think you're probably the first most-level headed person to take something like this on in a sane and reasonable manner and is actually doing something about it... props to you...) is on the predication of when (I think we can all agree there is no if about it, it's a matter of when) MS drops VB6 run time support ... you're VB7 will still continue to run... right? Which is fine... so why should I (as a theoretical VB6 developer) wait until then? Why not go ahead and port over the existing VB6 code base to VB7 and get it over with, then it'll continue to run. 

Not only that, but then one could also take advantage of any additional features added to it. 

I think the biggest thing that I hear people complain about is that their VB6 wasn't able to run, with no changes ... much like when we moved from VB4 to VB6 (with a side trip through VB5 for some)... And that seems to be what Sten is looking for here... just take existing VB6 code run it through VB7 just as it is w/o having to change a darn thing.... geezes....VB developers a re a lazy bunch aren't we?  :Wink: 


This next bit isn't directed at anyone specifically, but meant as an attempt at putting some myths into proper context...
I've been following VB.NET almost right from the get-go... I was at a Wrox Conference back in... well... just prior to the .NET release.. and attended a Q&A session with the team that built .NET... it was an eye opener and gave some insight into the why things are the way they are. In the years since, I keep seeing things like "MS dumped VB6" or "MS threw us [VB6ers] under the bus" or "they didn't care about the VB6 developers" ... I can say that those kinds of statements are false. It's not like someone woke up one day and said "hey, let's f* with VB6 developer and create this all new platform that will cause them to re-write everything and all existing code won't work... muwhahahaha!" ... There was a major effort o get VB6 rolled into .NET PROPERLY... problem was with the compiler... the end result was something that would have been so complex that stability of not only the compiler but also the IDE and the apps would have been compromised. It wasn't an easy decision, and there were many months and countless hours trying to hash it out... they just couldn't get it to work in a reasonable manner. 

Ok, I'll slink back into the shadows now...

-tg

----------


## Carlos Rocha

This is to anyone in special, but I think one shouldn't be too radical at this stage.


In my opinion, Olaf's project is a good project and started with the right foot, and - maybe the most important part - is very useful already. By using his "framework" within VB6 one have access to things A LOT better than the equivalent provided by VB6, and it adds lots a modern/new stuff right out-of-the-box: SQLite usage in a similar way to ADO, Cairo drawing (Forms, Widgets, PDF, SVG, among others), Physics engine, TCP, RDP, Reg Free Dll ActiveX, Touching Screen (Gesture), MM Device, OpenOffice/LibreOffice usage, Browse control (WebKit), and a lot more. Being a "one man work" so far, he deserves already the respect of all of us, and the faith that he will get the job done.


I use his SQLite wrapper for a few years, and I'm now starting with the Cairo stuff, and all my future development will depend on the rest of the provided stuff whenever possible, and (again in my opinion) using his stuff is the right way to get in touch with the full project and to "have a say" about it.


Personally, I'm not interested in the VB compatibility by itself (thought I understand who is), but the feeling of a possible Windows independence is good, pretty good. I think, however, that it's more important to make sure that programs based on VB7 will work in Linux with Wine. This way one could still use OCXs, SxS, and many good things that we only have with Windows (being able to use 3rd party libraries like TX TextControl, FarPoint Spread, ComponentOne, and the like, it's probably very important for many of us). Anyway, the reduced Windows dependencies is a step forward for this to happen. Even for who needs .NET I think it's easier to use Wine than Mono.


Just my 2c

----------


## Schmidt

> I think the point that sten has been trying to make... and maybe I have this wrong... is that your motivation for doing this  
> ... is on the predication of when ... MS drops VB6 run time support ... your VB7 will still continue to run... right?


Basically right *). But only in case your: "MS drops support for the vb6Runtime" is meant as: "VB6-apps will stop working, no matter what one will try, 
because MS removed (or just blocked) critical dependencies deliberately - or is forcing a '64bit only' - or 'WinRT-only' onto the new OSes.

*)(I'm just trying to be precise here, because technically: "dropping support for the vb6Runtime" is in no way dangerous for VB6-apps ...
...one can install-and-deploy the vb6Runtime then in the same way as in the days of Win95, when it didn't come preinstalled on the OS).





> Which is fine... so why should I (as a theoretical VB6 developer) wait until then? Why not go ahead and port over the existing VB6 code base to VB7 and get it over with, then it'll continue to run. 
> Not only that, but then one could also take advantage of any additional features added to it.


I'm all for it - please port to the new VB7 as soon as it becomes available and stable.  :Smilie: 
But then do it in a "healthy way" - or just leave it be (meaning: stick with VB6).

Maybe an example can help (a somewhat simplified one, to keep things straight):

You have a VB6-application which utilizes (and here our simplification kicks in) *only* the MSHFlexGrid.ocx - 
(on some Forms) - all the rest on your Forms is made out of intrinsic Std-Controls (Labels, TextBoxes, Combos).

Now assume, we are in 2018 - and MS announces, that the next OS-version will only support 64Bit-Apps - 
and will dismiss the SYSWOW64-stuff (the 32Bit-library-layer) all-together.

That means, that neither the vb6Runtime will work on those new OS - nor will any other 32Bit-binary 
(neither your MyFlexApp.exe nor the MSHFlexGrid.ocx) work anymore on such a 64Bit-only platform.

It was announced that the new OS will come out in 2 years, so you have some time still ... 
also announced was (from the "happy and thriving VB7-community" <g>) that the 64bit-binaries it produces,
as well as the 64Bit-vb7Runtime-classes will work further on the new OS) ... but Ok, what will you do?

Your Application needs to be ported to one of the languages/compilers which can produce binaries 
which will continue to run on this new Win-OS.

You call your friend Fred, who was constantly pointing out to you, how good he fared with .NET,
since it even supported the usage of MSHFlexGrid.ocx in his WinForms-App (he was a fan of the 
Grid as well as you and too lazy to learn "a new one" whilst porting over) ... you hang up disappointed,
because he was telling you, that he's now in the process to re-write all his FlexGrid-code, since
his .NET based App would not run on the new OS either, due to this dependency.

Now you call Bob, who was promoting a VB7-fork "with full support for OCXes" to you some time ago- 
but you discover, that he has the same problems as Fred - his MSHFlex-dependent applications 
will not run on the new OS - he will have to rewrite larger parts.

Now you remember a discussion you had some 5 years ago (with a guy you didn't like very much, 
because  of his: "acts as if he knows everything"-attitude) who told you at that time, that
it doesn't make any sense to support OCXes in VB7 - that it would be better to work on
mappings to Widgets which are fully supported by the new GUI-runtime of VB7 instead.

And that one has to bite the bullet in replacing those OCX-dependencies - writing code,
to work against alternative Grid-Widgets (the less adaption-code to write, the more interface- 
compatible to existing OCXes those Widgets are).

Though that sounded like work to you, so you stuck with the "just use VB6-further until it breaks"-
approach ... but as said - you still have two years - what will you do (since "learning a new Grid" is mandatory now) :

- use .NET which is less compatible at the SourceCode-Level than "the new VB7"
- use the VB7-fork which supports OCXes (also 64Bit-versions of them) - but as seen, is pretty dependent on MS-tech (which can break any time)
- use the "original VB7" which always had platform-independence and decoupling from as much 3rd-party-libs as possible in mind, and in the meantime also runs on Linux.




> I think the biggest thing that I hear people complain about is that their VB6 wasn't able to run, with no changes ... much like when we moved from VB4 to VB6 (with a side trip through VB5 for some)... And that seems to be what Sten is looking for here... just take existing VB6 code run it through VB7 just as it is w/o having to change a darn thing.... geezes....VB developers a re a lazy bunch aren't we?


Yep, seems so - can't do much about that - but the example I've just brought, points out some of the issues in that regard (when "reality just sucks").
<shrug>




> This next bit isn't directed at anyone specifically, but meant as an attempt at putting some myths into proper context...
> I've been following VB.NET almost right from the get-go... I was at a Wrox Conference back in... well... just prior to the .NET release.. and attended a Q&A session with the team that built .NET... it was an eye opener and gave some insight into the why things are the way they are. In the years since, I keep seeing things like "MS dumped VB6" or "MS threw us [VB6ers] under the bus" or "they didn't care about the VB6 developers" ... I can say that those kinds of statements are false.


Nope, they are not - *definitely not*.




> It's not like someone woke up one day and said "hey, let's f* with VB6 developer and create this all new platform that will cause them to re-write everything and all existing code won't work... muwhahahaha!" ...


It is still possible, to write (and compile) C++ code without any .NET-dependencies,  the continuing VC++ compiler-versions are still well-maintained and able to produce COM-binaries.
COM, which never was dead as a technology (just another lie from MS at that time) and which with WinRT sees a promotion into the top-tier even now.

So what exactly do you think made it *impossible* for MS  (with those huge developer-resources), to provide the same "continuing C++compiler technology"
in the same fashion as before (with C2.exe along with VB5 and VB6) in a continued Classic-VB-branch?
You don't seem to know the story, that a VB7 (the true one) was already semi-finished and at least in Beta-stage - even presented at the german BASTA-Developer-conference (somewhere around 2000, don't know the exact date anymore).





> There was a major effort o get VB6 rolled into .NET PROPERLY... problem was with the compiler... the end result was something that would have been so complex that stability of not only the compiler but also the IDE and the apps would have been compromised. It wasn't an easy decision, and there were many months and countless hours trying to hash it out... they just couldn't get it to work in a reasonable manner.


Well, they lied to you - and found a happy believer as it seems.

Olaf

----------


## WhyWontIEdieAlready

One word before I start writing: I will simply use "OCX" for controls and ActiveX DLLs because it's convenient ;-)
I always mean ActiveX Controls (OCX) *and* ActiveX DLLs since the technology they are based on is virtually identical.

I do not see your point in arguing that it would be better to move away from OCX *now* because it's support *could* be dropped by Microsoft later on. 

As a developer I search replacement for a compiler and an IDE that is not officially supported any more but still want to keep using external libraries that are very well supported. A lot of 3rd party OCX developers offer up-to-date versions of their controls and libraries. It's not like OCX is dead - not by any means. 

If there was a VB7 that would support OCX that would mean I could concentrate on porting the source of my main app to VB7 now and deal with dependencies of 3rd party (or my own for that matter) libraries when the time comes or I have time to spare. If it would not support OCX it's an "all or nothing" gamble that costs a lot more time and money. Also there is no garantuee that all of the external functionality can be added in a reasonable timeframe (if at all).

Also: *If* Microsoft would drop OCX support, the developers of said 3rd party libraries would have to move on themselves and would probably provide new versions of their controls and libraries in another form that could by used by developers.

If you start removing 3rd party functionality from your source just for the hell of it you either have no budget that needs to be held (i.e. academic/hobby developer) or have more than enough money to spend for a project that could consume thousands of dollars/euros worth of developer time (depending on how much 3rd party technology you embed and how critical it is to your project) which is a luxury not many developers can afford.

Don't get me wrong: If it would be a financially viable solution I would gladly remove all 3rd party dependencies but for the forseeable future that is just not an option for me.

----------


## sten2005

Hi Olaf,

My apologies for the delay in replying, I've been on-site at a large user  discussing upgrading their VB6 applications to Windows 8 - work has to come first  :Smilie: 

There was probably too much detail in my last post (and therefore in your reply). Let me try again...

I am very impressed that someone (you) who seems capable of bringing a VB7 project to fruition has stepped forward. I support virtually everything you have put forward for this project.
My disappointment is that you don't see the importance of maintaining upward compatibility from VB6 to VB7. I believe without this this project will ultimately fail (I don't mean that I think you won't complete the project, I mean that the uptake of VB7 by the VB6 community will be negligible). If a VB6 developer can't take an existing VB6 application and recompile it under VB7 with the minimal amount of work they will not move to VB7.

When I said 


> My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility.


     I worded that rather loosely. I didn't mean "language" in the tightly defined meaning which you obviously read it, I meant it to refer to the whole VB7 "package" - that is language, IDE, OCX support, and everything else.
Please read that line as "My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that VB7 *package* 'improvements' justify breaking upward compatibility."
Also I am using "OCX support" as shorthand to mean support for ActiveX/OCXs, for Windows API calls, for DAO and ADO support, etc.

Again when I said 


> So we still use a 15 year old product - VB6.
> We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.


 I was again referring to the whole "package" not specifically the language.

My concern is that when you complete VB7 you will have a product to be proud of; but most of us VB6 developers will be using a 20 year old product - VB6.

You say 


> I can only state that again ... your list here:
> " (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled ... (for at least 32 bit Windows)"
> is exactly what VB6 currently supports until MS decides to pull the plug.
> 
> I don't really get, what is so difficult to understand in, that *if* a VB7 supports the above list in exactly the same way as VB6, that it is exactly as vulnerable (breakable) as VB6.


There is nothing difficult to understand there.  But you are proposing a product that breaks this now. Microsoft may or may not break it at sometime in the future.
It is a concern that Microsoft breaks VB6 support but I note the following points:
Moving to VB7 with OCX support would at least replace Microsoft common controlsVB7 with OCX support would work on Windows 32bit (& hopefully Windows 64 bit and Linux using WINE ?)We gain time to look at either replacing OCXs or at producing 'Lite' versions of the applications without OCXs to run on tablets etc.Windows (probably) isn't going to go away - even limiting applications to Windows only would still be usefulMicrosoft's support statement for VB6 promises support until 2023 (on Windows 8) - presumably therefore VB7 with OCX support wouldn't break either.

You say 


> See, I don't even understand you in *that* regard (or behaviour) - if I don't have the intention to change to another development-tool,
> if I know already beforehand that it will be put aside finally, then I wouldn't even start experimenting with it.


It is far from not having the intention to change to another development tool, it shows the difficulty of finding an acceptable development tool. VB.Net, RealBasic, PowerBasic, Jabaco and the rest don't meet the requirements - for several reasons but mainly the lack of upward compatibility from VB6.

----------


## Schmidt

> [OCX-support]
> 
> ... you are proposing a product that breaks this now.


No, a "breakage" would be, when VB7 ("originally") came with OCX-support and when this support 
would be removed in an later upcoming version.

As I see it, we have a fully OCX-supporting (and still nice) VB6-IDE.

And if the project lifts off, then we have in one or two years a VB7, which is VB6-code-compatible,
supports all kind of Declare-definitions - supports Classes and Class-libraries - and a new GUI-concept
(with a lot of already existing Control-alternatives in form of the new Widget-classes).

We'd have that *in addition* to VB6 (and in VB6 one can use the same Widget-Classes in a calling-compatible way too BTW) ... 
so if we (as a community) would use the following years (I assume we still have a decade or so, until MS pulls the plug on VB6 in one way or another)
if we would use those years to round up a nice package of Widget-classes (all community-maintained, free to use by everybody) - 
then the discrepancy between "commercial OCXes" and "community-based Widgets" would not be that large.




> Microsoft may or may not break it at sometime in the future.
> It is a concern that Microsoft breaks VB6 support but I note the following points:
> Moving to VB7 with OCX support would at least replace Microsoft common controlsVB7 with OCX support would work on Windows 32bit (& hopefully Windows 64 bit and Linux using WINE ?)We gain time to look at either replacing OCXs or at producing 'Lite' versions of the applications without OCXs to run on tablets etc.Windows (probably) isn't going to go away - even limiting applications to Windows only would still be usefulMicrosoft's support statement for VB6 promises support until 2023 (on Windows 8) - presumably therefore VB7 with OCX support wouldn't break either.


You also didn't answer my previous question (with regards to, that the whole list above is already supported by VB6, and what you expect a VB7 to 
provide you in addition).

Please see my reply to WhyWontIEdieAlready, where I asked the same thing (but also answered it from my point of view).

Olaf

----------


## Schmidt

> One word before I start writing: I will simply use "OCX" for controls and ActiveX DLLs because it's convenient ;-)
> ...


Arrggghhh - just discovered, that my detailed reply to your posting above (about one hour of work) was somehow "lost in transmission" - 
not sure why or what has happened, maybe a moderator has the ability to discover something at the serverside and can restore what I've sent?

Olaf

----------


## dee-u

When are you guys going to end the discussions and start working on this?

----------


## sten2005

Your view seems to be the same as that of Microsoft when they brought out Vb.Net. "Move to our shiny new language(package) - but your legacy code is your problem".  That didn't persuade VB6 developers to move to VB.Net and it won't persuade them to move to VB7 either.

----------


## WhyWontIEdieAlready

@schmidt

Oh, that sucks :-(

If it does not turn up, could you at least post the essence of your thoughts? Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly.
Also, for the record, I think that even a VB7 without support for OCX-Controls and Active-X-Dlls would be a good thing, but it does not seem to be a viable option for a lot of existing projects. But from my standpoint it would not help my current situation that much without said support.

I am also not sure why you think that OCX/ActiveX support is a bad idea. Yeah, it may break in the future, but it would help with converting projects today.

Let's compare:

VB.NET does support OCX/ActiveX DLLs but did not support an easy way to port the source without major code changes.
The VB7 you suggest would allow easy porting of code but would not allow OCX/ActiveX integration.

Both is a big problem for me. 
With VB.NET I would need to rewrite about 250k Lines of Code - I just cannot afford that.
With a VB7 without OCX/ActiveX support I would have to port all of our own components and libraries to another component model or make them static and also I would have to search replacements for several 3rd party libraries that are used for some critical features. That is something I also cannot afford.

So, yeah I think VB7 is a good idead - event without OCX/ActiveX support. But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).
I still would appreciate it and certainly would have a look and maybe start new projects in VB7 because having an open source IDE/Framework/compiler for a langauge I am more than familiar with is still a good thing - but not for my existing stuff that needs to be maintained for the foreseeable future.

As I see it: If we had VB7 with OCX/ActiveX support we could port our projects now and hopefully enough 3rd party developers would support that system natively (without ActiveX) so that when and if the time comes and Microsoft pulls the plug on ActiveX we would be ready.

Dominik

----------


## dee-u

> Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly.


The thing is, this has rather just became a discussion and it might just end up just a discussion with no result just like LightFusion.

----------


## sten2005

> VB.NET does support OCX/ActiveX DLLs but did not support an easy way to port the source without major code changes.
> The VB7 you suggest would allow easy porting of code but would not allow OCX/ActiveX integration.
> 
> Both is a big problem for me. 
> With VB.NET I would need to rewrite about 250k Lines of Code - I just cannot afford that.
> With a VB7 without OCX/ActiveX support I would have to port all of our own components and libraries to another component model or make them static and also I would have to search replacements for several 3rd party libraries that are used for some critical features. That is something I also cannot afford.


Me too !  And I guess this applies to many in the VB6 community.




> So, yeah I think VB7 is a good idead - event without OCX/ActiveX support. But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).


And sadly not an option for me either.  :Frown:

----------


## WhyWontIEdieAlready

@dee-u

Yes, that is a risk and I agree that seeing progress and getting a start is very important.

But I think especially the question of the desired target level of compatiblity is so important, that it needs to be discussed before.
Otherwise people may invest time and be disappointed afterwards or the project might fail because of not laying some important ground rules/specs before.

----------


## mjohnlq

As for me, I hope:
step 1. develop the vb7 compiler that can compile the old vb6 .cls and .bas to a console .exe file, as possible as VB6 language compatible.  the compiler can run on linux and windows, maybe can based on llvm.  this step no need support ui controls files such as .frm or .ctl files. but need develop the file and network and other no-ui class library that needed by the ui-controls, all these library file are .cls and .bas file.
step 2. develop the vb7 controls with the same names as the old vb6, the vb7 controls can based on vbRichClient or wxWidgets or qt or others.  the controls need can compiled use the compiler developed in step 1.
step 3. develop the vb7 compiler that can compiler the old vb6 .frm and .ctl and .res files use the controls developed on step2,  after this step, all the vb6 projects that didn't use the activex controls can  be compilered and run on linux and windows.
step 4. develop the vb7 compiler that can support activex control on windows, to do as possible as VB6-compatible on windows.
step 5. develop the vb7 IDE that only use the controls develop in step2, then the vb7 ide can run on windows and compile old vb6 project, and the ide can open the vb6 projects on linux.
Then, all my vb6 project can opened on the new vb7 ide and can compiled and run on window. And on linux need do some modify to compiled and run on linux, so can move all my vb6 projects slowly from windows to linux.

----------


## Schmidt

Whoaa, too many replies to answer them all "as carefully" as I did before - so please forgive me, when in the following I will "brush over it"
in a fast (and rough) way - please don't take anything personally - I just want to make my position more clear, even if it "hurts" somebody.

So here my "staccato answers" to the postings in the order they came up:

@dee-u:
> "When are you guys going to end the discussions and start working on this?"

Good point - let's stop talking - either you help - or you don't (well - and I note from your wording above, that you don't count yourself among the helpers)


@sten2005:
> "Your view seems to be the same as that of Microsoft when they brought out Vb.Net. "Move to our shiny new language(package) - but your legacy code is your problem". 
> "That didn't persuade VB6 developers to move to VB.Net and it won't persuade them to move to VB7 either."

To make it short - I don't care who is "persuaded to move to it *later when its finished*" (since that doesn't help me much with the problems at hand) ... 
VB6 is still entirely sufficient for many things - and so there's apparently not much real pressure on the VB6-devs - later if that pressure increases in the future, 
then those developers will start looking for alternatives - and I hope that (among the different choices, which are then available in 5-10 years time), 
that VB7 stands out with a compiler which is the most compatible to the VB6-language - and with an IDE which is also very familiar, and with native Widget-Controls 
which look and feel familiar too.


@WhyWontIEdieAlready (Dominik)
> if it does not turn up, could you at least post the essence of your thoughts? 

I've explained my plans, how to achieve component-model-libs which offer selfdescribing classes - 
and that I think I can manage this in a way which is rather compatible to COM - though still remains platform-portable.
So, for COM-Dlls there is a high probability that access to COM-classes will be available - though OCXes are interface- and 
also siting-wise an absolutely over-engineered and complex thing MS cooked up there - and I'm not willing to support this 
clumsy approach directly in the new language-runtime and the compiler - the new Widget-concept is based on just two 
interfaces - "just a normal class", and siting-wise also totally easy to handle (and will be fully platform-portable).

That was basically the essence of the technical background.

> "Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly."

It is - those who are about to invest time (which apparently is not dee-u's intention) deserve a little bit of a "roadmap-explanation"
and where the whole thing is supposed to end up.

> "Also, for the record, I think that even a VB7 without support for OCX-Controls and Active-X-Dlls would be a good thing, "
Yep, the full *.cls and *.bas support alone should everybody "make dancing with joy" here (at least, so I thought) - 
and as said, ActiveX-Dlls will very likely be supported - because that's not really difficult - when the Class-concept of the
new compiler is pretty compatible to the COM-base interfaces and appropriate VTable-structures and -behaviours.


> "but it does not seem to be a viable option for a lot of existing projects. But from my standpoint it would not help my current situation that much without said support."
As said, your current situation is not really "dire" - you have a well enough working VB6 still.

The question I was asking you in my lost posting (and also sten2005, but he didn't care to answer it) was:

"What do you expect from a VB7, which VB6 cannot offer to you these days too."

And for my part I answered it with:
First and foremost: platform-independence, a community-based source-base nobody can take away "from us" in the future - and VB6-code-compatibility.
(and a few other things of course, but those are secondary).

VB7 shall be (in my thinking) a tool which "nobody is able to break anymore" - but if it ties itself (with its runtime-roots) too deeply to MS-approaches one can find only on the 
Win-platform, then we loose that strongest of its features - that's why OCX-support is entirely secondary in my thinking - if there's enough contributors for that, then it 
will come later in a sideward-docking approach, which is offered in addition to the Runtime-supported NativeWidgets (nothing is impossible to accomplish, binding-wise - with a C-compiler in the backend).

> "I am also not sure why you think that OCX/ActiveX support is a bad idea. Yeah, it may break in the future, but it would help with converting projects today."
Those projects would (after conversion) break in the same way as when you'd have left the OCXes in your VB6-project - I still don't understand, why nobody sees the logic behind that.

If you port something, then port it decently (in a way that will not break in the next 10 years at least).

A tool which will offer both: platform-independence over its native Widget-concept, but also full compatibility to OCXes and older VB6-Controls - 
that's asking too much from a community-project with (yet) limited man-power.
Let's finish the first round - see where we end up (and how large the team is at that point in time) - then move further and decide which 
additional features go up or down on the priority-list.

> "Let's compare:"
> "VB.NET does support OCX/ActiveX DLLs but did not support an easy way to port the source without major code changes."
> "The VB7 you suggest would allow easy porting of code but would not allow OCX/ActiveX integration."

Well, you forgot: VB6 offers full support for OCXes/AXDlls and is fully compatible to VB6

> "Both is a big problem for me. "

And why is that - please ask yourself truly, why it comes, that you consider that a big problem.
Is it not the fear, that MS will break something in the future, which will render VB6-Apps useless?

I can only tell you again - if that your fear was well-founded and MS will break something that renders VB6-apps useless, 
then a highly compatible designed VB7-compiler, which offered fulll OCX-support will be broken too.

What you could think about instead is: what tools can make such a potential future breakage more bearable (with the least over-all-efforts)?

And when there's something out there, which has "we will be unbreakable" written in bold letters all-over its flag - 
and is nearly fully VB6-code-compatible - wouldn't that project worth a thought from your end - would it be worthy of your support?


> "So, yeah I think VB7 is a good idead - event without OCX/ActiveX support. 

Thanks - thought so too.  :Smilie: 

> "But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).

Currently, yes - but I explained just that a few lines above - so let's wait for the VB6-breakage.


> "I still would appreciate it and certainly would have a look and maybe start new projects in VB7 because having an open source IDE/Framework/compiler for a langauge I am more than familiar with is still a good thing "

Exactly, an "open source IDE/Framework/compiler for a language one is familiar with is a good thing"...
though somehow I have the feeling - that you still consider the whole idea as "a product" - and yourself "a customer" - and that 
"announcing to not buy the product" (in a kind of "customer is always king"-fashion) will achieve something ... IMO this is not the case.

In a community-project which lives from the efforts of contributors - the only thing what counts is the input those people give.
If you are among them, then your opinions have more weight - you could show (per code-contribution) if an idea of yours is worthwhile.

> "As I see it: If we had VB7 with OCX/ActiveX support we could port our projects now and hopefully enough 3rd party developers would support that system natively 

No - nothing would happen then (without having a kind of soft-pressure, which will encourage the writing of Widgets instead of OCXes) .

Olaf

----------


## Schmidt

> As for me, I hope:
> step 1. develop the vb7 compiler that can compile the old vb6 .cls and .bas to a console .exe file, as possible as VB6 language compatible.  the compiler can run on linux and windows, maybe can based on llvm.  this step no need support ui controls files such as .frm or .ctl files. but need develop the file and network and other no-ui class library that needed by the ui-controls, all these library file are .cls and .bas file.
> step 2. develop the vb7 controls with the same names as the old vb6, the vb7 controls can based on vbRichClient or wxWidgets or qt or others.  the controls need can compiled use the compiler developed in step 1.
> step 3. develop the vb7 compiler that can compiler the old vb6 .frm and .ctl and .res files use the controls developed on step2,  after this step, all the vb6 projects that didn't use the activex controls can  be compilered and run on linux and windows.
> step 4. develop the vb7 compiler that can support activex control on windows, to do as possible as VB6-compatible on windows.
> step 5. develop the vb7 IDE that only use the controls develop in step2, then the vb7 ide can run on windows and compile old vb6 project, and the ide can open the vb6 projects on linux.
> Then, all my vb6 project can opened on the new vb7 ide and can compiled and run on window. And on linux need do some modify to compiled and run on linux, so can move all my vb6 projects slowly from windows to linux.


Your list above favours a "compiler first, then everything else"-approach.

I've already explained why I don't think that to be a good idea in my very first post in this thread.

There exist already well-working basic-compilers (developed in a non-integrated, standalone-fashion) as FreeBasic and OxygenBasic.

Especially FreeBasic does exist now for a few years already - and so far there is no well-integrated IDE-concept in sight,
which offer something like VBs UserControl-designer (so that you can design your own Controls/Widgets).
Also Edit&Continue is not addressed in any way (Debugging support in the existing IDEs for FreeBasic is very limited).

So there you can study already "a case" where a "standalone-compiler-first, IDE and GUI-bindings later" approach was failing
(despite a relatively large community).

If we want to come up with a tightly integrated, "Visual Environment" - then we will have to build this thing around 
an IDE - and integrate the compiler there in a way, which interacts in the same fashion as VB6 with the Editor-Window
(pre-compiling the current line after you move the cursor away from it in the Editor) ... we will need to try already in the 
very basic first compilation-tests an integration of the Debugger-Handling and an Edit&Continue concept which interacts 
visually with the Editor-Pane and the watched variables.
We need to do that early, as long as things in the compiler and Editor are still simple - if we start an attempt later when
the compiler is already in an advanced state - I foresee larger problems to integrate something like that successfully and
as deeply as we have it available in the VB6-IDE currently.

That said - in case you are the author of the llvm-based approach here: 
https://code.google.com/p/extended-b...extended-basic

I'd like it really much, when you would join the team.  :Smilie: 

Olaf

----------


## jpbro

> Yes, that's easy enough with "forking a GitHub-Repo online" (into your own. previously created GitHub-account, which you can maintain and change against your local HardDisk independently).
> If you have "nice changes to contribute", then start a "Pull-Request" - (such Requests become visible on the GitHub-WebPage of the originator-Repo - and can be commented on - and later on
> merged into the main-branch ... thereby fulfilling this "Pull-Request" of the contributor with a "Merge-Response", so to say).


I've started contributing to the vbWidgets project on GitHub. While I use Git for my own projects, I'm the only developer which makes it easy to have my own "protocol" for submissions. I hope I've followed the proper protocol for your project, but please let me know if you would like things done differently.


Regarding the controversy as to whether to support OCXs, it has become a polarizing issue.

Do you see a path where the IDE can be developed to support a plugin extension that could offer some kind of OCX support (perhaps in a container widget that bubbles events up to the new form engine). This would allow a second group of interested parties to spend effort developing OCX support, while the rest of the team that doesn't really care for it can ignore those efforts and work on the rest of the IDE.

This would also help to entice VB6 developers over who think they need OCX support, and introduce them to the new IDE and new features of framework. While they get comfortable with the new environment, over time they could migrate their apps completely off the OCXs and gain full cross platform, 64-bit, unicode, etc... functionality.

----------


## WhyWontIEdieAlready

@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

----------


## WhyWontIEdieAlready

@schmidt

Here are some suggestions for a compromise for OCX controls based on your suggestion for a VB7:

When opening a VB6 project the IDE will have to do some sort of conversion (to transfer intrinsic VB forms & controls to the new widget system), right?. A good approach could be to program the converter to use conversion manifests for different control types so that a developer could add their own conversion manifests to convert other controls as well. That would help with all OCX Controls that only add optical value (like better looking buttons etc.) and already have a replacement that offers the same functionality but in incompatible form. The conversion file would include mappings for properties, events, etc. and should have the ability to contain VB code in itself to help with more complicated stuff. 

Here is an example:

*MyCrazyCustomButton.occ:*



```
Public PropertyMappings as new cMap = (
    Text => Caption
    TextColor => ForeColor
)

Public EventMappings as new cMap = (
    DoubleClick => DblClick
)

Sub HandleProperty(Byval pPropertyName As String, Byval pAssignedValue, Byval pWidgetContext AS cWidgetContext)
    Select Case pPropertyName
        Case "Theme"
            If pAssignedValue = "iThemeWarning" Then
                pWidgetContext.SetProperty("BackColor", Rgb(255,0,0))
                pWidgetContext.SetProperty("ForeColor", Rgb(255,255,255))
                pWidgetContext.SetProperty("Icon", "Icons\wa
            Else
                [...]
            End If
    End Select
End Sub
[...]
```

Another helpful conversion tool would be the ability to auto-generate widget templates based on used OCX controls that do not have a conversion manifest: If the import assistant stumbles upon a control it checks the availability of a conversion manifest (which could even be used for intrinsic VB controls to minimize hard coded conversion routines). If none is found it queries the controls' interface and generates a dummy widget with all the needed properties, methods, functions and events to start writing a replacement. This "dummy" would ensure that the conversion can be completed and can be used as a temporary placeholder or a good starting point to write a custom replacement.

Dominik

----------


## WhyWontIEdieAlready

> The question I was asking you in my lost posting (and also sten2005, but he didn't care to answer it) was:
> 
> "What do you expect from a VB7, which VB6 cannot offer to you these days too."
> 
> And for my part I answered it with:
> First and foremost: platform-independence, a community-based source-base nobody can take away "from us" in the future - and VB6-code-compatibility.
> (and a few other things of course, but those are secondary).


Sorry, I posted a whole lot of stuff and DID forget to answer the question ;-)
So here it comes:

I would love to see the following features in a VB7 today:
- I like the open-source aspect very much, but would -to be honest- also settle for a commercial product if they would still respect their customers and would offer a good support
- The ability to attract younger developers that currently do not want to invest time in a "dead language"
- A bug-fixed IDE with some new comfort features (but not a bloated one like VS is offering - I rather like it fast & slick!)
- Some enhancements regarding the language itself to help dealing with larger projects: Better inheritance, easier syntax for optional parameters, small stuff like that - but it would make a big difference in terms of efficiency
- Platform independence (because in my humble opinion and strictly professional speaking Windows 8 Modern UI plain s*cks)

Dominik

----------


## WhyWontIEdieAlready

@schmidt

Sorry for posting so much, but I think I just found a simple solution to provide an OCX bridge widget based on your vbRichClient framework:

It's pretty simple: We could develop a tool to automatically create a widget-wrapper for any given OCX Control. This tool could even be integrated in the import assistant, so that importing a VB6 form would work like this:

- Check if there is a conversion manifest (for intrinsic controls and other controls that already have a valid replacement)
- YES: => Convert to new widget 
- NO: => Create wrapper widget and compile it automatically using the old VB6 compiler (that is needed for the wrapper creation, not for the later runtime) and use the wrapper

How the OCX wrapper widgets works and why it will work with your system as long as Windows supports the VB6 runtime including thunderforms:

- It's simply a widget in your format, it's just an ActiveX DLL component 
- Compiling the wrapper will require VB6.exe / C2.exe since it uses a thunderform as a host for the wrapped OCX control
- In runtime it does only require VB6 runtime support of the target operating system (Wine + Windows up until Microsoft pulls the plug)
- When connecting to the parent by the "AddedToHierachy" event it will dynamically create a thunderform and dynamically add the control
- The Win32 API command "SetParent" is used to make the form a child of the parent form (accessing it's hwnd over your widget architecture)
- If the base widget is moved, shown, hidden, resized so is the form and the wrapped control
- If the widget is removed the Form will be removed with SetParent Form.hwnd, 0 and the hosted OCX control will be destroyed
- All events, properties and methods of the hosted OCX control will be mapped and be made accessible without direct access to the wrapped object and therefore there is no need to support the VBExtenderObject on the side of your framework - just Events, Methods, Properties

We could event write a universal OCXWrapper that can basically add every OCX dynamically to a form based on the vbRichClient framework by creating it via Form.controls.add("Server.Control", "Name", Form), accessing it's events dynamically by using the VBExtenderObject and making it's properties and methods available by using the "InvokeHookArray" method of the TypeLibe Information Library (TLBINF32.dll).

Here is a proof-of-concept (without properties and methods, but that is guaranteed to work because I already tried this in another project of me where my own scripting language can bind ActiveX-Dlls and create the COM-objects located within):

*fOCX.frm*


```
VERSION 5.00
Begin VB.Form fOCX 
   BackColor       =   &H0080C0FF&
   BorderStyle     =   0  'Kein
   Caption         =   "Form1"
   ClientHeight    =   3150
   ClientLeft      =   0
   ClientTop       =   0
   ClientWidth     =   4680
   LinkTopic       =   "Form1"
   ScaleHeight     =   3150
   ScaleWidth      =   4680
   ShowInTaskbar   =   0   'False
   StartUpPosition =   3  'Windows-Standard
   Begin VB.CommandButton but_SelfDestruct 
      Caption         =   "Destroy"
      Height          =   315
      Left            =   0
      TabIndex        =   0
      Top             =   0
      Width           =   1275
   End
End
Attribute VB_Name = "fOCX"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit
```

*cwOCX.cls*


```
Option Explicit

Public Event OCXEvent(pEventInfo As EventInfo)
Private Declare Function SetParent Lib "user32" (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long

Private WithEvents but_SelfDestruct As CommandButton
Private WithEvents HostedControl As VBControlExtender
Private WithEvents Form As Form
Private WithEvents W As cWidgetBase


Public Property Get Widget() As cWidgetBase: Set Widget = W: End Property
Public Property Get Widgets() As cWidgets: Set Widgets = W.Widgets: End Property

Private Sub Class_Initialize(): Set W = Cairo.WidgetBase: End Sub
Private Sub Class_Terminate(): Destroy: End Sub
Private Sub but_SelfDestruct_Click(): Destroy: End Sub

Sub Destroy()
    If Not Form Is Nothing Then
        Set but_SelfDestruct = Nothing
        SetParent Form.hWnd, 0
        Unload Form
        Set Form = Nothing
    End If
End Sub

Private Sub HostedControl_ObjectEvent(Info As EventInfo)
    RaiseEvent OCXEvent(Info)
End Sub

Private Sub W_AddedToHierarchy()
    Set Form = New fOCX
    Set but_SelfDestruct = Form.but_SelfDestruct
    SetParent Form.hWnd, hParentHWND
    
    Licenses.Add "MSComctlLib.TreeCtrl"
    Set HostedControl = Form.Controls.Add("MSComctlLib.TreeCtrl", "myctl", Form)
    Dim I As Long
    For I = 1 To 10
        HostedControl.object.nodes.Add Key:="Test" & Str(I), Text:="Test" & Str(I)
        HostedControl.object.nodes.Add Relative:="Test" & Str(I), Relationship:=4, Text:="TestChild" & Str(I)
    Next I
    
End Sub

Private Sub W_Hide()
    If Not Form Is Nothing Then Form.Hide
End Sub

Private Sub W_Show()
    If Not Form Is Nothing Then Form.Show
End Sub

Private Sub W_Paint(CC As cCairoContext, ByVal xAbs As Single, ByVal yAbs As Single, ByVal dx_Aligned As Single, ByVal dy_Aligned As Single, UserObj As Object)
    
    If Not Form Is Nothing Then
        Form.Show
        Form.Move xAbs, yAbs, W.Width * Screen.TwipsPerPixelX, W.Height * Screen.TwipsPerPixelY
        Static vFirstResizeDone As Boolean
        If vFirstResizeDone = False Then
            vFirstResizeDone = True
            W_Resize
        End If
        HostedControl.Visible = True
    End If
    
End Sub

Private Sub W_Resize()
    If Not Form Is Nothing Then
        Form.Move Form.Left, Form.Top, W.Width * Screen.TwipsPerPixelX, W.Height * Screen.TwipsPerPixelY
        HostedControl.Move 0, but_SelfDestruct.Height, Form.ScaleWidth, Form.ScaleHeight - but_SelfDestruct.Height
    End If
End Sub

Private Property Get hParentHWND() As Long
    Dim vP As cWidgetBase
    Set vP = W.Parent
    If vP.hWnd > 0 Then
        hParentHWND = vP.hWnd
        Exit Property
    End If
    While Not vP.Parent Is Nothing
        If vP.hWnd > 0 Then
            hParentHWND = vP.hWnd
            Exit Property
        End If
        Set vP = vP.Parent
    Wend
End Property
```

*Attention:* Before unloading the containing form you have to click "Self destruct" otherwise the app will crash. That is because the base widget has no "RemoveFromHierachy" event and we need to call SetParent and restore the original parent handle (0=Desktop) before unloading the form.

Some other things regarding vbRichClient that came up during testing this (I only first used vbRichClient two hours ago, so maybe the following points are not valid, so feel free to correct me):
- First of all: Great work! Looks very promising and I like the use of Cairo for Windows (my own UI framework just uses GDI+ and has a wrapper for that, but of course it uses OCX for the controls)
- Resize should be called after AddedToHierachy
- There should be a RemoveFromHierachy Event that is triggered before the widget is removed (also called during unloading of the parent form)

I know that there still would be some issues - especially if a control searches it's environment to access another control and there are still some things. Another issue is of course that you cannot z-order a wrapped OCX control below a vbRichClient based widget because the widget is drawn to the form while the OCX control is an overlay. So it's far from perfect, but it still could provide support for some 3rd party controls that cannot be converted otherwise because we do not have the controls source code.

I know that this would allow me to port my applications completely: I would convert my own controls (hopefully using an mostly automatic converter) to the new widget format while accessing the unconvertable 3rd party controls through wrapper widgets.

It definetly isn't a solution for everybody but it would allow at least some degree of OCX use without the need for VB7 itself to support OCX controls.

I am very interested to hear your opinion about this.

Dominik

----------


## Schmidt

> @schmidt
> 
> Sorry for posting so much, but I think I just found a simple solution to provide an OCX bridge widget based on your vbRichClient framework:
> 
> It's pretty simple: We could develop a tool to automatically create a widget-wrapper for any given OCX Control. 
> ...



Thanks Dominik, for the proof of concept - and of course, as long as we produce 32bit-Binaries with VB7 - and the Vb6-Runtime is still available and working - 
we could use something like that in conjunction with the VB6-Form-engine (encapsulated in a VB6-COM-Dll), to perform the Form.Controls.Add-Call ...
(which is the critical point in the whole exercise and does quite a lot of hidden and complex stuff under the hood with regards to the IOlexxx- UserControl-interfaces and siting).

For those who want to "merge" vbRichClient5-Widgets and normal VB-Controls on the same Form in *VB6*, including correct Tab-Key support and stuff, 
there's the ucPanel.ctl approach - so one doesn't have to use a cWidgetForm as the only available GroundLayer for Widgets in VB6 - ucPanels can be used alternatively.

Though for VB7-proper I'd like to have (if we do such a thing as your proposed OCX-bridging) a small Helper-Dll, written in MS-VC++ (with some help from ATL,
which offers something similar as the VB6-Controls.Add-call with regards to easier siting-support for OCXes - so VC++ offers an easy way, to produce also a 64Bit-variant of such a helper).

So, if that OCX-topic is dear to you (even when still unfamiliar with VC++), something like that would be a worthwhile addition (when encapsulated in a Dll, 
which in its  first incarnation should play together and be tested with VB6 - just something which is able to "externalize" the VB6-Forms-Add-functionality - 
and is then usable independently from the VB6-runtime  by the VB7-compiled-binaries in both, 32Bit and 64Bit mode).

In case you never worked with VC++ - it's not all that "alien" - and "siting of an OCX per ATL" should be well-covered in online-articles and forums,
where one can take a look how it's done.

You will have a lot of time for that too, since I don't expect the compiler to produce something useful before at least 9-months or so are gone by.

Regards,

Olaf

----------


## Schmidt

> I've started contributing to the vbWidgets project on GitHub. While I use Git for my own projects, I'm the only developer which makes it easy to have my own "protocol" for submissions. I hope I've followed the proper protocol for your project, but please let me know if you would like things done differently.


No, all fine - thanks - will respond (and merge your first additions) soon.




> Regarding the controversy as to whether to support OCXs, it has become a polarizing issue.
> Do you see a path where the IDE can be developed to support a plugin extension that could offer some kind of OCX support (perhaps in a container widget that bubbles events up to the new form engine).


Yes - something like the "fast shot from the hip" Dominik came up with as a first proof of concept is always doable (sidewards - and later on) - 
And "making an OCX visible somewhere on a Form" (the "basic siting", so to say) is not *that* difficult to achieve - 
neither over a small external VB6-Dll - nor over an (ATL-based) C++-siting-Dll-wrapper.

The bigger problem is, to integrate those hWnd-based Controls with other Widgets on the same TopLevel-Form (layering-issues will happen because of Windowless vs hWNd-based) - 
and then we would need to support correct tabbing-integration - and finally (what you already hinted at) - a proper Event-integration into the WidgetForm-Event-Bubbling-mechanism.
That's all solvable of course (in one way or another) - but "a distraction" nonetheless in the early stages of the project - because we already have a fully working "UserControl-Engine"
(which is more powerful than the MS-one and should therefore be preferred).




> This would allow a second group of interested parties to spend effort developing OCX support, while the rest of the team that doesn't really care for it can ignore those efforts and work on the rest of the IDE.


Sure, I'm not hostile against such efforts - anything which broadens the user-base is a good thing in the end - and should be integrated when tests show, that it plays well with the existing engine...
I'm just trying to steer a straight course to platform-independence, which currently seems not that important to many VB6-Devs - but it will become so in a few years- I'm deeply convinced of that.
That's why I labeled the OCX-support (somewhat undeserved maybe) "a distraction" - (from the Widget-Engine)... you will not be able to "take OCXes with you", in case of a platform-switch.
The Widget-Engine (along with more and more well-written additions to the free available Widget-stack) should be the preferred kind of GUI-approach.




> This would also help to entice VB6 developers over who think they need OCX support, and introduce them to the new IDE and new features of framework. While they get comfortable with the new environment, over time they could migrate their apps completely off the OCXs and gain full cross platform, 64-bit, unicode, etc... functionality.


As said, if there's a group of interested Users who come up with a nicely sidewards-bindable OCX-Bridging-approach - we should integrate it into VB7 (even if I'm not a fan of OCXes <g>).

Regards,

Olaf

----------


## SuperDre

> I'd try to mimick the old IDE (maybe just introduce some nicer Icons) as far as possible (the non-SDI-version I mean).
> Olaf


i do hope the SDI version is also taken into account, as that's how I use the IDE, don't like the mdi. Also extensibillityis very important, the current vb6 ide has some nasty shortcomings,which are very noticable under windows 7 (using source safe 5).
We use MZ-tools for extending the ide, and our own addins (no i don't suggest the ide should be compatible with those, far from it, it's pretty crap, a lot of our add-in code consists of working around the crappy extensibility, not on actually the functionss themselves.)

One of the reasons why i would want my current vb6 projects to be able to just convert and continue in vb7 is due to some stupid limitations of the vb6 ide/project size. sadly there is some sort of limitation on the ammount of differently named variables in one project (yep, i'm hitting that limit, which results in 'out of memory' errors in the ide.. also one of the most annoying things of the ide/intellisense of vb6 is that it doesn't limit the name of a method/property/parameter/variable to the specified scope, but on the whole project, which is especuially annoying if you are using something like sourcesafe, for example take a property 'X' (uppercase X)on a class, but if you use an ocx or some default api declaration where a variable is called 'x' (lowercase x), the ide changes the name of the class property to 'x' or if you add the class after the api-declarating, it will change the parameter 'x' to 'X'... VERY ANNOYING, so i do hope something like that is fixed.
the reason i want everything in one project is due to not wanting to have to worry about dll-hell, that way i know the specified project always uses the versions of the controls it needs to have, and i don't have to worry about my ocx-es/dll's don't have to be s 'backwardcompatible'. so i hope the new ide will fix the limitations/annoyances..
Also the advantage of having 100% compatibility is you can immediatly start using new functionalities for new parts, and replace/upgrade older parts when needed...
I also mentioned sorcesafe for a moment, good sourcecontrol integration is also ver needed in the new ide..

ps. i still haven't had time to checkout the framework.

----------


## jpbro

> No, all fine - thanks - will respond (and merge your first additions) soon.


Great! No rush to merge of course, and criticism of my code is always welcome if it is not up to snuff. I just wanted to "fly the flag" a bit about contributing to the effort.




> Yes - something like the "fast shot from the hip" Dominik came up with as a first proof of concept is always doable (sidewards - and later on) - 
> And "making an OCX visible somewhere on a Form" (the "basic siting", so to say) is not *that* difficult to achieve - 
> neither over a small external VB6-Dll - nor over an (ATL-based) C++-siting-Dll-wrapper.
> The bigger problem is, to integrate those hWnd-based Controls with other Widgets on the same TopLevel-Form (layering-issues will happen because of Windowless vs hWNd-based)...


Frankly, I'm not too concerned about the details "today" because I think that if it is technically feasible, and can be done in such a way that it is not a major distraction to the core project (that is to say that another group of programmers who otherwise wouldn't want to get involved, but are willing to work on OCX compatibility without taking too much effort away from the core programming group), then why not?




> Sure, I'm not hostile against such efforts - anything which broadens the user-base is a good thing in the end


I agree.




> I'm just trying to steer a straight course to platform-independence, which currently seems not that important to many VB6-Devs - but it will become so in a few years- I'm deeply convinced of that.


I 100% agree that platform independence is a primary goal. I only see OCX support as a temporary bridge.

A personal anectode: I initially fought against legacy support when developing the latest version of our software, even though my boss thought that it was critical. I fought because it was going to be a lot of painful work to understand some ancient proprietary binary formats (circa 1993, for which there was no documentation), and to deal with non-normalized Access databases that didn't even store the data needed to be used with some of the new features of the software. At first I "won", but over time it was evident that many of our "old" customers needed to see something that they were familiar with in the new program to really understand the fundamental shifts in the approach that we were taking with the new version. So in that sense, I was wrong, and I eventually took the time to create a migration path for them. When new features were impossible to use (because the data didn't exist from the legacy software for example), then it at least gave the users an understanding of what they were gaining by starting from scratch with the new program. Because of this experience, I think that OCX support (or at least the ability for interested developers to easily integrate some kind of OCX support in "VB7") would be useful.




> The Widget-Engine (along with more and more well-written additions to the free available Widget-stack) should be the preferred kind of GUI-approach.


I agree.




> As said, if there's a group of interested Users who come up with a nicely sidewards-bindable OCX-Bridging-approach - we should integrate it into VB7 (even if I'm not a fan of OCXes <g>).


I agree, for reasons stated above. I think the only concern of the core IDE dev team regarding OCX support should be that it is relatively easy for an OCX-compatibility dev team to integrate their work into the main project (what I don't know is how this will be done - I would prefer an extension/plugin framework, as opposed to a different build of the IDE.)

----------


## jpbro

@SuperDre & Olaf

Maybe a new thread should be started to discuss the complaints about the old IDE and what features we would all like in the new IDE?

----------


## Schmidt

> @SuperDre & Olaf
> 
> Maybe a new thread should be started to discuss the complaints about the old IDE and what features we would all like in the new IDE?


I'd find that not necessary at the moment - in my initial GIT-Repo-Opener-Step (just give me a few more weeks, to bundle something up), 
I will upload a wireframed and widgetbased-Version, which in its "Panel-Areas" tries to mimic the current VB6-MDI-version (most of the PanelAreas still empty, 
only filled with mockups or stubs). Also the Menu-Stripes and ToolBar-Stripes I will only provide with the first entries - and the modal-dialogues
I will replace with a generic "Todo-MessageBox".

From that Wireframe it should be easier then, to "spread the work-load" without causing team-efforts to overlap.

I'd like it when we could use *this* Forum here for the rough overview, where the project currently is, reflecting the current
state in a kind of "still open, ...already worked on by PersonX, ...already finished"-List where developers can "check themselves in" 
for a certain Todo-task, to fill the "still blank spots" in the wireframe-model - and make it clear for others, who's currently working on what - 
which are the Todo-Tasks which are still "open" - and what tasks are already done ... 

Maybe *that* should then go into a new, separate Todo-Thread, where the initial post is used to reflect the current state.

Basically I'd like to treat the GUI in the same way as the initial requirement for *.bas and *.cls compatibility - let's discuss enhanced features
(much) later - first let's try to come up with something which resembles the original as closely as possible - only if there are 
"cheap and obvious enhancements possible already in the first throw"- then of course let's apply them - but those topics will
then come up along the way in the GIT-repo-Pull-Requests - and we could discuss implementation-details there then.

Edit: Forgot to comment on the SDI-capabilities of the old VB6-IDE - and how to achieve that in the VB7-IDE...

This feature would (if there's enough contributors who'd be willing to approach this) not that difficult to implement, 
since in the new Form-engine (which offers the hosting-areas for the new Widget-Framework) there's no difference between 
"Client-Panels" or "TopLevel-Forms" -  both are of type cWidgetForm.

So, Code (and Widgets) on a certain Panel (interacting with such a cWidgetForm-Base),  which in the first throw will be implemented as Docking-Areas - 
can later on easily be hosted also in a TopLevel-cWidgetForm-instance (ToolWindows etc.), by just switching the instantiation-line of the cWidgetForm-variable - 
so SDI-mode will not be a real problem if that is wanted - but it can be achieved later on, without "wreaking havoc" in the original CodeBase - and so I'd like to 
delay this step until we came clear with the MDI-version initially (which I think is the mode, the VB6-IDE is currently used by most Devs).


Olaf

----------


## vbrad

Most of the discussion here has been above my head but I am really excited by this project.
I'd be happy to help out if there was work within my capabilities available though.

----------


## SuperDre

> Edit: Forgot to comment on the SDI-capabilities of the old VB6-IDE - and how to achieve that in the VB7-IDE...
> 
> This feature would (if there's enough contributors who'd be willing to approach this) not that difficult to implement, 
> since in the new Form-engine (which offers the hosting-areas for the new Widget-Framework) there's no difference between 
> "Client-Panels" or "TopLevel-Forms" -  both are of type cWidgetForm.
> 
> So, Code (and Widgets) on a certain Panel (interacting with such a cWidgetForm-Base),  which in the first throw will be implemented as Docking-Areas - 
> can later on easily be hosted also in a TopLevel-cWidgetForm-instance (ToolWindows etc.), by just switching the instantiation-line of the cWidgetForm-variable - 
> so SDI-mode will not be a real problem if that is wanted - but it can be achieved later on, without "wreaking havoc" in the original CodeBase - and so I'd like to 
> delay this step until we came clear with the MDI-version initially (which I think is the mode, the VB6-IDE is currently used by most Devs).


But implementing it from the start makes sure you won't have any problems later on.. Also with modern MDI you can just drag a window out of the MDI-parent (at least in VS.NET) so in some way you do have SDI.. 
But personally I'm not that fond on MDI, the only thing I like about MDI is the fact if you maximize a child-window it will position itself within the MDI-clientarea, but we 'fixed' that for SDI in our add-in so you can 'one of the options of our addin we created is that a code window will position itself under the VB6-main-toolbar and is limited to the project-window (or whatever you want).. It works a bit like the old Delphi IDE (and it's best addon G-Expert).

But are 'you' gonna use the vb6 IDE as the example IDE or are 'you' also looking at other IDE's?

----------


## Fatina

Please read this: http://www.codeproject.com/Articles/...rful-than-ever  :Thumb: 





> *Introduction:*
> Its been many years since MS dropped support for VB6, yet people continue to use it to this very day. Many users have switched over to VB.Net due to how powerful it is, and the fact that its truly object oriented. But some find the runtime too large, and their apps are too dependent on the .NET Framework. The on going battle between VB6 lovers and VB.Net nuts must come to an end. Its time we developers unite to create the ultimate VB language that's fast and easy to use. A language that is extremely RAD (Rapid Application Development). Its time for VB Classic.
> 
> *Why VB Classic?*
> VB Classic if done right will be the solution to every VB developers problems. People as well as businesses continue to use VB6 for a reason. Either its too expensive and time consuming to switch to VB.Net and port all that code, or some people find VB6 easier to code for than VB.Net. Some people also find VB.Net lingering away from the BASIC syntax that we all once recognized. But people use VB.Net for a reason too. Its powerful, the latest technology, and actually object oriented. Some find VB.Net easier to code for than VB6. But what draws you in to stick with your favorite VB language regardless of version you use? What do you not like about it? If we all iron out the flaws of VB, we can create an improved VB language, and make it easy to migrate to from both sides of the fence without overwhelming you with a completely new syntax. A lot of people find both languages have very slow functions they would like to see execute faster for example. VB Classic will have very familiar commands execute as fast as humanly as possible so you will have no worries of slowdown in time sensitive projects such as games!
> 
> *Can I be a part of the Team?*
> I will need a team of people to help me put this together. You can PM me or say you want in here in this thread, but you must be serious about joining. Before we even begin to jump into syntax, I would like help in putting together the IDE. Once we have an IDE to work with, then we can discuss syntax. The reason is because if we talk about syntax, we can go on and on until theres about 20 pages of a super thread going, but.... no IDE was made. I don't want to make the same mistake that happened with LightFusion, and its a must that progress must be made. The IDE will be designed in C++ starting with the basic window, the menu items, and the code window within the window. As we progress, then we can add special things such as a toolbox and such. The IDE is a must before a syntax can be formed. 
> 
> ...

----------


## Fatina

Do not be silent, be aggressive !


Defend, defend, defend ! together we will succeed!


New (2014) sources and articles on "bring back VB6":

http://www.codeproject.com/Articles/...rful-than-ever

https://www.facebook.com/MicrosoftVB 

http://www.xyplorer.com/xyfc/viewtop...=10978&start=0

http://www.i-programmer.info/profess...d-by-many.html

http://www.dreamincode.net/forums/to...for-vb6-again/

http://www.itwriting.com/frozenvb6.php


New (2014) petitions and motions for VB6:

http://www.change.org/petitions/micr...pilation#share

http://www.planetsourcecode.com/vb/s...75150&lngWId=1

http://www.planetsourcecode.com/vb/s...75121&lngWId=1


Vote for VB6 on the question "What is the best programming language in the world ?":

http://www.theranking.com/what-is-th...e-world_r55229

http://www.theranking.com/what-is-th...ge-ever_r43672

http://www.theranking.com/best-progr...e-world_r36102


Do not be silent, be aggressive !

----------


## mjohnlq

Here has vb.net's compiler source code:
in the sub dir DotNetReferenceSource.zip\Source\vb of the below package
http://referencesource-beta.microsoft.com/download.html

----------


## Fatina

> Here has vb.net's compiler source code:
> in the sub dir DotNetReferenceSource.zip\Source\vb of the below package
> http://referencesource-beta.microsoft.com/download.html


 :Smilie:  is this legal ? hmmmmm VB .NET compiler source code  :Smilie: 

VB6 compiler source codes ?  :Smilie:

----------


## mjohnlq

> is this legal ? hmmmmm VB .NET compiler source code 
> 
> VB6 compiler source codes ?


vb.net compiler source is open source by microsoft, so i think it is legal.
but vb6 compiler source code is not open sourced by microsoft.

----------


## Fatina

> vb.net compiler source is open source by microsoft, so i think it is legal.
> but vb6 compiler source code is not open sourced by microsoft.


Visual Basic 6.0 it is not open source because is too important, true ! thanks for the link, I did not know that VB .NET is open source

----------


## mjohnlq

> Visual Basic 6.0 it is not open source because is too important, true ! thanks for the link, I did not know that VB .NET is open source


you  are welcome. 
I just know it today too. from this link: 
http://visualstudio.uservoice.com/fo...t-framework-so

----------


## Schmidt

> is this legal ? hmmmmm VB .NET compiler source code


VB.NET-compiler source (non-MS) is out there for years under Mono, written and maintained
by Rolf Bjarne Kvinge... 

In either case (although I'd think that the Mono-license is a bit more liberal than the MS-
conditions which come with their source), I'd suggest not to look at it (in depth), and 
definitely not to copy portions from it, just to be on the safe side.

Olaf

----------


## Fatina

> In either case (although I'd think that the Mono-license is a bit more liberal than the MS-
> conditions which come with their source), I'd suggest not to look at it (in depth), and 
> definitely not to copy portions from it, just to be on the safe side.
> 
> Olaf


true  :Smilie:

----------


## yereverluvinuncleber

Just to let you know my position, I would definitely contribute toward a kickstarter-like project for a more up-to-date VB6 IDE that was able to be language-aware with language specific functionality being enabled/disabled via configuration/plugins. Personally, I'd like a new IDE to be as much like the old VB6 IDE as possible. That is what made me productive and I'd like it to continue. Jabaco came up with a pretty good first stab at a VB6 IDE look/act-alike but that project is dead in the water. I think a new non Microsoft IDE is an achievable objective that would be just the first step to reinvigorating VB6 and jumping off point for VB7.

For VB7 to succeed it simply needs to do one thing - compile and run our programs. 

Any new functionality needs to be in addition to supporting the old. Once again, I would be willing to contribute to a kickstarter-like project that would create a VB7 compiler on windows. Initially, if it was only for windows I would be happy but  if later compilers could create code for Android that would complete the picture. Each compiled could be a separate kickstarter project. 

The only VB7 enhancement that I see that would drive me to wanting it 'desperately' is better handling of transparencies to allow transparent/semi-opaque images behind controls/backgrounds &c. This would allow shaped applications like these:

----------


## Schmidt

> The only VB7 enhancement that I see that would drive me to wanting it 'desperately' is better handling of transparencies to allow transparent/semi-opaque images behind controls/backgrounds &c. This would allow shaped applications like these:


You can already achieve everything I see on your screenshot with the vbRichClient-framework (a free set of 3 Dlls for VBClassic).
With ease, since it supports not only vector-based, antialiased Drawing (as well as all kind of alpha-channel-Bitmaps and Icons - gaussian blurring etc.), but also a new Form- and UserControl-engine (in the context of the Framework I call those new UCs "Widgets" - they can be developed quite similar to normal VB-Usercontrols, but in addition come with an Alpha-Transparency- as well as a .Moveable property, MouseWheel-Events, MouseIn/Out etc... the Framework is Unicode-capable throughout).

Just install the "BaseDlls" first: 
http://vbrichclient.com/#/en/Downloads.htm
(and read what's stated below the Download-link with regards to registry-entries).

And then check out the well-commented Tutorials/Demos, in the order they are listed on this page:
http://vbrichclient.com/#/en/Demos/GUI/
- CairoDrawing
- FormEngine
- WidgetEngine

Each of the above contains a list of Folders, ordered from "easy" to "advanced" - 
each Folder is self-contained (not dependend on the Source-files in other Folders).

Olaf

----------


## yereverluvinuncleber

I thank you for that information and I will certainly have a look at those references you have provided. 

I have already created these using javascript and XML as genuine desktop widgets using the Yahoo widget engine, the IDE was Photoshop for the graphics and Context Editor for the code using a conversion script to convert the PS layers to an XML description.

I might have used VB6 if the future for VB6 had been perceived, at the time, as being more secure. However, even the Yahoo widget engine has been abandoned and so I am now looking for a new development platform. Considering Xwidget engine (Windows/Android) and/or QT (most of them)

This is another that I have created as a widget so you can see the sort of thing I now knock up:


Regardless of whether I could fulfil my current needs with VB6 I'd still support an open source multi-language VB6-like IDE and I'd contribute toward a VB7 in one way or another.

----------


## Schmidt

Nice graphics (and graphics skills)... 

As for good-looking, *.png-based and antialiased "AnalogueClock-KnockUps"  :Wink:  
(though still kept simple, without the Date-Visualizings and Moon-phases) - 
this vbRichClient-based Widget-Demo is perhaps interesting to you as well:

http://www.vbforums.com/showthread.p...-ClockHands%29

Aside from the rich graphics-capabilities which offer anything you're perhaps wont also from the other engines (including SVG as well) - 
the framework also integrates a physics-engine (a chipmunk-binding behind easier to use COM-classes), so that
you could design physically correct behaving mechanics too... (a motor, all kinds of "joints" and springs ... it's all there).

As for VB7 (and a new IDE which is based on the new Widget-Engine) - currently have not that much time as I'd like - 
though the project is still on my todo-list... will post here, when I have something to show and make the next move with that...

Olaf

----------


## yereverluvinuncleber

> Nice graphics (and graphics skills)...


Complement appreciated... Having just read the description on your site and seeing what you have already done and what you intend to do, I am more than impressed by your programming skills. My graphic skills certainly exceed my programming skills (I am really no more than a scripter with initiative).

Time is what none of us have but if it encourages you, I am really impressed that someone is delivering the components that you are producing. These were needed a long while ago...

My apologies for showing more of my stuff but as you seem to like it...

----------


## yereverluvinuncleber

Looking at your rather attractive clock widgets - I'm going to have to reconsider VB for widget-making.

FYI - my javascript widgets are here: http://lightquick.co.uk/steampunk-wi...tml?Itemid=264

Don't have high expectations of my code but the widgets do work mostly. The widgets are zipped in a .WIDGET file, there is a converter on the download page that makes it easier to unzip the widgets. Feel free to convert if you want.

----------


## yereverluvinuncleber

Chaps. One thing that might help with any possibility that MS might break the platform and remove something like OCX capability - ReactOS. I have some high hopes for ReactOS, an open source re-engineered version of widnows (sic) which is similar in concept to what you are thinking of doing with a new VB7. ReactOS is based upon the functionality of NT 5.2 and is already bootable/runnable in alpha and will be going to beta probably on the next release.

If it is successful, ie. it goes beta then live and it appears usable, then it should provide a platform for the future for all VB6/VB7 apps in that it will not break backward compatibility just for the sake of Microsoft doing so.

I think that any developers of a future VB7 should have a stake in what the ReactOS boys are doing as I reckon it could be a partnership made, well, not quite in heaven, but close.

https://www.reactos.org/



Don't expect it to install/run VB6 yet - it isn't quite there yet. It runs lots of app.s but the memory management is still flaky, the explorer and task manager are being re-engineered now and a lot of what is there is in place because they needed something to just 'work'.

----------


## yereverluvinuncleber

Interesting thought that when you distribute your VB6 app you could bundle an o/s with it too, almost like a runtime library...  :Wink:

----------


## Schmidt

I'm following ReactOS for a long time now, it started out well, but progress is really slow in the meantime
(they're still not yet at the point of true "Windows-Driver-compatibility" - which could give a boost when
that'd be ready).

In UserLand (atop the kernel- and driver-layer) they are using SourceCode from the Wine-Project.





> Interesting thought that when you distribute your VB6 app you could bundle an o/s with it too, almost like a runtime library...


Have already validated this approach about  1.5 years ago (with a tinycore-linux,
which comes in a ~12MB-package, including a modern kernel and a Desktop-GUI). 
http://www.tinycorelinux.net/

Linux+Wine is still the (much) more stable approach, compared with ReactOS.

After installing the Wine-package from the TinyCore-Repository, followed by an
install of the VB6-runtime-Files - VB6-apps were able to work on that system.

Size as a VMWare-package/disk (including the quite large Wine-Layer-libs) was about 45MB  
or so (7z-compressed about 30MB) - so, yeah - a complete, modern OS, able to run VB6-apps
on top, was thus smaller than e.g. an update-package for the 4.xxx .NET-runtimes ...  :Wink: 

But resorting to that kind of thing (shipping VB6-Desktop-Apps as a VM) will not
be required IMO for a long time to come - Win9 will support VB6 and COM definitely
further - there's just too many Apps in all the Offices around the globe (even a whole 
lot of .NET-based ones) which cannot function without Win32 and/or COM.

Olaf

----------


## yereverluvinuncleber

> Size as a VMWare-package/disk (including the quite large Wine-Layer-libs) was about 45MB  
> or so (7z-compressed about 30MB) - so, yeah - a complete, modern OS, able to run VB6-apps
> on top, was thus smaller than e.g. an update-package for the 4.xxx .NET-runtimes ...


That is a great approach and I'll consider that for the future too! I'd also like to get my yahoo widgets running under wine but the engine does not work due to some missing graphic functionality. 

I have seen ReactOS firm up a little with the last release but you are quite right it seems to make slow progress - it is a momentous task to attempt. Hoping that when it turns to a beta release the momentum will start to be generated. I feel that ReactOS is a hard project to contribute towards due to the nature of the developers, they don't always seem a communicative bunch though this has also improved recently.

----------


## axisdj

Hello Everyone,

As most of you know I have been driving hard to promote the vote to MS to bring back VB6. I actually had a conversation with someone at MS a week ago, and although he is lead guy of another team not associated with vb, he kept stating that bringing the product back is highly unlikely because most modern development needs more... So funny. After the phone conversation I asked him to give me a list of things that would help my app if I re-wrote it .net. I have yet to hear from him. I think I would be stupid to actually move to .net, again trusting a company that deserves no trust.

I have also talked via forum to the people at xerocoder.com and suggested they create a convertor for vb6 code to import to their platform. They feel that they could create a convertor that can convert up to 95% of vb6 code. They use a macro system that allows you to create language keywords to convert what they have to vb6 syntax, pretty neat. I hope they decide to go for it.

Schmidt is a true genius and I wish there was a way to give him the funds he needs to get the project done, although I REALLY do agree with yereverluvinuncleber that a vb6 replacement must be able to compile a vb6 app as they run today. The way I see it that, and that alone will have vb6 devs all over the world run to its adoption. I know that may hinder the fact that it will be cross platform and win32 dependent, but those things can be much easily re-factored if a compile from current vb6 code can be achieved, all extra effort can then be focused on cross platform and removal of win32 dependencies. 

I am really crossing my fingers that one of these four things happens this year
/ MS brings back vb6 
/ xerocoder implements a true vb6 import
/ Schmidt  finds time and money to complete his project
/ or anything comes to market as a true vb6 replacement.

That's my 2 dollars and 50 cents!
Good Day!

----------


## Fatina

Hello Everyone,

I am disgusted by the banning of Megan Winter's account on social.msdn.microsoft.com. She came with valid points for Visual Basic 6.0, too valid! And what the administrator/power user does on a MICROSOFT site?! He (the power user) erased all 60-70 valid comments (on "Bring back Visual Basic 6.0 ! We all need it." issue) and banned the acount due to his inability to cope with the conversation! This guy is a disgrace for Microsoft! The admin that banned a perfect valid user like Megan Winter should not have access to that site ! The name of this power user is Cor Ligthert. Please comment there: http://social.msdn.microsoft.com/For...orum=vbgeneral

Folks, what happened to Megan Winter is NOT ok !


PS: yes, but it will not be the same. I also agree that a vb6 replacement must be able to compile a vb6 app as they run today (and this is the most important thing!). These points are important: http://vb6awards.blogspot.ro/2014/02...-basic-60.html

----------


## Schmidt

Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.

And he's not at all good at the kind of "marketeering" he did then and there (although it's  
much better than trying to talk with him about programming-topics, been there - done that).

Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
partly because of his bad english skills)  :Wink:  
So, in short: you can as well have a nice conversation with a brick-wall - at least the responses 
you'll get then, will be consistent and non-contradictory.

Just forget about it.


Olaf

----------


## Fatina

> Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.
> 
> And he's not at all good at the kind of "marketeering" he did then and there (although it's  
> much better than trying to talk with him about programming-topics, been there - done that).
> 
> Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
> partly because of his bad english skills)  
> So, in short: you can as well have a nice conversation with a brick-wall - at least the responses 
> you'll get then, will be consistent and non-contradictory.
> ...


So true Olaf, you're right!  :Smilie:

----------


## yogiyang

As the project is still on drawing board I would suggest to have look as a similar compiler B++. It is on sourceforge web site.

It seems to be abounded but it can be a starting point for this new project. It is basically an emitter which will generate C++ code in back end and compile it with either MingW or BorlandC++ (free compiler).




> http://sourceforge.net/projects/b-pl...urce=directory


While we are at it. 

I would like to know if it would possible to use LLVM for targeting multiple OSs?

HTH

Yogi Yang

----------


## yereverluvinuncleber

> / Schmidt  finds time and money to complete his project


If Olaf felt like setting up a kickstarter to fund the first stage of the project we could use it gauge the actual level of support. It would need a site and some publicity though.  Not pushing you toward this - just stating that I feel that it is a valid direction to go in if you needed something to push you to complete the work you have already started.

----------


## Schmidt

> As the project is still on drawing board I would suggest to have look as a similar compiler B++. It is on sourceforge web site.
> 
> It seems to be abounded but it can be a starting point for this new project. It is basically an emitter which will generate C++ code in back end and compile it with either MingW or BorlandC++ (free compiler).


In my plan to accomplish platform-independence (as well as 64Bit-support),
I wanted to incorporate a "plain C"-emitter. That's mainly because I see
the (InProcess working) tinycc-compiler-library playing the main-role in a 
PCode-like engine, which is working behind the scenes within the new IDE 
(to allow for easy debugging, and Edit&Continue).

The "real compilation" would then allow to target either MingW for faster 
and optimized "native-compiled binaries" - but alternatively also the tinycc again,
which allows for slower executing, but smaller "PCode-like" binaries then.

So the new IDE will have (as before) two different compilers - a very fast compiling 
one (tinycc, about factor 10 faster than GCC), and MingW which has not the same 
throughput in "processed lines of C-Code per second" as the tinyCC, but will end 
up with higher-optimized, faster executing binaries.

Neither tinycc nor MingW-dependencies will be required to "ship" with 
your compiled binaries finally - but I assume this is clear.




> While we are at it. 
> 
> I would like to know if it would possible to use LLVM for targeting multiple OSs?


It is certainly possible - mjohnlq already suggested that here in this thread - and there's
also already the beginning of an LLVM-based compiler as mentioned in the posting here:
http://www.vbforums.com/showthread.p...=1#post4492531

So, it is doable - but at the moment I'd like to stick with my plan for a plain-C emitter 
(the same emitted sources usable by both, the tinycc-engine as well as the MingW-C-compiler).
Since this would mean a very lean deployment of the new IDE-project (when in the first
implementations only the tinycc is acting as the compiler for both: IDE-Debug-runs as well
as final Binary-compilation).

The MingW-compiler (which has quite a large deployment-size > 10MB) could be installed as 
an optional engine (to be shelled from within the IDE whereas tinycc supports both - a nearly
GCC-compatible commandline-interface - but also the already mentioned libtcc.dll).

tinycc is really impressive and comes since release 0.9.26 in both, a 64Bit- and a 32Bit-version 
(able to compile the appropriate 32bit or 64bit binaries also for windows). Deployment-size -
about factor 30! smaller than MingW (only about 386KByte).

For those who want to play around with the little engine - here's the main-page:
http://bellard.org/tcc/ 

And here the Download-page (version 0.9.26 for Windows is what you want).
http://download.savannah.gnu.org/releases/tinycc/


Olaf

----------


## yogiyang

> In my plan to accomplish platform-independence (as well as 64Bit-support),
> I wanted to incorporate a "plain C"-emitter. That's mainly because I see
> the (InProcess working) tinycc-compiler-library playing the main-role in a 
> PCode-like engine, which is working behind the scenes within the new IDE 
> (to allow for easy debugging, and Edit&Continue).


This would mean that we will not be able to debug code interactively like is currently possible in VB6.

Would it be possible to implement an interpreter and well as code emitter?

Say if possible adopt Gold Parser (again this project is 100% in VB) to interpreting and related stuff. (http://goldparser.org/)

Just my thoughts.

----------


## Schmidt

> This would mean that we will not be able to debug code interactively like is currently possible in VB6.


Quite the opposite - the tinycc-Compiler will *allow* (due to its InProcess-availability as a Dll and its superfast compile-speed) fast Upstart-Times and a "true Interpreter-like debugging" (as well as Edit&Continue), all due to the ability of the tinyCC-dll, to add new compiled functions "on the fly" into an "already running scenario".

Just imagine the emitted C-Code as something like .NETs "intermediate code" - and the tinycc-Dll as a kind of "VM".





> Would it be possible to implement an interpreter and well as code emitter?


The very same "emitted C-Code" will feed both - the Debugging-Process (then with the tinycc-dll as the C-Code-to-Binary-translator) - and in a true "binary-compile-run", the same C-Code gets translated into Windows PE-format (Exes or Dlls) by either the commandline-version of the tinyCC or the MingW-C-Compiler.




> Say if possible adopt Gold Parser (again this project is 100% in VB) to interpreting and related stuff. (http://goldparser.org/)


I know the page and the tool - but it's not needed.
A dedicated (handwritten) Parser is to about 90% complete (and speed-optimized) already.


Olaf

----------


## yogiyang

> Quite the opposite - the tinycc-Compiler will *allow* (due to its InProcess-availability as a Dll and its superfast compile-speed) fast Upstart-Times and a "true Interpreter-like debugging" (as well as Edit&Continue), all due to the ability of the tinyCC-dll, to add new compiled functions "on the fly" into an "already running scenario".
> 
> Just imagine the emitted C-Code as something like .NETs "intermediate code" - and the tinycc-Dll as a kind of "VM".


But the debugging part will be in C language and not in Basic language right?

The possibilities of having TinyCC as a dll and using it is really great concept!

Just curious...
Will TinyCC be able to compile and run new unsaved project directly from memory as is currently possible in case VB6?

----------


## Schmidt

> But the debugging part will be in C language and not in Basic language right?


The problem that (after Binary-compilation) one can only attach normal Debuggers
(which in case of the GCC-Debugger would report only the somewhat renamed 
C-Symbols then - and have no real relation anymore to the underlying line of
VB-Code, which produced a certain "C-Block"), is known.

But in VB we don't debug stuff in this fashion (with dedicated OutOfProcess-Debuggers)
... we do it directly in the same IDE-Process against "InMemory-VB(A)-PCode"...




> The possibilities of having TinyCC as a dll and using it is really great concept!
> 
> Just curious...
> Will TinyCC be able to compile and run new unsaved project directly from memory as is currently possible in case VB6?


Well, look at that here:  :Smilie: 



```
Private Enum tccOutPutType
  TCC_OUTPUT_MEMORY
  TCC_OUTPUT_EXE
  TCC_OUTPUT_DLL
  TCC_OUTPUT_OBJ
  TCC_OUTPUT_PREPROCESS
End Enum
```

So the latter one is True - and will be the base for a real "InIDE-Debugging" as we are
wont to - I can exchange Symbols and add (newly compiled) functions into a given 
TCC-InMemory-State (whilst being in an IDE-DebugSession).

That, paired with a self-implemented Stack-Area-allocation will ensure "Interpreter-
like flexibility" - but will run faster than VBs current PCode.

I've compiled a VB-friendly stdcall-variant of the tcc-lib and (next few days) will 
post a CodeBank- example for InMem-usage of this "Mini-VM" from within VB (at the 
moment only acting as a kind of "C-Scripting-language" from within a VB-application then).

Olaf

----------


## yogiyang

> I've compiled a VB-friendly stdcall-variant of the tcc-lib and (next few days) will 
> post a CodeBank- example for InMem-usage of this "Mini-VM" from within VB (at the 
> moment only acting as a kind of "C-Scripting-language" from within a VB-application then).


Wow that would be great! You are at it again!

Please don't get me wrong. But personally I have observed that we VB6 developers have been spoiled by VB6 IDE and are used to, you know setting a breakpoint and then running the code and when the IDE halts at the breakpoint we can manipulate/check values of variables, skip execution of a code lines, add new code lines, etc.

Lack of such interactive debugging feature will probably put off a conventional VB6 developer from adopting this new alternative.

Yogi Yang

----------


## sten2005

> Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.
> 
> And he's not at all good at the kind of "marketeering" he did then and there (although it's  
> much better than trying to talk with him about programming-topics, been there - done that).
> 
> Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
> partly because of his bad english skills)  
> So, in short: you can as well have a nice conversation with a brick-wall - at least the responses 
> you'll get then, will be consistent and non-contradictory.
> ...


Megan has now been 'Unbanned'





> Visual Studio team (Product Team, Microsoft) commented  ·  March 06, 2014 18:59  ·   Flag as inappropriate
> @MeganWinter, we looked into why you were banned on Forums and you should not have been. We have unbanned you and will further investigate internally as to why this ban took place. We are tremendously sorry and apologize for any inconvenience in which this has caused.


http://visualstudio.uservoice.com/fo...improved-versi

----------


## yereverluvinuncleber

Do you know I am quite astonished by the "head of steam" that seems to have been generated recently behind vb6 and by its loyal users. It seems that people (even windows users) are realising that the "Microsoft way" is not the only way and that there are actually other ways of doing things. I've been keeping my eyes open for a long while now and the "driving wind" behind alternatives is greater than it has ever been. Microsoft doesn't seem to be aware of it or perhaps it is blind to the outside world. Reversion to VB6 as a potential development platform for the future is one thing that I see emerging from Microsoft's Windows 8 car crash.

I reckon that if there is a chance for a VB6 alternative and a compatible and familiar IDE, then the time for it is has arrived or is arriving. There seems to be a lot of disillusionment from users with Microsoft's new NT6 GUI and also from Developers across the board regardless of which Microsoft technology they are familiar with. People are still loathe to drop the Windows environment they are familiar and productive with - but no longer expect Microsoft to provide it.

----------


## Schmidt

Very well put, all of the above - and as for the "Steam" - I think the recent initiaitves coincide 
with Steve Ballmers resignation (roughly from the time of its announcement) - but were 
perhaps encouraged also due to MS's-backpaddling to the COM-environment, which is now 
(again) the technical base for all those "new, clean and tiled" (ARM-capable) WinRT-developments.

Best tool for the WinRT-job? -> C++, using those new COM-interfaces in an unmanaged way.
So why not re-incarnate the classic C++/COM companion (VBClassic) again?

I think the above two reasons are the driving force behind these latest efforts of the VBClassic-
community - if there ever was a (slight) chance for a kind of resurrection - then now is the time
to make oneself heard, to possibly make it into the "my-strategic-decisions-to-make"-list of the 
new CEO - there was always "strong forces behind VBA" (in the MS-Office-Group) which in the 
meantime are perhaps aware again, that "VBAs big brother" wants to get back on board.

I personally see the chances for that as only 3-5% or so - but you never know - 
and even if those numbers are quite small, the chances now are a bit better than  they 
were e.g. 3 years ago.

Olaf

----------


## yereverluvinuncleber

What news? Is there any? A lack of information is always teasing... 

Any news about this project would be gratefully accepted.

----------


## yereverluvinuncleber

Not directly related to this thread but interesting nonetheless, getting VB5/6 working on ReactOS (windows clone).

https://www.reactos.org/forum/viewtopic.php?f=4&t=13090

I will be posting there shortly when I have more time to test VB6 on ReactOS myself.

----------


## yereverluvinuncleber

Olaf,

Have you made any progress on your idea for a true VB7? We would all support you in your efforts, all projects need a driving force with the capability to actually do it.

----------


## Elroy

Admittedly, I didn't read through every entry above, but I did read through quite a few of them.  This is a very interesting project, and it's something I've thought of myself, but there are a few problems here (possibly already discussed).  First and foremost, this is a monumental project.  It's certainly a bigger project than one or two people can carry off on their own.  For it to have any chance at all, it'd have to compile my existing code with a minimum of effort.  I thought I read that you were only going to do .bas and .cls modules.  However, if you get .cls modules going, you're 99% of the way to getting .frm modules going as well.  I can understand how .ctl modules may be a bit tricky, but you'd really need to get those going as well.  However, I don't even see that as the major complexity you'll have to deal with.  First and foremost, you'll need to be drop-dead compatible with the internal storage structure.  This includes all the intrinsic variable types as well as the variant, objects, and collections.  You'll have to handle both static and dynamic arrays.  That includes strings being handled in Unicode but converted to ANSI when calling an API, writing to PropertyBag, or writing to disk.  Arrays will have to be handled in precisely the same way too, as I have code that figures out whether a dynamic array is dimensioned or not withoiut error trapping.  And variable length string garbage collectors are a rough chore for ANY language.

Bottom line, it's a HUGE job.  I suppose you're doing it in some form of C with the hopes of going 64 bit.  The problem is, anyone who's quite fluent in C is not going to be highly motivated to help you.  Any chance you might have of getting this done would be to do it in VB6.  That way, the hoard of extant VB6 programmers might come running to help.  Yeah, you're boxing yourself in, but not that badly.  New features could still be added and a 32bit program can write 64bit op-codes just fine.  But it's just too big a job, and the existing VB6-IDE works just fine.  In fact, it works so well that that's the reason we're having this discussion in the first place.  Our only true hope is to try and pressure Microsoft to re-releasing VB6 (possibly with an upgrade) Here's a comment I posted elsewhere:

I've posted a list of recommendations for a VB7-COM product in many places through the years (64bit, easier unicode support, a Double-Long type variable, new Block/EndBlock keywords to reduce variable scope, ability to wrap OCX dependencies into the EXE along with manifest, and a few others).  But I'd actually be happy with just a re-release of the VB6-IDE.  Heck, they can put an "as is, no support" disclaimer on it if they like.  Not only do they discontinue the product, but they've done everything in their power to kill backwards compatible licensing, declaring that a copy of .NET does not satisfy the VB6-IDE licensing requirements.  It's as if publishers quit publishing the Harry Potter books (adamantly refusing to print more copies), but declared that they'd aggressively sue anyone who tried to make their own copies.  I'm not talking about open-sourcing it, supporting it, or even providing any warranty of suitability for anything.  Just sell my clients copies of it.  I have several projects I've opened sourced in VB6 code and charge for consulting, adaptation, and customization.  My clients would like the VB6-IDE so they can go forward with their own development teams, but they have to pay $2000+ for occasional copies of the VB6-IDE that appear on eBay.  It's disrespectful, it's shameful, and it should be illegal.  Heck, in my opinion, Microsoft would have been MUCH better off if they'd incorporated the VB6-IDE into their Windows OS (harking back to the days of their BASIC-OS).  Imagine how addicted the world would be if they had a smart, easy-to-use programming language at their fingertips in Windows.  They'd have half the world using it, and also clamoring for their OS to be ported onto every new platform (Tablets, Phones, etc) so that people could quickly write their own little VB6 style applications.  Personally, I think that strategy could still work toward recovering their lost ground in the handheld markets if they would quit disrespecting the very people who have hung with them through thick and thin.

----------


## ScriptBASIC

Now that Linux isn't viewed as an enemy of Microsoft, you may want to give Gambas a look. (3.6.1 released today)

----------


## yogiyang

For those who may be interested there is another open source project called BCX that does just what is being planned here.

The compile it ready and in production since many years. The visual IDE similar to VB6 IDE is still missing though!

The official web site is: http://www.bcxbasic.com/

There is Yahoo Group here: https://groups.yahoo.com/neo/groups/BCX/info




> BCX was programmed entirely using BCX BASIC, making it a self-translating translator. And translating is FAST!   BCX translates its own source code, over 24,500 lines of code, in just 1.2 seconds on a P4 laptop running XP Pro.
> 
>   	BCX BASIC to C/C++ Translator by Kevin Diggins (c) 2012
> [Lines In: 24524] [Lines Out: 29246] [Statements: 22106] [Time: 1.22 sec's]
> BCX translated BC.BAS to BC.C For a C Compiler
> 
> The C/C++ source code produced by BCX is highly portable and has been
> successfully compiled using these seven popular C/C++ compilers:
> 
> ...


HTH

Yogi Yang

----------


## indika.online.lk

I am working on vb6 compiler that emit c++ that can generate object code using clang at the moment i am adding the namespace support to it after that i plan to add the class and inheritance stuff.currently it handles all vb native types (integer,long,string,byte,double,single and varient) and supports 
on error *** statements 
function definitions with optional byval ,byref ("optional byref" is not supported atm)
Arrays
Types
all conditional and loops statements
Generated code outputs line number information so source debuggin is possible
I intend to start an open source project once i get the compiler to be able to compile itself (for that i need to add the class support)
Thing that troubles me is that whether i should make a vb6 (COM)  compatible class or a c++ class . if its a vb6 compatible class it can be exported as class library in vb6 but that makes it impossible (to my knowledge) for this new *vb7* to support inheritance since COM only support interface inheritance.hope to add implementation inheritance (or multiple inheritance if i could figure out a way out of "The diamond problem"
Also i plan to add a garbage collector instead of reference counting for objects management
more coming soon. hope to see your involvement with the project once i host the project

----------


## Schmidt

How far along are you at the moment?

If currently you have something working which compiles and emits VB-procedure-Code only,
maybe it's not too late to switch to "plain C-Code-emitting"?

The reason I ask is, because I've done tests already, which show promising results with real 
"In-IDE-Edit&Continue-Debugging" (using the tinyC-Compiler as a kind of dynamically re-compilable
InIde-PCode-engine - but this nice and fast little compiler, which can compile directly into memory - 
only understands plain C-Code).

I'd see no problem to implement COM-compatible Classes using plain C - and also no problem with 
Inheritance using those C-implemented Classes.

You can send a regular E-Mail over my Forum-account to me, in case you have an interest in 
discussing these things - maybe we can join forces.

Olaf

----------


## indika.online.lk

I havent checked tiny cc but Cling seems promising in the edit and continue part http://root.cern.ch/drupal/content/cling (always exited about higgs boson :P) which undestands c++ 11 .

problem is, its the limitation of COM,COM classes cannot handle implementation inheritance

----------


## indika.online.lk

> How far along are you at the moment?


Most vb6 language constructs are done including Types, in the middle of adding class support, ( also need to verify on the actual c++ output )
In using Boost for handling higher level data structures like arrays and variants.

----------


## indika.online.lk

Compiler can handle this atm , (note that i intentionally added some syntax errors for error detection, its not a blind converter it verifies every statements down to each sub statement including types) 



```
Namespace System
	Namespace Core
		Public Function tFu_nction(Optional ByVal x as Long , _
		Optional ByVal y as Integer="fgfg", _
		Optional ByVal z as Long) as Integer 
			Dim xd As Integer, yc As Double, xu As Integer
			x = yc = 123
			Dim s As String
			x = "123" 
			s=444
			

			Exit Function

		End Function
	End Namespace
End Namespace
Public Type TestType
	var1 As Long
	var2 As String
	var3() As String
End Type

Public Type TestType2
	var1 As Long
	var2 As String
	var3() As TestType
End Type

Function Arraytest(g() As String) As String()
	On Error Resume Next
	Dim ff(1 to 9, 9 to 67) as String
	
	Dim MyStruct as TestType
	Dim MyStruct2 as TestType2
	
	MyStruct2.var2=MyStruct.var1
	
    ff(1, 9) = "its"
    ff(2, 55) = "working"
    Arraytest = ff
End Function

Function booltest() As Boolean

    Dim Arr(4, 4) As String
	Dim Arr2(1 to 9, 9 to 67) as String
    Dim s As String

    Dim ffft() As String
    ffft = Arraytest(Arr)

    s = Arr2(1, 9) '="its"
    s = Arr2(2, 55) '="working"


    Arr2(1, 9) = "***"
    Arr(4, 4) = "its my life"
    ReDim Preserve Arr(10, 67)

    s = Arr(4, 4)
    s = "12" + "99"

    s = Arr2(1, 9)

    booltest = 0
    Dim x As Long
    On Error Resume Next

    While x < 7
        x = x + 1

    Wend

    For x = 10 To 150 Step 10
        If x = 100 Then Exit For
    Next x

    Dim Y As Long
    factorial(x = 8)

    Do While x < 8
        x = x + 1
    Loop
    Do
        Y = x
        Exit Do
    Loop
    Do

    Loop Until x < 8



End Function

Function factorial(ByVal n As Long) As Long
    If (n <= 0) Then
        factorial = 1
    Else
        factorial = n * factorial(n - 1)
    End If  
End Function

Public Function ffftFunction(ByVal x as Long,Optional xg as Integer=0,Optional z as Long) AS String
    x = 5 + 7 * 8
    On Error GoTo LastLine
    x = System.Core.tFunction(7, xg, 0)
    ffftFunction = "hello world"
    On Error GoTo LastLine
    If x > 0 Then x = x + "dd"
    GoTo LastLine
LastLine:
911:
    Resume Next
End Function

Private Function fact()
    Dim TokPrec As Integer, ExprPrec As Double, xu As Integer
    If TokPrec <> ExprPrec Then
        fact = (System.Core.tFunction() = ".")
    ElseIf TokPrec <= ExprPrec Then

    Else
        fact = 0
    End If
    fact = 5 + 7 * 8
End Function
```

----------


## ScriptBASIC

Nice work!

Can you use the same label names within structures in the same program? (FUNCTION/SUB/MAIN)

You may want to have a peek at CERN ROOT as a development environment. (Interpretive C/C++) that uses *cling* for the compiler.

----------


## indika.online.lk

> Nice work!
> 
> Can you use the same label names within structures in the same program? (FUNCTION/SUB/MAIN)


Within in same function NO , why ?

----------


## ScriptBASIC

Not within the same function or sub but in the same program.  Sorry for the confusion.

----------


## Schmidt

> Most vb6 language constructs are done including Types, in the middle of adding class support, ( also need to verify on the actual c++ output )
> In using Boost for handling higher level data structures like arrays and variants.


I'd strongly suggest, that you use the original type-defs and structs which are used under 
 the covers of VB6 also (meaning the safearray and variant-structs here).
There's a lot of VB6-code out there which is accessing those structs at a lower level
(safearrays are accessed in VB e.g. for fast DIB-Handling - or fast String-Parsing - and 
Variant-structs are accessed in quite some scenarios in the same way - e.g. with an 
Offset of 8 Bytes, to reach the underlying Value or StrPtr or ArrPtr/ObjPtr which sits there.)

It's important to care about that in this early state, before (much) more things are packed 
onto this groundwork - not easy to introduce such breaking changes as "safearray-compatibility"
at a later time.

Also the String-Type should be compatible with BSTR (since a lot of VB-Code is expecting
such an allocation to have 4 Extra-Bytes "to the left of the StringPointer" which describe the
allocated length in Bytes. Also the trailing Double-ZeroBytes should be ensured on that String-Type.

As for COM only supporting interface-inheritance (and not implementation inheritance)...

With a compiler one can juggle and re-arrange the VTable-entries as needed - 
as well as defining extra-space in the Private-Vars-struct of the *inheriting* class
for the members of the Private-Vars-struct of the *inherited* Class.
That's how it could work at a lower level for the Compilers "own" generated classes.

In the simplest case - even with how VB6 actually works - we could accomplish 
inheritance, when the compiler in case of our current interface-inheritance-scheme
just ensures also the *implementation* of those interface-methods, by drawing an 
instance of the Class it inherited from - and delegating to the VTable-entries of that Class.

Expressed in VB-Code (all written by hand instead of a compiler-emitting-automatism):

If you define a BaseClass like this:

TypeName: cBaseClass



```
Public Sub SayHello()
  MsgBox "I'm a cBaseClass-instance"
End Sub

Public Function AddTwoLongs(L1 As Long, L2 As Long)
  AddTwoLongs = L1 + L2
End Sub
```

The above Class is not defining a "plain virtual interface" only, it also contains 
the implementation behind the methods already.

Now, another class which plans to inherit that interface *and* that base-implementation 
would be written this way in VB6:

TypeName: cDerivedClass



```
'***** inheritance-by-delegation follows ******
Implements cBaseClass 'defines the VTable-entries we need to implement in addition
Private cBaseClass As New cBaseClass 

Private Sub cBaseClass_SayHello()
  cBaseClass.SayHello
End Sub

Private Function cBaseClass_AddTwoLongs(L1 As Long, L2 As Long)
  cBaseClass_AddTwoLongs = cBaseClass.AddTwoLongs(L1, L2)
End Sub
'***** end of inheritance-by-delegation ******

'the cDerivedClass's own public Methods follow
Public Sub DoinMyOwnThang()
  '...
End Sub
```


So - to support inheritance the compiler would do the delegation-code to the BaseClass 
in above interface-signatures (the part within the asterisks) for us automatically by default.

As it is currently, a VB-developer is *enforced* to fill out any implemented (interface-inherited)
method-signature "by hand" (then in any single method being free, to either delegate to 
the BaseInstance - or to "override" and putting his own stuff into the method-stub, which 
can get quite straining when we talk about of 30 or more Public entries in the VTable,
although one planned to override only one or two members of the BaseClass).

So in the easiest case the compiler could be doing something like the above, 
which is neither hard to understand nor to accomplish (at the code-emitter-level).

Olaf

----------


## indika.online.lk

> It's important to care about that in this early state, before (much) more things are packed 
> onto this groundwork - not easy to introduce such breaking changes as "safearray-compatibility"
> at a later time.
> 
> Also the String-Type should be compatible with BSTR (since a lot of VB-Code is expecting
> such an allocation to have 4 Extra-Bytes "to the left of the StringPointer" which describe the
> allocated length in Bytes. Also the trailing Double-ZeroBytes should be ensured on that String-Type.


This is why the namespace support was added to the compiler from the beginning cos runtime can expose different implementations of String,Varient by using namespaces
say if you add 


```
using Classic.Types
```

 or


```
using Classic.Types.String
```

the compiler uses the vb6 implementation, and use the vb6 project loader to automatically add this to source files when it converts the vb6 prj to new version.



> As for COM only supporting interface-inheritance (and not implementation inheritance)...
> 
> With a compiler one can juggle and re-arrange the VTable-entries as needed - 
> as well as defining extra-space in the Private-Vars-struct of the *inheriting* class
> for the members of the Private-Vars-struct of the *inherited* Class.
> That's how it could work at a lower level for the Compilers "own" generated classes.
> 
> In the simplest case - even with how VB6 actually works - we could accomplish 
> inheritance, when the compiler in case of our current interface-inheritance-scheme
> ...


 This "Wrapping" is easy for single inheritance, but gets complected when handling multiple inheritance or polymorphism  
How about doing it this way

Only COM classes are needed when you need to expose them outside the project, so what if we set the default classes to be c++ classes and public exposed classes to inherit from a class that support COM

something like



```
Class ExposedClass Implements Classic.COM

End Class
```

again this modification of the source can be added automatically by the project loader by looking whether it is a public or private class.So its transparent to the user.

since C++ already has the groundwork for inheritance , polymorphism , why reinvent the wheel,
 thats one of the reason i choose c++ over c also to OOP to work propely we need runtime type infomation. for casting etc. so it get completed to implement it manually.

Olaf you are right we do need to talk about this now than later. so we can deduce the best implementation

ill post some c++ output of the compiler later on so i can be certain that im on the right track

----------


## indika.online.lk

Current compiler binary and vs2010 project of runtime can be seen at https://code.google.com/p/v7basic/
Runtime is really ugly atm, not to mention buggy , at this stage i only used it to check c++ code validity , but you can run it and single step the basic code  :big yellow: 
feel free to interrogate OpenBasic.exe by changing the test.bas
I didnt want to upload the boost library but i had to cos i modified some headers of boost multi_array.

----------


## yogiyang

I just ran into this framework for VB developers in C++ on sf.net.

Thought I will share it here it may be useful who knows.

http://ezbasic.sourceforge.net/index.php

HTH

Yogi Yang

----------


## rizalmartin

@Schmidt you may consider the Chameleon Basic as a guide on the new Visual Basic 6.0 compiler.

http://sourceforge.net/projects/chameleonbasic/

----------


## ScriptBASIC

> @Schmidt you may consider the Chameleon Basic as a guide on the new Visual Basic 6.0 compiler.


Thanks for the link! I gave it a try and was surprised how far along this BASIC to ASM compiler has come. I hope the author continues with its development.

----------


## ScriptBASIC

* Deleted *

----------


## Fatina

Source: ANIMATION of the Visual Basic 6.0 incandescent bulb (simple GIF images): http://vb6awards.blogspot.com/2014/1...nt-bulb_8.html

----------


## Fatina

http://3.bp.blogspot.com/-9yl6A-hE32...mation%2B3.gif

----------


## rizalmartin

Someone has successfully converted C code to VB6. What if doing the conversion in reverse. VB6 to C code then compile it. That behaviour is similar to Basic4Android. It uses VB.NET style syntax as frontend but java code at backend. Upon compilation, it transalates the VB.NET like code to java and compile it.

Because of that, then its possible to write a VB6 code, convert it to C++ code and compile it.

http://www.planetsourcecode.com/vb/s...12483&lngWId=1

----------


## SuperDre

> Someone has successfully converted C code to VB6. What if doing the conversion in reverse. VB6 to C code then compile it.
> Because of that, then its possible to write a VB6 code, convert it to C++ code and compile it.


It's already been tried on many previous incarnations, and all have stopped development (propably due to losing interest themselves).. You'll find some opensource versions already on github or some other public sites..

----------


## rizalmartin

Prove it SupreDre. Show the links please.

----------


## SuperDre

> Prove it SupreDre. Show the links please.


sigh.... take your pick:  http://basic.mindteq.com/ and be sure to check out the 'discontinued' section..... 
but hee, maybe you can use one of those which made their source available and continue the work yourself...

----------


## rizalmartin

> sigh.... take your pick:  http://basic.mindteq.com/ and be sure to check out the 'discontinued' section..... 
> but hee, maybe you can use one of those which made their source available and continue the work yourself...


Thank you for this link. This will help on developing a true VB7 compiler.

----------


## yogiyang

Hi SuperDre,

I think you need to check this one: http://www.bcxbasic.com/

It is alive and updated regularly.

HTH

----------


## germano.barbosa

How is vb7, have you made any progress?

Sorry to resurrect the topic

----------


## yereverluvinuncleber

This does not help much toward a VB7 but it may provide a new native home for VB6. I mentioned ReactOS in an earlier post but then it was truly in its infancy. 0.4.8 has just been released, it is still very much alpha-grade o/s that should only be run in a VM but it now installs and runs VB5, which you can see in the forum post here:

start=1125#p130485



Hopefully, we can test VB6 next and pray the result will be as positive. ReactOS being based upon Windows server 2003 will be a natural and familiar home for VB5/6 development and not being from Microsoft, forced obsolescence will not be part of the culture. ReactOS and VB6 are made for each other it is just a pity that ReactOS is written C, C++ and that you can't as easily contribute...

Long live VB6!

----------


## yereverluvinuncleber

Olaf, can I ask you to note this thread: http://www.vbforums.com/showthread.p...PIC-WIN-thread

It might be worthwhile giving it a go on some of your non-graphical projects.

----------


## dreammanor

Now that JavaScript is omnipotent. I'm thinking, whether it's possible to use JavaScript (Electron or Deno) to develop True VB7 transpiler and IDEs completely similar to VB6?

Note: 
The VB7 I'm talking about is a brand new scripting language similar to VB6. It can be used for desktop software development, as well as for the development of Web-Apps and Mobile-Apps.

----------


## dday9

I'm not as familiar with VB6 as I am with other languages, but something that I leverage (almost on a daily basis) are online compilers. This helps me when I need to test something simple or to brainstorm a feature.

Something to consider would be to write your own VB6 online compiler like dotnetfiddle.net as a first step. This would at least give you the capabilities to execute console applications in any environment.

----------


## IndicSoftware

> Note: 
> The VB7 I'm talking about is a brand new scripting language similar to VB6. It can be used for desktop software development, as well as for the development of Web-Apps and Mobile-Apps.


Wow that is great news. Currently we are using B4X (B4J and B4A) for developing cross platform application in BASIC. 

I personally love VB and if you will come out with VB7 I will gladly switch to it instantly!

Can you give any time frame of releases?

Regards,

----------


## SuperDre

> The VB7 I'm talking about is a brand new scripting language similar to VB6. It can be used for desktop software development, as well as for the development of Web-Apps and Mobile-Apps.


Not interested in yet another new scripting language, there are way too many already. One of the powers of VB6 was native compilation..
If you really want crossplatform etc. You're better of just using the widely used frameworks and languages like C#. Especially if you're a business, it's just plainly stupid to rely on a language that isn't supported by a large majority and having to rely on hoping the language you're using will continue to be developed and maintained.

A VB7 is only interesting if you can take a project of VB6 and load it and have it run with really minimal changes needed, like it was with VB5 to VB6 (not VB6 to VB.NET which was just completely incompatible with each other (and VB.NET is the reason we never saw the release of VB7, even though VB7 was feature ready when they decided to dump it and progress with VB.NET).

----------


## BN586

I read this thread numerous times during development, mostly to make sure no one else was successfully building a true Visual Basic 7 and to commiserate in the lack of a true Visual Basic 7.

Since I believe that the people who really care deserve to be the first to know ...

I'm giving you guys a few hours advance heads up on this before the rest of the world ...

C-Prime is all platforms "Visual Basic 6" that compiles to machine code.  On everything from Windows to Linux, Android to iPhone.  And it's easy.

http://c-prime.net

Attachment 183038





And as I have been up all night trying to get the site up, I shall now go to sleep for a few hours ...  :Smilie:

----------


## SuperDre

Sorry to say this, but if it isn't 100% VB6 compatible, like being able to load your original project and without much hassle start/compile, it isn't really interesting and it'll be just another scripting language.
But good luck, it's already impressive if it compiles to all major platforms.

----------


## yereverluvinuncleber

> Sorry to say this, but if it isn't 100% VB6 compatible, like being able to load your original project and without much hassle start/compile, it isn't really interesting and it'll be just another scripting language.
> But good luck, it's already impressive if it compiles to all major platforms.


I'm not sure about that negativity. Many VB6 programs will never be ported to the iphone/tablet classes of devices. I can see TwinBasic/RADBasic being a future for VB6 on the desktop and thence with a potential future on other desktops... However, if there was a basic-alike language that you could use for the iphone/tablet that also had some use on the desktop - then it could be useful, especially if it is more or less here already.

For new development targetting iphone/tablet a useful and familar desktop IDE is the most important thing for me.

----------


## BN586

> Sorry to say this, but if it isn't 100% VB6 compatible, like being able to load your original project and without much hassle start/compile, it isn't really interesting and it'll be just another scripting language.
> But good luck, it's already impressive if it compiles to all major platforms.


Thank you for comment.  It isn't a scripting language.  It was written in C, it has a virtual machine, it has break/edit/continue.

----------


## yereverluvinuncleber

What the chap meant to say in a more positive way was that, keep it as close to VB6 in use (IDE) but keep the syntax and methods as close to VB6 as possible and you will potentially have lots of happy customers. 

I'd document the differences and make it as as easy to convert as possible.

This place can be quite negative as lots of possibilities have emerged only to disappear, it is a little depressing over time. We also have high expectations, so prepare for criticism.

----------


## BN586

> What the chap meant to say in a more positive way was that, keep it as close to VB6 in use (IDE) but keep the syntax and methods as close to VB6 as possible and you will potentially have lots of happy customers.


It's pretty damn close ... me.caption = "Hello World".  Yes.

But exact where integer is  -32768 to 32767 --- *no!*  Absolutely not.  And your measurements are in twips?  Really, in 2021?  Visual Basic 6 was great but it always had some bizarre choices.

And previous versions of Visual Basic never converted completed to a new version.

Anyway, us programmers can be brash and the like, I have been occasionally guilty of this myself.   I'm not really the kind of guy that gets affected by that.

If you can ask a questions at StackOverFlow, you can take some criticism  :Ehh: 

As a courtesy and a fan of Visual Basic 6 --- I learned most of my programming with that --- I wanted to post it here first.

My son Alex who is in the video is in high school --- no one his age has ever heard of Visual Basic 6.  He's learning Java and Python right now.

C-Prime is going to be around a long time, but it needs to have modern thinking to appeal to newer programmers.

----------


## Niya

> I read this thread numerous times during development, mostly to make sure no one else was successfully building a true Visual Basic 7 and to commiserate in the lack of a true Visual Basic 7.


That has already happened. TwinBASIC is as true a successor to VB6 as I've ever seen. And unlike all the would-be successors we've seen over the years on these boards, this one actually exists outside of people's imaginations.

----------


## SuperDre

> But exact where integer is  -32768 to 32767 --- *no!*  Absolutely not.


Integer range you mention is 16-bit integer.. and is defined back in the day when Windows was still 16bit, when VB started.
Personally I think Integer is a stupid definition as it's based on the system your running it on, better are names like Int16, int32, int64.





> And your measurements are in twips?  Really, in 2021?  Visual Basic 6 was great but it always had some bizarre choices.
> And previous versions of Visual Basic never converted completed to a new version.


I agree, twips is a system that is really bizarre, still have a lot problems with it.
And it isn't a problem if there are some problems after importing a project, but it shouldn't be that you have to change half the application just to get it running. 
Never had any real problems upgrading from VB4 to VB5 and then to VB6..

----------


## Niya

> Integer range you mention is 16-bit integer.. and is defined back in the day when Windows was still 16bit, when VB started.
> Personally I think Integer is a stupid definition as it's based on the system your running it on, better are names like Int16, int32, int64.


Generally in today's world an Integer is thought of as a 32 bit integer. This is true of most popular languages including C++, Java, C#, VB.Net, Java, JavaScript, Swift, Kotlin, SQL and many more.

----------


## VB6 Programming

twinBASIC have updated their roadmap

https://www.vbforums.com/showthread....34#post5565434

The new twinBASIC IDE is looking good and the ability to import VB6 forms and controls is expected soon.

The twinBASIC IDE can be downloaded here https://www.vbforums.com/showthread....=1#post5561881

----------

