Oxygen Basic
Information => Open Forum => Topic started by: JRS on October 07, 2014, 04:17:25 PM
-
The Script BASIC project could use some help testing Dave's IDE/Debugger and COM interface. The complete project and a Windows installer is available on the Bitbucket Script BASIC COM repository (https://bitbucket.org/ScriptBasic/com). Don (SB forum member) seems to be having lock-up / not responding issues and I unable to reproduce them under XP (VirtualBox) or Windows 7 64 bit. (WOW)
Either I am doing something wrong or else there is a bug in the Debugger.
When i load a SB script (for example testmath.sb) an click on the RUN button, everything seems to execute OK. But if I then click on the scroll bars on the right side of the two windows or if I click anywhere in either window or on any of the program control buttons the Debugger freezes with the "PROGRAM NOT RESPONDING" messages and I have to do several ctl-dels to kill the hung up process "test".
P.S. I have the same problem when using the previous version before your weekend update.
It would be really great if Jose Roca would find an interest in SB COM and help the project along.
.
-
Has anyone given this a try? It doesn't work for Don but works for me. Where do you stand in this dilemma?
-
from the darknest corner of internet ....
.....this program talk and talk and talk,,,,, ;D
yes it work!
.
-
Thanks Aurel for giving it a try!
Do you have VB6 or the runtime libraries installed?
-
No problem ,IDE is not bad ...
well believe or not ,this is the first time that Script Basic program work for me :o
anyway...i have VB6 on CD somewhere but for runtime i am not sure ..probably is
installed or this program just work... ???
-
No problem ,IDE is not bad ...
Dave did a great job on the IDE/Debugger and his C code really shows how the internals of SB works embedded.
Hearing that your box worked was a sigh of relief. If it runs on Aurel's system, it should run on anything else. :)
You should be able to add the rest of the extension modules (SDL_gfx, IUP, ...) and use the IDE with them. (3rd party dependency installs required)
It would be great to hear if it's working on Win 7 / 8 / 10 for anyone else.
-
I would like to propose standardizing on Dave COM interface for BASIC languages like O2, FBSL, ... and jointly maintain the project. After reading Frederick J. Harris's Converting Data Bound Grid Control Code To PowerBASIC Windows 10 (http://www.jose.it-berater.org/smfforum/index.php?topic=4996.0) there has to be a better way. Merging Dave's COM with Charles's DLLC is another thought I have pondered.
If the PowerBASIC folks are tired of waiting for a pheonix of PB, they should seriously consider joining us here for dose of O2.
-
Hearing that your box worked was a sigh of relief. If it runs on Aurel's system, it should run on anything else. :)
Because of him, I use a proprietary APDS (Aurel Proof Delivery System) for anything I release for Windows. Truly does work for EVERYBODY.
-
I think one of the main items on the VB6 lives on list is XP theme support. (XP & Win7) I already have theme support in the VB6 IDE which works great. (see attached) I found a link that looks promising and plan on giving it a try with the SB IDE/Debugger.
VB6 XP/Vista/Win7 Manifest Creator (http://www.vbforums.com/showthread.php?606736-VB6-XP-Vista-Win7-Manifest-Creator)
.
-
Hi John,
1. The VB6 virtual machine's runtime msvbvm60.dll (its US locale build, to be precise) is a system library that comes in every clean Windows installation, original or OEM, localized or not, since Windows 2000. You can find it in the \system32 forlder of any OOTB 32-bit installation, or in the \SysWOW64 folder, under 64 bits. So, you shouldn't worry about the compatibility of your editor with any user PC regardless of the actual Windows version or locale it runs under so long as the editor continues to be re-compiled, if needed, by VisualBasic 6 localized for the U.S. Neither do you have to ship your own msvbvm60.dll with it because every Windows PC already has it installed in its default search PATH. In fact, failure to run your editor on a Windows PC is a 100% sure indication that the PC's Windows installation is broken or has been tampered with.
Official VB6 packages localized for other regions are however not ABI compatible with VB6's original US implementation and would therefore require their own msvbvm60 DLL's to be shipped along with VB6 programs created using such packages. I have checked it personally for legit Russian, French, and Spanish packages of VB6. The situation with warez distros of VB6 may be even worse than that. So, make sure your US VB6 package stays intact and don't allow unauthorized, amateurish recompilations to occur. (yet another headache of an open-source project, hehe...)
2. It is true that in order to support theming, any Windows application must have either a precompiled manifest resource or an associated .manifest file. But VB6's controls aren't simple common system controls that other languages would use. Most of them are superclasses augmented to suppress excessive flicker of ordinary common controls as they are being resized on non-composited desktops of W2K or XP or Classic themes of Vista+ platforms. They also allow for VB6's own backbuffering (the so called Autoredraw mode), which ordinary common controls won't do. Clearly enough, such improvements imply totally different drawing patterns that may be incompatible with the principles of Windows theming now or, more likely, in the future.
VB6 had been designed before Windows themes appeared therefore MS has never guaranteed that manifests would work for VB6 programs under all circumstances or with all Windows builds. All such theming was never officially supported and is totally at the developer's and user's own risk. Luckily enough home-brewn VB6 theming kinda works in most cases.
3. IIRC FBSL has had its own COM layer since the year of 2006 or thereabouts. It's capable of handling both local and inproc servers (i.e. exe and dll COM object sources) and it can also make use of ActiveX technology with some extra programming effort which isn't however too extreme to be totally impractical.
So, I beg your pardon but your proposition on standardizing FBSL to Dave-or-anyone-else-over-there-at-SB's COM does sound a bit out of place to me. Thanks for the invitation tho.
-
Thanks Mike for the VB history and what MS supports. Dave's COM interface is more than an OLE automation interface. It supports using VB & .NET forms/controls for the GUI and use SB for the callback routines. What the PB team has been after for years. I will post an example of this today.
-
Thanks John,
I'm looking forward to seeing it in action.
-
Thanks John,
I'm looking forward to seeing it in action.
I posted it on the Script BASIC forum in a new thread.
Script BASIC COM VB example (http://www.scriptbasic.org/forum/index.php/topic,323.0.html)
-
I posted a Script BASIC COM example of accessing a C# .NET calendar control on the Script BASIC forum if anyone is interested.
-
Are your VB6 and .NET GUI's compiled as ActiveX DLL's?
-
Yes. The Bitbucket repository has all the code for the examples I posted.
-
As promised, I posted VB6 calling back to Script BASIC script functions.
See latest Script BASIC forum post.
-
Yes.
Thanks, John.
Then this maxim
Dave's COM interface is more than an OLE automation interface.
doesn't seem to be well-proven. Calling properties and methods of OLE (= ActiveX) objects (= VB and C# controls) from an inproc (= DLL) server is exactly what "OLE automation interface" stands for. In other words, I'm sorry to say but I'm feeling a little, erm, frustrated since my "looking forward to" expectations have not been satisfied.
In other respects, your SB OLE code looks nice and easy to follow, and this COM-aware extension may indeed be handy for basic interaction with COM based applications.
-
In other respects, your SB OLE code looks nice and easy to follow, and this COM-aware extension may indeed be handy for basic interaction with COM based applications.
Good enough for me. Thanks for having a peek. Can I ask you to try it on Win 10 when you have time?
Are your VB6 and .NET GUI's compiled as ActiveX DLL's?
You can you use the FREE VB controls edition to create ActiveX DLLs that work with SB COM. (I was successful theming it as well)
-
Sure John,
I'll try to do it tomorrow.
-
I posted an VB5CCE (VB5 Controls Edition) OCX example using SB COM.
I also included a link to download the FREE VB5CCE + xp manifest + help (10.2 MB) if you want to give it a try.
-
if you want to give it a try.
Dear John,
IIRC I gave it a try somewhere in early 90's of the last century. Let's however leave "you" in place as an indefinite reference to our juniors who may have never seen VB CCE in action. :D
-
For nostalgia reasons, it is nice to see somebody besides Chris Boss trying to keep VB6 alive. But, VB6 has had its run and has nothing to offer in this modern era. Code produced is not remotely optimized for modern processors, does not properly handle multi-threading, and does not support 64-bit.
-
Yet it may be a good start before plunging headlong into VB.NET and C#. It was rock solid and very entertaining for its time. And it's still being used by thousands of small businesses and tens of thousands of programmers that cater for the needs of the former.
-
I agree that VB classic is still widely used. There seems to be considerable effort to keep it relevant by the user base. (theme support, updating libraries, ...) It makes a nice GUI designer for Windows and the SB COM interface is the easiest method I've used so far working with it outside the box.
I'm still interested to see if the SB IDE/Debugger works with Win 10.
-
I'm still trying to stand up to my promise to let you see if the SB IDE/Debugger works with Win 10.
-
Thanks Mike!
It would make me feel better to know my efforts will still be valid on Win 10. It should be interesting news for all VB classic programmers.
-
I hasten to inform you that msvbvm60.dll is safe and sound at its usual place in the \system32 folder of Windows 10.
And my computer has just informed me robotically that this is my test of your SB debugger installation. :)
Slight inconsistencies with GUI control placement/sizing may be corrected in VB6 IDE to allow for generally thicker non-client margins (borders) and taller titlebar under more modern Windows OSes.
(IIRC (but I may be wrong!) mscomctl.ocx is not a redistributable module; it's a licensed component that comes with your legit VB6 installation. But I repeat I may be confusing it with some other one that spells or sounds close enough to that.)
.
-
It makes a nice GUI designer for Windows
I do keep VB6 installed as I am slowly porting a lot of old stuff over to a different language. But you did highlight a VERY good point. The GUI designer is VERY nice and I have used it with many different languages via custom FRM converters over the years. I did love VB6 back in the day and it is the RAD IDE that all others should be judged by (the only thing that ever came close for MSVC++ at the time was the third-party Octopod IDE).
-
Yes Brice,
I've read a thousand VB6 user messages that the only chance for other BASICs to cause people to leave VB6 behind would be a compatible IDE of at least equal functionality.
-
Thank You Mike !!!
I feel a lot better about investing my time in this direction.
I've read a thousand VB6 user messages that the only chance for other BASICs to cause people to leave VB6 behind would be a compatible IDE of at least equal functionality.
I'm looking at a VB6 (GUI layout) to SB(or anyone else)/IUP translator for a cross platform use.
-
I'm looking at a VB6 (GUI layout) to SB(or anyone else)/IUP translator for a cross platform use.
I can only wink-wink in Kuron's direction then. Perhaps it's him that could help you out with that judging by his last message. :)
My own efforts in that domain ended back in 2006 when a bunch of half-illiterate ex-BCX drama queens accused closed-source FBSL of being an illegal clone of BCX. Of course it wasn't and simply couldn't be one because FBSL is a bytecode interpreter, i.e. an entirely different type of application, rather than a mere piece of translator bloatware. I was working on FBSL's own IDE that was supposed to re-implement VB6 IDE's functionality for FBSL as closely as possible. It was coded in OOP-ed FBSL BASIC and DynAsm and was already combining all the might of Eclecta (FBSL's official editor) and a simple form designer. Its codename was FSF that stood for Freestyle Script Factory.
The accusations were so unexpected and so utterly profane that I was baffled and outright appalled to the extent of being unable to do any work, to say nothing of completing so ambitious and complicated a project as that. Some of the hounds are here no more, some others have been unfortunate to sort of recover from physical illnesses to the state of near insanity, yet some others are still here doing well. I'm not angry any more because time does heal our wounds. But the project was abandoned in an indeterminate state because I seem to have lost any interest in this kind of activity, restricting myself to occasional fixes to Eclecta to keep it minimally up to date with current builds of FBSL proper.
That's how I lost my faith in humanity. :)
.
-
That's how I lost my faith in humanity.
That's gorgeous! You shouldn't give up that dream.
-
It was dream coming true. :)
FBSL of today is incongruously mightier than it used to be in 2006, and reviving this project would mean re-writing it completely from scratch. I am not sure if it would be reasonable, John. I'm not coquetting or something. There are simply so many interesting things around these days that if one gets involved in a project like this, one risks not having enough time left to feel the taste of them all. :)
-
when a bunch of half-illiterate ex-BCX drama queens accused closed-source FBSL of being an illegal clone of BCX
If it is any condolence, there have been many of us who have had run-ins with these idiots over similar issues.
-
I didn't realize that the BCX project was still alive. I thought James Fuller's BC9 was the last version of it. I haven't heard from AIR (Armando) in ages.
-
@Kuron:
Condolences are accepted with gratitude and a fair amount of them returned to my brother in arms. :D
@John:
No John,
Those people who have forked their own implementations off the BCX main trunk are the brave souls that only deserve respect for their perseverance in turning that bloatware into their own respective usable products the way they saw them.
I remember my elder son (arilou_camper was his nick) to have downloaded their last build somewhere around 2009 or something and offer me to have a look at what came out of it in the end. I said no and never touched the zip. But I must confess it is still hanging somewhere on my XP desktop amongst some other 350 to 400 downloads accumulated there over the years -- untouched.
Not interested.
(And yes, my XP has never slipped me since the year 2008 and I've had no need to reinstall it for all that time, and it's still alive and kicking and sending you greets. Can any of you Linuxoids boast the same? :D )
-
It was interesting to see VB5CCE run under Wine.
I tried to install the SB IDE/Debugger under Wine but it failed to register two of the required OCX controls. :-[
.
-
I just created (VB6 compiled) the Manifest Creator program and it was XP themed. At least I know it works.
.
-
I added the Luna XP theme to Wine from my XP VirtualBox. This allowed my XP manifest to work with VB5CCE under Wine.
.
-
Calling properties and methods of OLE (= ActiveX) objects (= VB and C# controls) from an inproc (= DLL) server is exactly what "OLE automation interface" stands for.
The following was found in my Wine VB5CCE .vbp project file.
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\windows\syswow64\stdole2.tlb#OLE Automation
-
1. Exactly which controls failed to install under Wine?
2. Of course it may happen that there would be no such a path under Wine as shown in your last message. I'm currently under XP and not very eager to reboot for investigation. Have a look into your Wine's \system32 folder to see if there's an equivalent to stdole2.tlb there (that's an OLE types library). If not then try to copy one from your XP installation. Then start your VB5CC, open some new (template) project, goto Project->References, click the Browse button, navigate to your Wine's \system32, and select the stdole2.tlb that you copied there.
You can try to do the exact same thing with the two controls that failed to register, but going along the Project->Components route this time.
The main idea is that when you add a reference to a TLB or OCX to a VB project in this manner, the respective module gets registered in your system automatically if it wasn't registered before. I think Wine should be able to mimic this behavior otherwise it won't be able to run applications of the MS Office family, which it is.
-
I don't have much interest in getting COM working on Wine. I tried it out of curiosity and to see how far Wine has come along. I'm working on building a library of VB6 to IUP control conversion routines that could be used by any language in essence.
-
Understood. But just in case...
-
Several weeks ago I exported the type libraries from several of VB6's runtimes and I didn't find anything in them that seemed to be remotely usable or useful. What I was hoping to find but didn't was some programatic access to a way of instantiating such things as VB Forms and its standard controls like text boxes, labels, buttons, etc. What I found instead were various equates and conversion routines. Like I said, nothing immediately useful - at least to me. But perhaps I missed something. If I did, I'd appreciate knowing about it too, as it would provide a whole new approach to converting VB6 code. In other words, what I'm saying, is that instead of using DDT Create Dialog ... or SDK CreateWindow() to create UI elements, just use VB's exported COM interfaces to do this. It would be elegant if it were possible to do that. But like I said, I have not as yet found a way. So assumming its not possible, all that leaves one is doing what you are doing now Stan - or like I did several years back.
Maybe someone should let Fred know about the Script BASIC COM interface and use that as a model.
-
(Or google for the subject to find a ton of relevant links. :D)
-
Or google for the subject to find a ton of relevant links.
On second thought, it's more entertaining to watch these pros expose the clueless side of their egos. Jose Roca seems to be the only one that gets it.