Introduction to Forum

[Gary Beene]

PowerBASIC INC would like to encourage the development of an open source VB-to-PowerBASIC converter. To that end, we're opening up a new forum specifically to discuss issues, code, suggestions, etc. related to achieving that goal.

At one time, there was a private forum on the topic, but based on what we believe is a general interest by the community and based on the recent posts by several forum members showing new interest in the topic, PowerBASIC INC has approved opening up a public forum to help restart the effort.

PowerBASIC INC may participate in the effort by posting comments/suggestions, but leadership on the task rests with the user community.

[Rodney Hicks]

At one time, there was a private forum on the topic, but based on what we believe is a general interest by the community and based on the recent posts by several forum members showing new interest in the topic, PowerBASIC INC has approved opening up a public forum to help restart the effort.

This looks like a perfect candidate for the 'Special Interests' forum!

[Gary Beene]

Hi Rodney,
Yep. I agree. I just wanted to give it a little bit of top billing for a week or so, then I'll move it.

[Rodney Hicks]

That makes sense! I coulda, shoulda, oughta thought of that!

[StanHelton]

OUTstanding!

We can do this!

[Knuth Konrad]

PowerBASIC INC would like to encourage the development of an open source VB-to-PowerBASIC converter.

I would right from the start either restrict that to "VB-to-PowerBASIC non-GUI code converter" or at least split it into two separate projects (GUI/non-GUI).

Reason: when talking about GUI conversion, to which GUI engine should the code be converted? DDT? PBForms, Windows SDK, <3rd party forms engine>

[Chris Holbrook]

I would right from the start either restrict that to "VB-to-PowerBASIC non-GUI code converter" or at least split it into two separate projects (GUI/non-GUI).

I understand your point. Also I see a big question mark over which version of the Windows API to use, PowerBASIC's or Jose Roca's. But I understand from Stan Helton's comments elsewhere that scope creep killed the last attempt. I suspect that there is an irony trap in there somewhere.

I would just go with the flow until serious issues arise. As fr as I can tell, there is not even a roadmap yet!

[StanHelton]

Hello Knuth, Hello Chris,

I would right from the start either restrict that to "VB-to-PowerBASIC non-GUI code converter" or at least split it into two separate projects (GUI/non-GUI).

Reason: when talking about GUI conversion, to which GUI engine should the code be converted? DDT? PBForms, Windows SDK, <3rd party forms engine>

I'll tell you what I'm doing right now. I use PBForms in my own code because it's easier and faster for me. I'm constructing a program that will use DDT in the conversion. It will be open source when I post it here and hopefully the architecture will allow members of the community to add capability for their favorite way of doing things GUI. There is only one restriction we should all agree to up front -- no commercial 3rd party tools in the essential builds. Add-ons later should be okay, but PB and me both agree that we don't want to force anybody to buy anything in order to use this Converter.

Jim Davis tells me he is working on an alternative Base Program so we should have a minimal Alpha up soon, maybe two.

There's no real difference between PBForms and DDT, though, because PBForms generates DDT to paint the windows. As for Windows SDK, somebody else will have to build that part. I can use it, but not well.

I suspect that there is an irony trap in there somewhere.

I would just go with the flow until serious issues arise. As fr as I can tell, there is not even a roadmap yet!

I'm treading water as fast as I can. Seriously, the first task I assigned myself this time was to build a VB6/PBWin10 concordance. It's not yet complete, but I'm willing to post it if anybody is interested. My Basic Alpha is based on this concordance as a simple text to text translation wherever possible.

Hope this helps.
Stan

[James Davis]

Hey guys... just throwing in my two cents. I'm working on just simple converter. One that will pull the following out of a BAS file line by line; Command, Variable, Operation. By getting those 3 things out of the line by itself, it should be relatively easy to do be able to do a straight conversion. Of course you would have to take into account any included DLL/OCX files, but I'm mainly focusing on just straight VB code without all the hassle of included files right now.

By building a database of the variables that are used throughout the code, you should be able to just do a simple conversion. I'm still working on it mind you, but I feel like that would be the best way to go so far.

