AllBASIC

BASIC Developer & Support Resources => VB (5/6/CE) Classic => Topic started by: John on December 27, 2016, 01:39:34 PM

Title: VB6 not dead
Post by: John on December 27, 2016, 01:39:34 PM
I'm having good luck using VB6 IDE on Windows 7 and generating OS level supported applications for Windows 7 - 10 using the current default Windows theming.

I'm curious if there are other VB6 programmers that would like to keep the candle burning with the hopes Microsoft will someday open source it?

The purpose for this post is to get feedback how others feel.

Quote
"B4J is being used by our growing developer community to roll out real-world apps that solve everyday business problems faster than ever before," he said. "Based on the feedback we've received, B4J is being welcomed as an effective and long-awaited successor to Visual Basic."


Title: Re: VB6 not dead
Post by: AlyssonR on December 28, 2016, 03:15:11 AM
I still use VB6 on my Win 7 kit - the only problem is when using the .exe on a different machine due to that £$%^&* code signing thing, since you can't simply tag an application as safe and you have to allow it to run every time.

Both the IDE and the apps run smoothly and reliably on Win 7 both on 32 and 64 bit systems.
Title: Re: VB6 not dead
Post by: John on December 28, 2016, 09:51:42 AM
Quote
the only problem is when using the .exe on a different machine due to that £$%^&* code signing thing,

