VB6 not dead

[John]

Mike,

Is Visual Studio 2008 the best release to use if you plan on building C/C++ extensions to VB6 projects?

Currently in my Windows 7 32 bit VirtualBox I have VS6 (VB6 only - no VS, ...), VS2008 Pro, VS2012 Ultimate.

[Mike Lobanovsky]

Me?! No, I ain't planning to get involved in any VB6 activity in the foreseeable future. I got pretty much fed up with it in my past.

VB6 doesn't support either 64 bits or multi-threading so there's no real need to have anything better than VC6 it used to share its VS environment with at the time. Use VC6's typical ANSI C tool chain and link against the system standard msvcrt.dll library. And I'd strongly recommend using its original IDE instead of nmake and/or batch file jugglery. When in Rome, do as the Romans do.

[John]

Me?! No, I ain't planning to get involved in any VB6 activity in the foreseeable future. I got pretty much fed up with it in my past.

I'm doing this to extend VB6 use since Microsoft is still willing to support it for the foreseeable future.  VB6 with its user contributed enhancements works just as well or better than any other 32 BASIC out there. VB6 makes COM usable to BASIC programmers. Trying to use Roca's includes is over the heads of most.  Sorry you had such a sour experience with VB6.  I couldn't be happier that Dave created an SB interface rather seamless with VB6.

I went back through the old SB COM threads and it looks like Dave used VS2008 for his C++ part of the code. The VS2008 IDE even compiled the C# .NET example creating the COM aware OCX from control as a .DLL.

FYI: I was getting all kinds of warnings and a strange error that made no sense. Turns out running Visual Studio 2008 on Windows 7 in administrator mode produced a clean build. (no warnings or errors)

I find Visual Studio beyond 2008 slow, non-intuitive and difficult to use.

Microsoft Visual BASIC 11.0 Language Specification

[John]

Exposing .NET Framework Components to COM

Here is a SB COM C# .Net calendar in a form container using the COM visible feature.

Code: C++

1. [assembly: ComVisible(true)]
2.  

For reference, if no assembly level ComVisibleAttribute is applied, all public classes are assumed to be COM Visible. Failing to mark an assembly as [assembly: ComVisible(false)] will often result in the following Code Analysis warning, even for types that are not marked [ComVisible(true)]:

CA1405: COM visible type base types should be COM visible

Making a .NET Dll COM-Visible

[John]

VB.NET - Add COM-Visible Attributes

There are some cases when a company might want to convert some of its VB6 modules to .NET and keep using them in a COM environment. E.g.: convert the logic libraries and keep the front end in VB6. The “COM Visible” feature was implemented to assist in this scenarios.

When this optional feature is enabled, the VBUC will generate attributes for the COM-exposed classes and their members in order to keep the resulting assemblies exposed through a COM interface. This enables the resulting components to be called from other non-managed components via COM. A brief code sample:
Original VB6 Code:

The following method is declared in an ActiveX dll.

Code: Visual Basic

1. Public Sub method1()
2.     MsgBox    “Hello world”
3. End Sub
4.  

Resulting VB.NET Code:

Code: vb.net

1. Option Strict Off
2. Option Explicit On
3. Imports System
4. Imports System.Runtime.InteropServices
5. Imports System.Windows.Forms
6. <ComVisible(True)> _
7. <ProgId("Project1.Class1")> _
8. <ClassInterface(ClassInterfaceType.AutoDual)> _
9. Public Class Class1
10.     Public Sub method1()
11.         MessageBox.Show("hello world", Application.ProductName)
12.    
13.     End Sub    
14. End Class
15.  

[Mike Lobanovsky]

Code: Visual Basic

1. Public Sub method1()
2.     MsgBox    “Hello world”
3. End Sub

Both VB6 and VB.NET are gonna choke with the double quotes you're using in your sources, John.

[John]

Not my source. I should have put it in a quote.

[Mike Lobanovsky]

(posting this just to signal I've seen your post-factum edits)

I'm doing this to extend VB6 use since Microsoft is still willing to support it for the foreseeable future.  VB6 with its user contributed enhancements works just as well or better than any other 32 BASIC out there. VB6 makes COM usable to BASIC programmers. Trying to use Roca's includes is over the heads of most.  Sorry you had such a sour experience with VB6.  I couldn't be happier that Dave created an SB interface rather seamless with VB6.

It also implements a handy event-driven paradigm for interaction with an inexperienced user. Just a few predefined Events for each of a few predefined controls instead of Windows' usual extremely versatile message pump. Plus a possibility for the user to define their own set of Events (implemented transparently with Windows custom messages in the WM_USER+ or, better, WM_APP+ range) for their own COM-based User Controls.

But once there always comes the time when predefined-only Events become a burden for the user. I remember I liked pretty much those double-bar grippers the VB6 and VC6 IDEs had in place of the single-bar grippers the Common Controls library offered in its stock toolbar and rebar controls back at the time. They couldn't be ownerdrawn (or overdrawn, for that matter) using the VB6 stock Events only. Graphics is just one of the many turning points where every advanced Visual BAsic user usually starts to "enhance", with different levels of success, the VB6 environment proper.

I went another way. I designed my own BASIC that had everything VB6 lacked from my perspective, including the console. And now Eclecta still has those double bar grippers I was after 15 years ago:

I find Visual Studio beyond 2008 slow, non-intuitive and difficult to use.

The VC6 IDE I mentioned was practically as responsive and user-friendly as its VB6 counterpart.

[John]

The only reason I'm interested in VB6 is for the easy to use COM/OLE aspect. Dave's contribution only makes it sweeter.

VS2008 is fast, clean and intuitive like the VB6 counterpart but with native theming and updated controls. For my purposes developing Windows 32 applications VB6 & VS2008 is all I need. I tend to use TDM-GCC32 as my goto compiler for the cross platform support it offers. For COM related projects I'll stick with VS2008.

[Mike Lobanovsky]

No problem, John, do as you please -- you're the SB boss, after all. But just FYI, PowerBASIC 10.04, the latest version to date, has everything one may ever need to efficiently use early-bound (faster) COM directly in their applications.

[John]

The other reason I'm revisiting VB6 since it no longer looks like Win2K is the vast amount of existing code for it.

[John]

FYI, PowerBASIC 10.04, the latest version to date, has everything one may ever need to efficiently use early-bound (faster) COM directly in their applications.

I don't know which is more dead, PowerBASIC or VB6?

PowerBASIC has no ATL container support and relies heavily on Jose Roca's additions to make COM usable. I don't see Jose investing anymore time in PB and seems to have already made the FreeBASIC transition.

[John]

Both VB6 and VB.NET are gonna choke with the double quotes you're using in your sources, John

ok

Something doesn't jive with examples being posted.

Understanding the MsgBox command in Visual Basic 6

[Mike Lobanovsky]

Exactly what is your problem, John? The double quotes seem to be OK this time.

[Mike Lobanovsky]

There's a link to the corresponding VB6 project there. Below is a snapshot of its typical output under my XP. Of course it's a mockup because I can't proceed before I close a modal MsgBox at each prior stage but it honestly depicts what I'm seeing in one session until I hit the main form's Exit button.