The main objective here is to be able to take a piece of VB code, run it thru the converter and it will be able to run in PB. Now mind you, I'm sure there are faster ways of doing things but we need to start simple and let it grow from there. For my first bit of code, I'll be happy if I can take a basic VB file (with no included DLLs/OCXs) and parse it out to port it over to PB.

After that, I'm sure that there are ways to include the VB DLL/OCXs directly into PB so that they can be used (yes, they are slower, and yes they would be klugdy... but the objective is that it would work in PB).

After that, making the conversion replace those included files with faster, run-time PB includes that would replace all those nasty VB includes and simulate them in a better and faster manner.

So basically that's what we're going for here. Something that works... it doesn't even have to work well... as long as it does most of the hard stuff that would make for a pain in manual conversion (like taking all the global declaration and putting them inside the PBMAIN() sub) would be a major help. Its just a matter of building on a framework that will be ever evolving and everyone will have the opportunity to add to it to make it better.

Think about this... if we can make something that would allow all the abandoned VB programmers port their existing code over to PB then we'll expand a userbase, infuse fresh talent into our community and show that PB is something to contend with. We all know the power of this langauge, now I think it's time we prove it to everyone else and let them see for themselves just what PB can do! So what does everyone think of that idea?

-=> Jim! <=-

[Wayne Suite]

Conversion

Umm ... VB is Visaul Basic the Visual part being Form based GUI. The actual VB Code theoretically can be easily ported to other basics. The first thing you develop or even see when you run or make a VB program is the GUI interface.

Therefore it only makes sense to me that you delveop the form conversion 1st and foremost based upon the form tools available in the creation of the standard tools for VB form development.

Once the form is converted (which most likely will be the hardest part) then the VB Code will port fairly easily I would think.

At least this is what the abandoned VB Conversion project attempted to accomplish.

I would think the 1st and foremost thing for conversion would be the GUI form interface which VB programmers have come to rely upon for quick GUI development of the projects.

Very few VB programs are written as console apps or apps without being form based.

Then there is the question of whether you convert the .NET VB or the VB6 programs or try to do both.

You cant please everyone ... So someone/group needs to establish clear cut NON-DEVIANT goals for the project before anything in related to conversion gets done.

If I recall correctly at the end of the previous defunct VB Conversion there were some useful conversion actions created which worked somewhat.

Just my 2 cents...

Wayne.

[Wayne Diamond]

Wayne, such translations are a very difficult task.

Here is my attempt from back in 2000, when I was transitioning from VB to PB ...

http://www.powerbasic.com/support/pbforums/showthread.php?t=023022

I haven't seen any translations since that have been any better -- 14 years later.

[StanHelton]

You are absolutely correct when you talk about the expectations of the VB programmer. Without an effective GUI we won't get any of them.

On the other hand, without an effective engine under the hood, we won't have anything to offer even if we do the GUI 100%.

My 2 cents on VB's GUI output:

PB is better and easier once you know how to use it.

The only thing we need to get out of .FRX file is the images. They are all bitmaps if I remember. The header is only about 128 bytes. Conceptually to my way of thinking, this huge problem is only a huge problem if we tackle it before we're ready. Yes, it is probably one of the most important to the end user, but the tools are there in PB. Here's my algo -- from the code figure out what VB is doing with an image; pull the image out of the frx file; stick the image into the PB code at the appropriate place. But I'm nowhere near ready to write that code right now because a pretty GUI that doesn't do what it's 'sposedto ...

We don't want to beat ourselves to death trying to do difficult things when we haven't done the basic foundations. That glorious VB GUI sits on top of MS' BASIC interpreter with dependencies on MS C compiler, among other things. Most of the strangeness in VB is due to the fact that it is an INTERPRETER for MS C.

Suggested Goals (The way it looks to me):

1. Code translator that works mostly. (Alpha 0.01)

2. GUI translations, not necessarily looking anything like VB, but clear, nice, and effective. (More alphas)

3. Beta versions of the Converter. (new goals based on what we have and where we can go with it)

4. Production versions.

5. Then we tackle dotNET.

6. We all die and go to heaven with lots of money in our pockets.

[Knuth Konrad]

Umm ... VB is Visaul Basic the Visual part being Form based GUI. The actual VB Code theoretically can be easily ported to other basics. The first thing you develop when you [...] make a VB program is the GUI interface.