Allowing an Unsigned Application to Run As Normal (https://technet.microsoft.com/en-us/library/dd261784.aspx)

Can you expand on that? I don't seem to have any issues running VB6 apps on XT, Win7 or Win10 no matter what version of Windows they were created on.

Quote
Hi,

try the following links:

http://www.vbforums.com/showthread.php?t=347478

http://objectmix.com/basic-visual/156510-digital-signature-my-vb6-app.html

http://www.tek-tips.com/viewthread.cfm?qid=1319134&page=161

Hope it helps.

Regards,
A.Murugan

It looks like if the .exe was created on XP, the code signing isn't a requirement.
Quote
All part of the phaseout of COM I suppose, but the API can be used with a little more pain.  It just means you'll want to do your Vista builds on XP, or at least your code-signing and possibly your MSI installer builds on XP.

Even Microsoft (https://blogs.msdn.microsoft.com/vsto/2013/06/18/roadmap-for-apps-for-office-vsto-and-vba/) has stated that VBA (COM/OLE) is still the preferred and feature rich scripting method in Office today.



Title: Re: VB6 not dead
Post by: AlyssonR on December 29, 2016, 09:45:58 AM
Win 7 requires executable code to be signed with a current  certificate - it is self-certificated if you run it on the machine that it was compiled on.

When you develop using VB6, the resulting program runs seamlessly on the development system, but if you install it elsewhere, then execution is interrupted with the Windows User Account Control pop-up asking if you want the program to be allowed to make changes on your computer.

Title: Re: VB6 not dead
Post by: Mike Lobanovsky on December 29, 2016, 11:02:19 AM
Wow-wow-wow!

You shouldn't use the words "installer", "setup", "updater", "patch" and the like to name your program if it isn't one! Windows UAC is trained to be aware of such names (https://blogs.msdn.microsoft.com/sajoshi/2007/02/22/uac-five-most-common-install-failure-scenarios-and-workarounds/) and would automatically require elevated privileges from the user that they might not have.

And even if it is a true installer/etc. supplied with an explicit standalone file or embedded resource manifest defining a "requireAdministrator", rather than "asInvoker", attribute for your application, the target user will still be prompted by UAC to allow/accept the changes the installer is going to introduce to their file system.

All this letting alone the fact that 99% of VB6 applications wouldn't have any manifest at all...
Title: Re: VB6 not dead
Post by: John on December 29, 2016, 12:46:15 PM
Quote from: Mike
All this letting alone the fact that 99% of VB6 applications wouldn't have any manifest at all...

The only manifest I'm using is for Windows 7 theming support for the VB6 IDE. All VB6 applications I create use the replacement MSCOMCTL.OCX that auto registers itself. I'm using Inno to create the SB-Setup.exe which as you say should set up permissions at install time.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on December 29, 2016, 02:27:15 PM
Structurally, a VB6 application is faultless from the MS Windows perspective and doesn't require any extra activities on behalf of its developer or user to get it up and running on any Windows machine. Neither do the C applications created with the older VC6 Visual Studio that VB6 was bundled with back at the time. In fact, the C2.exe compiler that you can find in the VB6 installation is a somewhat enriched pre-VC6 C++ compiler back end (can't recall now if it was a VC3 or VC4 compiler) that's used to translate the VB6 sources to equivalent C++ and to build "standalone" (in fact, MSVBVM60.DLL-bound) VB6 executables. Since MS' support for all this SW was dropped long ago, it's only natural that neither of them has ever had any associated manifest tool.

To the best of my knowledge, MS has promised to include the MSVBVM60.DLL library (VB6 official runtime) into every future release of Windows at least till the year 2025. The only new feature a VB6 application (or a VC6 application as well, for that matter) may ever need to acquire a "modern" look is a standalone (a.k.a "side-by-side") manifest file that would bind it to a contemporary set of Windows common controls. Microsoft's recommended mantras for application manifests can be found here (https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx).

Since your applications, John, are already bundled to a custom control library (MSCOMCTL.OCX where .OCX = .DLL) that's already equipped with a manifest, they can get by without an own manifest unless they need to have some system-wide features enabled that aren't specified in MSCOMCTL.OCX' minimalistic manifest. Installers/patchers/setups are an example where such extra manifests would be welcome.

Alternatively, VB6 and VC6 executables may have manifests embedded in their disk files forever as internal resources using 3rd party software such as e.g. ResHacker (http://www.angusj.com/resourcehacker/).

One more thing to note: while intelligent business AV software like paid Kaspersky, ESET Nod32, Symantec Norton, Microsoft Essentials and a few others would never flag a manifest-less but well behaved VB6 application as potential malware, "free" antiviruses like Avast, AVG, Avira and similar low-end AVs aplenty at VirusTotal.com and similar sites tend to throw false alarms just on account of such applications having no associated manifest file and/or embedded manifest and/or version info resource.

VB6 has always been, and still is, an awesomely feature rich and most user friendly programming environment; probably the best of the kind even if not the fastest.
Title: Re: VB6 not dead
Post by: John on December 29, 2016, 02:38:46 PM
Quote from: Mike
VB6 has always been, and still is, an awesomely feature rich and most user friendly programming environment; probably the best of the kind even if not the fastest.

I couldn't agree more.

The MSCOMCTL.OCX (http://krool.mooo.com/Data/VBForums/VBCCR13/VBCCR13.OCX.zip) replacement (and others) is more than a manifest mapping library and updates many of the common controls to their current revisions, fixes bugs and enhances properties and methods.

VBFourms thread (http://www.vbforums.com/showthread.php?698563-CommonControls-(Replacement-of-the-MS-common-controls))

It was a huge loss when Dave had to give up extending the SB COM interface due to medical issues.  What he left us is more than usable.


Attached is the ComCtlsDemo referenced on the VBForums site.
Title: Re: VB6 not dead
Post by: AIR on December 30, 2016, 08:46:13 PM
/peeks over fence....

Personally, I was a Delphi user.  VB6 was/is very easy to work with, but in the early days was subject to the so-called "DLL-HELL" syndrome, which is why I drifted to Delphi.

At work, we still use quite a few VB6 programs on the PC side.  Some things just do the job as designed (as long as you stay away from the old-school OCX files that auto-updated - UAC has a rough time with those!)

BTW, Season's Greetings, I know it's been a while!

AIR.
Title: Re: VB6 not dead
Post by: John on December 30, 2016, 10:47:40 PM
Great to have you back AIR!

Hope you're doing well.
Title: Re: VB6 not dead
Post by: AlyssonR on December 31, 2016, 03:02:04 PM
One of the first things I learned when using VB was to ensure that the executable was packaged with whichever .DLL, .OCX and resource files it required locally, i.e. in/below the executable directory.

That even included a copy of shell32.dll for any system icons that may be referenced - surprisingly, that fixed a couple of installation problems when compiling on Win 98 and installing on NT4, back in the day.

While it may be necessary to access registry settings, I found that using program.ini for program settings was an absolute godsend, and avoiding a lot of mucking about with installers - my installs were all done with batch files and a configuration utility. Clunky, slow and very reliable.
Title: Re: VB6 not dead
Post by: John on December 31, 2016, 04:49:57 PM
Your VB6 app is required to regsrv32 and unregister the custom OCX (s) it uses. The VBCCR13.OCX I'm using does that for me automatically.


Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 01, 2017, 04:53:27 AM
You can link your VB6 Classic/VB6 CE custom controls into your VB6 executables, in which case you won't have to register anything at all on the target machine if your application has no use of external COM by design or intended purpose. Regardless of VB6's own engine being a transparent 100% COM solution. :)
Title: Re: VB6 not dead
Post by: John on January 01, 2017, 08:32:37 AM
Quote
VB6's own engine being a transparent 100% COM solution.

I feel this is the reason developers have been able to  keep VB6 relevant without source.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 01, 2017, 09:04:20 AM
Nah, they usually tailor it to their needs via its MSVBVM60.DLL's undocumented API and/or vtable patches to redirect program flow to custom callbacks and expose the otherwise unavailable pointers to VB6 intrinsic objects (essentially COM variants).
Title: Re: VB6 not dead
Post by: John on January 01, 2017, 10:59:49 AM
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.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 01, 2017, 04:34:15 PM
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. :)
Title: Re: VB6 not dead
Post by: John on January 01, 2017, 06:05:56 PM
Quote from: Mike
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 (https://download.microsoft.com/download/2/2/B/22B4695E-CEBC-4296-8DC3-0F329CA6751D/Visual%20Basic%20Language%20Specification.docx)


Title: Re: VB6 not dead
Post by: John on January 02, 2017, 02:12:14 AM
Exposing .NET Framework Components to COM (https://msdn.microsoft.com/en-us/library/zsfww439.aspx)

Here is a SB COM C# .Net calendar (http://www.scriptbasic.org/forum/index.php/topic,309.0.html) in a form container using the COM visible feature.

Code: C++
  1. [assembly: ComVisible(true)]
  2.  

Quote
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 (http://jumbloid.blogspot.com/2009/12/making-net-dll-com-visible.html)
Title: Re: VB6 not dead
Post by: John on January 03, 2017, 11:15:53 AM
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.  


Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 03, 2017, 03:10:05 PM
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. :)
Title: Re: VB6 not dead
Post by: John on January 03, 2017, 04:25:32 PM
Not my source. I should have put it in a quote.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 03, 2017, 06:22:52 PM
(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: :)

(http://i1240.photobucket.com/albums/gg490/FbslGeek/DoubleGrippers.png)


Quote
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.
Title: Re: VB6 not dead
Post by: John on January 03, 2017, 06:43:43 PM
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.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 03, 2017, 06:59:40 PM
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.
Title: Re: VB6 not dead
Post by: John on January 03, 2017, 07:31:06 PM
The other reason I'm revisiting VB6 since it no longer looks like Win2K is the vast amount of existing code for it.


Title: Re: VB6 not dead
Post by: John on January 03, 2017, 07:52:30 PM
Quote from: Mike
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.
Title: Re: VB6 not dead
Post by: John on January 03, 2017, 08:53:44 PM
Quote from: Mike
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 (http://www.vb6.us/tutorials/understanding-msgbox-command-visual-basic)
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 04, 2017, 06:56:51 AM
Exactly what is your problem, John? The double quotes seem to be OK this time. :)
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 04, 2017, 10:22:35 AM
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.
Title: Re: VB6 not dead
Post by: John on January 04, 2017, 10:51:50 AM
Now it works when I gave it another try this morning.  :o

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

Your comment put me into a tailspin of confusion and now I'm back at square one.

Please do something with your theming support for your VB6 IDE on XP. It gives this thread a bad image of why people left in the first place. The Windows 2000 look is dead not VB6. I have attached the Windows 7 VB6.EXE manifest. Let me know if you need my XP version.
Title: Re: VB6 not dead
Post by: John on January 04, 2017, 08:19:41 PM
Thanks Mike for the themed addition to your post. It shows how a VB6 modern interface can enhance the user experence.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 04, 2017, 08:28:48 PM
Your comment put me into a tailspin of confusion and now I'm back at square one.

You Linuxoids are too eager to do things differently from the rest of the business world. Where ordinary mortals would use apostrophes: '...', you tend to use an accent and an apostrophe: `...', and where we use conventional double quotes: "...", you prefer to use Windows locale specific glypths “...” that would be turned into Cyrillic handwritten ,,...” (not even sure how to call it in English) by the Russian edition of Windows while russified MS Office would substitute them with Cyrillic typographic double chevrons <<...>>. Hey there on the other side of the ocean, high time to decide on something definitive! Too much internationalization also has its downsides, you know... :D

Quote
Please do something with your theming support for your VB6 IDE on XP.

No problem. I've appended a manifested VB6 IDE snapshot juxtaposed with my earlier one. Feel free to delete or keep either one at your own option. (does scriba have a manifest yet, John?)
Title: Re: VB6 not dead
Post by: John on January 04, 2017, 08:40:34 PM
sbwin.exe is a Windows version of scriba.exe and supports current OS themes used with IUP applications.

AIR was kind enough to build the resource file for the IUP GUI Windows version of Script BASIC using TDM-GCC.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 04, 2017, 08:47:19 PM
Are you aware of this thread (http://www.oxygenbasic.org/forum/index.php?topic=1447.msg15916#msg15916) on the O2 forum?

I think own embedded icon, manifest, and version info resources would do both sbwin.exe and scriba.exe more good then harm as well.
Title: Re: VB6 not dead
Post by: John on January 04, 2017, 08:52:57 PM
Thanks for the link but I have no interest at this time doing anything Windows 64 bit.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 04, 2017, 09:04:14 PM
What I said there pertains to all 32- and 64-bit Windows applications, John, regardless of our concomitant topic on 64-bit TCC initiated by James.
Title: Re: VB6 not dead
Post by: John on January 05, 2017, 10:30:41 AM
I understand your point that SB executables should contain all the resouces (manifests, icons, ...) and author, version info.
Title: Re: VB6 not dead
Post by: John on January 05, 2017, 05:53:41 PM
Mike,

Do you know if it's possible with VB6 to create a forms designer? I'm looking at integrating IUP realtime dialog editor/designer as an extension of Dave's VB6 based Script BASIC IDE/Debugger. It would be fun extending the SB IDE just to shake the rust off from not using it for so long.

Another idea I had was a utility to convert VB6 form files to IUP LED form files. Then I could use VB6 as my designer. (Windows and Linux - one code base)

IUP has a IupOleContro (http://webserver2.tecgraf.puc-rio.br/iup/en/ctrl/iupole.html) but support is minimal. I'm wondering if the SB COM ext. module could be used with it?

Here is an example of using the IupOleControl with the Windows web browser COM control.

Code: C
  1. /*
  2.  * IupOleControl sample using C++
  3.  */
  4.  
  5. #include <stdlib.h>
  6. #include <stdio.h>
  7.  
  8. #include <windows.h>
  9. #include <exdisp.h>
  10.  
  11. #include <iup.h>
  12. #include <iupole.h>
  13.  
  14.  
  15. // Needed to use the WebBrowser OLE control if not using the <expdisp.h> header
  16. //#import "progid:Shell.Explorer.2" no_namespace named_guids
  17.  
  18. static WCHAR* Char2Wide(char* str)
  19. {
  20.   if (str)
  21.   {
  22.     int n = strlen(str)+1;
  23.     WCHAR* wstr = (WCHAR*)malloc(n * sizeof(WCHAR));
  24.     MultiByteToWideChar(CP_ACP, 0, str, -1, wstr, n);
  25.     return wstr;
  26.   }
  27.  
  28.   return NULL;
  29. }
  30.  
  31. static int load_cb(Ihandle* self)
  32. {
  33.   Ihandle* txt = (Ihandle*)IupGetAttribute(self, "MY_TEXT");
  34.   IWebBrowser2 *pweb = (IWebBrowser2*)IupGetAttribute(self, "MY_WEB");
  35.   WCHAR* url = Char2Wide(IupGetAttribute(txt, "VALUE"));
  36.  
  37.   // Uses the navigate method of the control
  38.   pweb->Navigate(url, NULL, NULL, NULL, NULL);
  39.  
  40.   free(url);
  41.   return IUP_DEFAULT;
  42. }
  43.  
  44. int main(int argc, char **argv)
  45. {
  46.   Ihandle* txt, *bt;
  47.   IupOpen(&argc, &argv);
  48.   IupOleControlOpen();
  49.  
  50.   // Creates an instance of the WebBrowser control
  51.   Ihandle* control = IupOleControl("Shell.Explorer.2");
  52.  
  53.   // Sets production mode
  54.   IupSetAttribute(control, "DESIGNMODE", "NO");
  55.  
  56.   // Creates a dialog containing the OLE control
  57.   Ihandle* dlg = IupDialog(IupVbox(IupHbox(txt = IupText(""), bt = IupButton("Load", NULL), NULL), control, NULL));
  58.   IupSetAttribute(dlg, "TITLE", "IupOle");
  59.   IupSetAttribute(dlg, "MY_TEXT", (char*)txt);
  60.   IupSetAttribute(txt, "EXPAND", "HORIZONTAL");
  61.   IupSetCallback(bt, "ACTION", (Icallback)load_cb);
  62.  
  63.   // Maps the dialog to force the creation of the control
  64.   IupMap(dlg);
  65.  
  66.   // Gathers the IUnknown pointer to access the control's interface
  67.  
  68.   IUnknown* punk = (IUnknown*) IupGetAttribute(control, "IUNKNOWN");
  69.   IWebBrowser2 *pweb = NULL;
  70.   punk->QueryInterface(IID_IWebBrowser2, (void **)&pweb);
  71.   punk->Release();
  72.   IupSetAttribute(dlg, "MY_WEB", (char*)pweb);
  73.  
  74.   // Shows dialog
  75.   IupShow(dlg);
  76.  
  77.   IupMainLoop();
  78.  
  79.   // Releases the control interface
  80.   pweb->Release();
  81.  
  82.   IupClose();
  83.  
  84.   return EXIT_SUCCESS;
  85.  
  86. }
  87.  

Once I get control = IupOleControl() I should be able to use the Script BASIC COM interface to access properties and call methods. Events are still being investigated.
Title: Re: VB6 not dead
Post by: John on January 05, 2017, 11:51:43 PM
It seems every time I try to start VB6 IDE now, it tries to install VS2008 (again). From the few Google searches I've done this is a know problem but none of the suggested fixes worked.  :-[
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 04:49:43 AM
It seems every time I try to start VB6 IDE now, it tries to install VS2008 (again). From the few Google searches I've done this is a know problem but none of the suggested fixes worked.  :-[

Please have a closer look at this thread (https://social.msdn.microsoft.com/Forums/vstudio/en-US/407058cd-22c5-44b7-bd0e-0571fdd2fc69/launching-vb6-editor-after-installing-visual-studio-2013-results-in-please-wait-while-windows?forum=vssetup). MS is reluctant to ensure backward compatibility of their newer Visual Studios with VS6 that the VB6 IDE was part of. The strategy described in the thread I've pointed to may help cure your problem.

Every NT-based Windows of the Professional/Enterprise/Ultimate brand has a cluster of services called Administrative Tools in its Control Panel. (Make sure you're seeing a full list of Control Panel apps and services rather than its default abortive Suzie User view.)

Goto Administrative Tools->Event Viewer->Windows Logs->Application's list of notifications, alerts and errors to deduct exactly what might be causing delays/unwanted activity whenever your launch your VB6 IDE, and try to fight it similar to what the people are doing as per the above link.

You're playing against MS .NET interests and in doing so, it would be unreasonable to expect their co-operation. :)
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 05:32:08 AM
Do you know if it's possible with VB6 to create a forms designer?

You can create any procedural code in VB6 regardless of this BASIC being essentially a COM-based OOP product (cf. ANSI C/C++ compatibility in all VC/GCC products), as long as your code doesn't need explicit access to memory pointers unavailable in an unmodified VB6 environment.

There are many implementations of a minimal forms designer around but most of them are based on the same Public Domain code found e.g. in BCX' BFMD (SDI) or FBSL's FMFD (MDI) albeit with different, target BASIC-dependent code generators.

You can download (http://www.fbsl.net/phpbb2/download/file.php?id=1845) the FBSL re-implementation of the same and study both its source code and functional precompiled binary. FBSL BASIC is closer to VB6 than BCX in its syntax and its sources would be easier to translate to VB6 to the exact same effect, of course having rewritten the code generator part to emit VB6-specific (or Iup-specific, for that matter) control prototypes because:Note that both BCX and FBSL minimal form designers would be equally far from perfect because they are based on essentially the same source code. Yet both could be debugged and improved upon while being translated to VB6.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 08:00:28 AM
[OT] That's what my weather monitor gadget currently looks like:  ;D [/OT]
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 09:12:40 AM
Thanks Mike for your post!

Adding the directory didn't work for me like it did for others. The last post to that thread mentioned he just let VS#### reinstall and the problem went away. I will give that method a try if your suggestions don't work.

Update

I decided to let VS2008 reinstall and went to grab a cup of coffee and when I returned there was no indication a install was in process or completed, just the desktop as if I just restarted and logged in. Everything works like it should. STRANGE!
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 01:26:18 PM
Quote
  • VB6 doesn't have a generic CONTROL widget available in FBSL/PB/TB/BCX and the like to dynamically create any common control available under Windows;
  • VB6 uses extended in-house Thunder... and ThunderRT... wrappers for its set of intrinsic controls rather than raw Common Controls every other BASIC/C/whatever language uses for their UIs.

That may be true for virgin VB6 but with the use of the VBCCR13.OCX replacement for the Thunder classed controls, I don't think that is still a limitation.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 01:27:44 PM
I used to have a few VMware v8 VMs under my XP when MS dropped XP support a few years ago. I migrated them to Win 7 on another PC and uninstalled the older VMware. But it often happens that deinstallation isn't as clean as it's supposed to be. So, one of VMware's numerous DLLs remained dormant in my \system32 subfolder where I didn't have a chance to spot it for the life of me among a thousand other DLLs that had piled up there since my most recent clean XP install circa 2005. I noticed that my XP started to take unusually long to boot. And Event Viewer helped me to spot and mark for deletion-on-reboot the offending DLL that was simply trying to pull in over and over again the entire VMware v8 installation from the server that wasn't offering it for download any longer because VMware had proceeded to v10 in the meantime!

The directory you mentioned might well have been not the true cause of conflict in your particular case. But analyzing the logs usually helps to find out exactly what might be happening; you just need to know where to look for them, and Event Viewer is the correct place for this under MS Windows. Probably your VS 2008 installer now rolled a couple of newer files on top of those that are used by both IDEs and that might've been incidentally overwritten with older versions by the VB6 (re)installation, and now the entire conglomeration can coexist peacefully again. MS servers usually take time to connect to and that's what might have been causing the delay in launching your VB6 IDE.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 01:36:23 PM
That may be true for virgin VB6 but with the use of the VBCCR13.OCX replacement for the Thunder classed controls, I don't think that is still a limitation.

That's really not a limitation but just additional PITA. Either way, I think it's not really Thunder controls that you should be after but rather the IUP controls to make SB GUI friendly in both Windows and Linux. Leave the Thunder controls alone to be handled in their native VB6 IDE environment; there's no place better for them than that. Get your own IUP forms editor up and running instead. VB6 and VBCCR13.OCX will be just a welcome Windows-only bonus.
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 01:42:40 PM
You're right and I need to stop getting side tracked with the lure of using VB6 as a OCX forms control with a COM/OLE SB connection. Dave already has something worth building on and I'm pondering if I should just live with the IUP dialog editor and property sheet or wrap it with VB6?
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 02:56:40 PM
I decided to do a rebuild of the Script BASIC COM extension module and was surprised how it went from zero warnings to 334.  ::)

After adding _CRT_SECURE_NO_WARNINGS to the C++ preprocessor definitions,  I'm down to 137 warnings.  :)
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 03:03:25 PM
Quote
I decided to do a rebuild of the Script BASIC COM extension module and was surprised how it went from zero warnings to 334.

My condolences. You will have to revise your project/solution settings after your recent re-installation of VS 2008 components that evidently took place while you were out for your cup of coffee.

Quote
... I should just live with the IUP dialog editor and property sheet ...

John, that's in fact a serious strategic question. That's what I'm pondering over too in relation to the projected FBSL (?) v4.

Firstly, an attractive BASIC must use the GUI elements native to the OS it is run-/-ning/-nable on. Look at VB6: its Thunder controls are 95% native in their underlying implementation yet they look completely alien under modern Windows unless we take emergency measures in the form of extra side-by-side manifests or embed them in VB6 executables directly using 3rd party tools or VB6 environmental hacks.

Secondly, IUP, and wxWidgets, and Qt, and almost everything else of similar kind seems to be too huge to be bundled with a medium sized BASIC on anything but Linux where they belong and where their components are in fact standard system equipment. A 260KB-large all-in-one FBSL binary simply CAN'T allow itself to be bundled with 5MB of GUI framework DLL hell that's going to falter every now and then where the native Common Controls sell for nothing and are rock solid. Nor can you efficiently isolate only what you need from these frameworks because their devs are steadily sailing away from simple widgets to a common easier-to-maintain core and peripheral control-specific wrappers good for nothing without the huge core they have to pull in. (and the situation only gets worse with every passing day while we're still unsure even where to begin)

Thirdly, these frameworks' interfaces are far too atomic to fit in the BASIC paradigm. Look at what IUP offers to interface your apps with! OMFG!!! You need perhaps two dozen distinct function calls and a verbal markup script into the bargain (!) just to get a simple button up and running in your app's GUI window! It is in a bad need of much, much simpler higher level wrappers and a compos visual designer with direct code generation to become minimally practical for everyday use. There is absolutely no reason for a C or BASIC programmer to have to code extra XML/HTML/Python/younameit stuff to spawn a hello world popup on the user screen!

I'm very grateful to AIR for pointing me to that LIBGUI stuff. It seems to be just about right in its ripeness to start falling into the same trap of "universality" as all its predecessors, but yet recoverable to its distinct constituent components that are the only meaningful and usable parts of any project in this area of program development.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 04:09:42 PM
Try to add _CRT_NONSTDC_NO_WARNINGS to suppress POSIX warnings as well. I think Dave was rather using a make/bat file to compile the sources if these macros aren't defined in the solution/project file settings he supplied you with. :o

Or he was still using VC6 to compile them, as I suggested you should do too...
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 04:24:41 PM
At this point they are warnings and giving me a ToDo list when I have time. If this was more than an IDE/Debugger, I might be more concerned. My gcc builds were void of warnings so on to better things.

Dave built the COM ext. module with VS2008. He even did a video of how to set it up for the project. My guess is Dave didn't feel the warnings were concerning in the development phase and I didn't discover them until the rebuild.
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 04:44:23 PM
Given what you say, I'm 100% sure he was simply ignoring them. Judging by your log file and his C vocabulary, it is obvious he meant the sources to be linked against msvcrt.dll rather than the VC9 extra distributables.
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 06:00:07 PM
I think a bit of history would clear things up how things evolved.

Peter created the dbg.so debugger with the the main goal of showing how C preprocessors are used with Script BASIC. This was a Windows console mode preprocessor that used Windows console mode specific API calls. Before Peter moved on, he gave me the 2.1 beta release to setup an open source effort with. He wrote a GUI remote version of the debugger called sdbg.exe. It was buggy and I converted to a console remote debugger (http://www.scriptbasic.org/forum/index.php/topic,336.0.html).  (dbgcon) When Dave came along he built on Peter's effort but used VB6 and eliminated the socket interface for something more direct.

(http://files.allbasic.info/ScriptBasic/sbdbg.png)

(http://files.allbasic.info/ScriptBasic/sbdebugger.png)

(http://www.allbasic.info/forum/index.php?action=dlattach;topic=455.0;attach=1119;image)

Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 06, 2017, 07:14:47 PM
Thanks for the clarification, John.

Whoever was the author of the C code you're immediately compiling was using a classic C language runtime library's vocabulary to formulate this code, and the offending function names you're seeing in your logs have no particular console or GUI flavor.

Since probably 90% of all Windows executables have been and still are compiled using MS VC compilers, msvcrt.dll (it dates back to VC6 times) has become a de-facto standard for Windows apps that have no use for more modern MS VC bells and whistles and anti-buffer-overflow solutions and redistributables that MS is coming up with in every annual edition of yet newer Visual Studios. Naturally these newer IDEs aren't very happy with this, and you won't see an explicit prebuilt option in them to allow for linking to the "deprecated" DLL. Hence my original advice to use VC6 and its IDE to avoid likely "false alarms". Another known hack would be to use a VC6-only installation without its IDE but instead to point your VS2005/2008 project compiler, include, and library paths to those of VC6 rather than VC8 or 9. :)

But probably I'm meddling too much in what isn't supposed to be my concern. I apologize if that is really the case. You know you are always free to trim my input to reasonable bounds if need be. :)
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 08:41:45 PM
Quote
But probably I'm meddling too much in what isn't supposed to be my concern. I apologize if that is really the case. You know you are always free to trim my input to reasonable bounds if need be.

This is an open topic about VB6 and its continued viable use. I just happen to be using Dave's stuff as a working example and the problems I've run into.

Keep in mind that most of SB VB6 IDE/Debugger is standard scriba and dbg preprocessor code that VC2008 is complaining about. We can't blame Dave for that.
Title: Re: VB6 not dead
Post by: John on January 06, 2017, 09:14:18 PM
I ran across this VB6 based form designer (https://www.codeproject.com/Articles/12560/Form-Designerhttps://www.codeproject.com/Articles/12560/Form-Designerhttps://www.codeproject.com/Articles/12560/Form-Designer) that looks promising.

Let me know if you think this would be a good place to start.

The one thing that I'm going to have a hard time giving up is the real time editing of a running form.  Maybe with a bit of help from VB, I can make the IUP dialog layout editor look a little better.

Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 07, 2017, 06:06:12 AM
John, you already have 4+MB of dependencies in your VBCCR13.OCX. You're gonna have another five in your IUP framework. Why would you be willing to pull in yet another megabyte of DD-specific ActiveX'es and core C dependencies? Let alone COM that's strictly Windows-specific? There won't be any cross-platform code compatibility between Lin and Win SB this way.

OTOH BMFD/FMFD are tiny and self sufficient, and their code generators may easily be re-oriented from Common Controls to IUP or another GUI framework of your choice. There are a zillion eye candies written in VB6 but you won't be able to use them anywhere outside Windows COM, or even look through them all in your lifetime.

Just saying.
Title: Re: VB6 not dead
Post by: John on January 07, 2017, 10:22:57 AM
Good points and made me realize how easy it is to get fat. For this round of the Windows 32 bit release I'm going to stick with what Dave gave us and the IUP dialog editor/designer. I think the end goal should be a cross platform IDE/Debugger written in C BASIC/IUP.

Quote
There are a zillion eye candies written in VB6 but you won't be able to use them anywhere outside Windows COM, or even look through them all in your lifetime.

It's just nice to know that VB6 isn't dead for the everyday tasks and games we all loved doing in the past until Microsoft abandoned us for .NET.

Quote
Unfortunately not enough people realise that VB stands for Very Best.  :)
Title: Re: VB6 not dead
Post by: Mike Lobanovsky on January 13, 2017, 01:01:14 PM
Quote
Unfortunately not enough people realise that VB stands for Very Best.  :)

Absolutely! :)
Title: Re: VB6 not dead
Post by: John on January 13, 2017, 05:47:05 PM
I thought more VB Classic programmers would have been interested in this thread with the news they can generate applications that runs great on all versions of Windows supporting current controls and theming.




Title: Re: VB6 not dead
Post by: AlyssonR on January 15, 2017, 04:09:34 AM
Strange.

Of course, a lot of VB programmers are still feeling the effects of 2016  ???

Having said that, most of my VB programming is automation rather than interaction, so I don't notice the mismatch.
Title: Re: VB6 not dead
Post by: John on January 15, 2017, 11:05:21 PM
I gave up on VB6 due the Windows 2000 look and the aging controls that no longer seemed to be supported. Using VBCCR13.OCX and a manifest for VB6.EXE giving me current Windows 7 theming, I have a renewed interest in using it again for the vast  VB6 code base that exists.

Quote from: Krool - VBCCR Author
Quote
Q. What is the benefit of using these over the existing controls?
Q. Does each control have the same properties? Do they have new properties?

The benefit is that these controls are linked to the comctl32.dll, that means they support the latest API calls, functions, properties and visual styles (themes).

The existing common controls 6.0 from MS are not linked to the comctl32.dll, so they doesn't support the visual styles (themes).
Reason why: The controls of the comct32.dll are compiled directly into the common controls 6.0 from MS, but as of state of a old version of comctl32.dll

Only the common controls 5.0 from MS are linked to the comctl32.dll, but the COM hull is very old and so they have a leak of the latest functions and properties. Also controls like the DTPicker, MonthView or UpDown are not included.

The VBCCR14.OCX has been released by Krool if you want to update your library.