VB6 Objects, OCX, & DLL

[StanHelton]

It's me asking for input again.

This time I've reached a decision point that has, I think, implications for the entire project. It involves the use of VB6 DLL & OCX files. I've spent the last couple days looking over Jose Roca's forum and the work he has done is quite impressive. Jose seems to have solved most of the problems associated with using VB6 components in PowerBASIC programs.

My own approach at the beginning has been to simulate VB6 features with PB equivalents and/or close approximations. To that end I am building a super CLASS designed to handle controls and produce these equivalents/approximations. So far it contains 127 properties, the associated GET/SET methods, and two separate interfaces. It is incomplete.

Some of you have suggested from the beginning that the Translator should produce PB code that uses the OCX/DLL files from VB6. When I study Jose's code I see that he has already solved the problem for many of these.

The delimma:
Should the Translator produce PB code that may be an approximation versus producing PB code that uses VB6 resources?

My way the enduser requires only the source files associated with the VB6 project being translated.
Jose's work seems to require the presence of the OCX files.

The Translator should produce PB source code that compiles, runs, and does the same job the VB source did before. So far, when folks describe to me why they like a particular VB component, my first inclination is to write a template for that functionality into either my super CLASS, or a dedicated CLASS template. (Neither the super CLASS nor the dedicated CLASSes would appear in the final output.)

I have to ask because either way is going to take some time. Producing output for both options will take that much more time. To me the essential goal is to bring VB refugees to PB and keep them with an end product that can do the translations and help teach new PBers.

It's not an easy question for me. I definitely need to hear suggestions and discussion. Either way, it will be a lot of work. Either way, the other tactic can be added after the chosen tactic is successfully implemented.

[Mike Simmonds]

My personal preference is to produce PB only functionally equivalent code
with ZERO dependencies on [possibly copyright, possibly missing] VB6
runtime, ocx, etc.

There should also be a 'frx' ripper to recreate icons, cursors, bmps, initial
text etc. etc. E.g. [Icon = "Ddx.frx":0000] could be translated to
[#Resource Icon id "file.ico"] with file.ico extracted from the frx.

Last time I looked, the format of the frx file was quite simple
[but I never actually got around to writing a ripper] ...

[<byte length><embedded resource>]...

Anyway, that's me.

Regards, Mike

[Knuth Konrad]

My way the enduser requires only the source files associated with the VB6 project being translated.
Jose's work seems to require the presence of the OCX files.

That depends ...

First, I'd split the COM/OCX files in two separate categories: Those with a (end user) UI, like the MS Flexgrid and those without, like for example Winsock.ocx.

The later are most likely candidates that can completely be replaced with PB/Win32 API code only.

As for those OCX with a user interface: if it's not something really trivial (=could have been done without the OCX in VB6 in the first place), you're gonna need the OCX anyway sooner or later. So make it a requirement for the converter that the OCX is present and go down the "José way". I doubt that its a viable attempt to provide a fully functional rewrite of, say - ComponentOne's VSFlexGrid or TrueDBGrid are something similar complex.

[Steve Ten]

Don't forget, controls in VB6 are basically of 3 groups:

1) Intrinsic Controls - the ones that are part of the VB6 IDE - you'll need to do PB equivalents of these.

2) Microsoft OCXs - Controls that could have been intrinsic controls but weren't (because of 'historical accident', timing, or whatever).
Most of these would probably be better as written as PB equivalents.
Often these are just calls to the Windows API. (As Knuth Konrad says, these could have been done without OCXs in the first place)

3) Third-Party OCXs - technically no different to Microsoft OCXs, but written by third-parties, typically commercially, often far more complex. It is probably not practical to develop PB equivalents.
For these you need to support OCX/ActiveXs. There could be licensing issues, but typically a VB6 developer would have licenses for any OCXs used.
There are (or were) literally thousands of these OCXs, the only viable option is to support them as OCXs.

This should prove useful:
http://www.vbforums.com/showthread.p...ommon-controls)
Here many (but not all) of the Microsoft controls have been rewritten in VB6. The source code is downloadable. Having the VB6 IDE would be an advantage in understanding this.

In practice I think I am saying that intrinsic controls and the simpler OCXs (that just call Windows APIs) should be rewritten as PB code, but that the more complex OCXs need to be supported as OCXs.

[Knuth Konrad]

Stan,

you might also be interested in Olaf Schmidt's work:

Olaf's explanation of what it does
vbRichCient.com (project website)
GitHub of the widget part of it. Perhaps be the most useful part, showing how he handled the rewrite of VB controls.
Cairo graphics engine

[James Davis]

I have to agree with Steve. I think that if you attempt to rewrite every single OCX in PB, you're talking a lifetime of work. I believe that most of the commands that VB uses can be rewritten in PB, there will always be some that were just plugin add-on OCX/DLLs that were hardly ever documented and hardly ever used. So you should implement some sort of PB inclusion of VB OCX/DLL in the conversion for things that you wouldn't commonly find in the VB langauge. That would be your best bet in the long run!

[Neil Prichard]

I would go the support for OCX route.

Sure, if you can rewrite some smaller better code to do same job as OCX that's fine too. But as there will be many OCX's that you have not yet come across or have not even a sample of, the best route would be to provide generic support for OCX's and DLL's.

I would think that the main tripping point would be the support for the UserControl and creation of custom OCX's which many people used VB6 for.

If you have specific controls in mind that are huge and cumbersome, then by all means ask the forum for help and get some of these coders creating small Powerful replacements in PB that are easy for you to use for translation purposes.

[Michael Mattias]

> So far it contains 127 properties

Just one guy's opinion, but that does not sound terribly user-friendly. It sounds geeky.

Then again, users of this 'source code modification' software will primarily be, well, geeks.

[StanHelton]

> So far it contains 127 properties

Just one guy's opinion, but that does not sound terribly user-friendly. It sounds geeky.

Then again, users of this 'source code modification' software will primarily be, well, geeks.

Aren't we all.

Seriously though, the discussion has shown me another possibility. I've discovered the PB Com Browser produces INC files awfully close to what would be necessary for a functional translation provided the enduser has the necessary OCX files. I've also noticed that the ComBrower INC file for ComCtl32 is very similar to the WinAPI ComCtl32. Many of the CALLs have the same or similar names. Exploring the differences. Am I looking at the difference between OCX wrappers and SDK inc files here? I know a lot of the DDT stuff is calling the WinAPI.

You do a lot of SDK (I don't so much). Do you know how close the end result would appear using these INC files? (ComBrowser vs. WinAPI)

[Michael Mattias]

> Do you know how close the end result would appear using these INC files?

???

The INC files generated by the PB COM Browser have many many user options and may not look like anything else anywhere if you like.

AFAIK, Microsoft has never offered any "pseudo-equivalent" header files for its BASIC language products.

The interface is the interface; it is the responsibility of the programmer to define that interface for use with his/her language development products.

PowerBASIC Inc and Jose Roca have both provided definitions of the "Windows' Flat API" for use with the PowerBASIC products. (not the same; both work; but you already knew that because you read This whine's time has come June 2002)

MCM

[StanHelton]

Guess I misunderstood what you were saying. Nevermind.