I strongly disagree with that statement and even go so far to claim that this design approach resulted in the code mess that gave/gives VB the bad reputation it has.

The GUI is one of the last things I code. Also, each control event is basically just a one line wrapper for the procedure/method which does the actual work.

If there's a "pretty decent" non GUI code only VB6->PB converter available, you could happily leave the VB6 programmer with his superior IDE (compared to DDT or PBForms) and provide him with the power of PB's compiler as the real work horse underneath.

[Michael Boho]

I moved from VB to PB almost 3 years ago. I bought PB Forms in addition to PBWin. Tried Forms, then PBWin directly without Forms.
Worked fine. In migrating from VB, I relearned on thing. If you want to swim, you gotta jump in the water.
Jump in! The water's fine!

[John Petty]

I tend to agree with Michael. I own every version of VB from 3 to 6 and even the rare VB1 for DOS. Started with PBDLL1.01 but since buying PB Forms 1 and PBWIN7 I gradually stopped using VB altogether other than to support existing products.
For me the hard part of converting was coming to grips with implementing the unique features of VB particularly Events. Thanks to the code skeletons PBForms wrote i found that a VB Event for a control was simply a matter of recognising the appropriate message in the callback and responding to it.
So two points
First all I could find on this site at that time was a continual reference to some great book about how Windows works which I had neither the time or interest to read. What I couldn't find and still can't is an explanation (with simple examples) of how to replace this key feature of VB in PB. Which brings me to my second point.
Converters don't teach, so simply producing a converter will just result in programmers asking why bother? So along with teaching how to convert should be description (along with simple examples) of the advantages of PB. Example in VB which was effectively single threaded, kludge apartment, the dreaded white screen was common so one inserted the DoEvents kludge in multiple places and that didn't always work. PB these days is of course truly and simply multi-threaded yet even now I see posting of the old kludge equivalent of DoEvents from the days when it really wasn't simple and no description and simple examples of what this powerful feature and how to use it means.

[StanHelton]

Clearly and upfront, a successful Conversion Program is one of the best possible teaching tools when it meets the threshold for a Production Version.

So two points
First all I could find on this site at that time was a continual reference to some great book about how Windows works which I had neither the time or interest to read. What I couldn't find and still can't is an explanation (with simple examples) of how to replace this key feature of VB in PB.

I started with GWBasic, QB, and BASIC7. When TurboBasic 1.0 happened there is no word for the joy in my heart. For a time I tried to do both VB and PB, until I realized that there's absolutely nothing in Visual over which the programmer has actual control. There's nothing like PB for getting the program to do what you want it to do.

Michael said it. You agreed, and so do I -- jumping into the deep end is the quickest way to learn -- or to give up entirely.

Which brings me to my second point. Converters don't teach, so simply producing a converter will just result in programmers asking why bother?

On this point I disagree. For the veteran PBer it's a time-saver first and foremost. For the VBer who wants something better it certainly can teach, and well. The manuals, the 3rd party books, the articles are helpful, but I think folks with programming experience learn quickest by reading the code!

So along with teaching how to convert should be description (along with simple examples) of the advantages of PB.

Right now the immediate goal is to get an Alpha that runs. After that we'll make it better with each iteration. The teaching can happen in these ways: 1st) the old reliable MSGBOX; and 2nd) comments added to the output source where the VB refugee can see code and explanation together; and 3rd) The VB code and the PB code can be viewed together -- the programmer knows what his code did and he can see the PB code that does the same thing.

Example in VB ... the White screen was common so one inserted the DoEvents kludge in multiple places ... PB these days is of course truly and simply multi-threaded yet even now I see posting of the old kludge equivalent of DoEvents ...

DoEvents is a good example, and not the only one. PBWin 10 is so powerful in it's message handling that I am sometimes surprised to see folks using SDK even.

... and THAT may be the best part of the Conversion Program. With the learning comes the knowledge that the old kludges are no longer necessary.

[Chris Holbrook]

Does a benchmark VB6 app exist for this project? Or a series of same?

[StanHelton]

As I remember there were a couple Proof of Concept apps. I will look through the older project code and post it if I can find it.