VB Form Conversion

[John R. Heathcote]

Wayne,

Why not provide an option box and let the user decide which way to do the conversion.

This would be one way to do it, another would be through the "OPEN" file command (single file conversion), or through the "OPEN PROJECT" command (project conversion). The latter is what I've opted for as it keeps the setup functionality separate from each other by design.

When offered a choice BOTH options is ALWAYS a better choice then this one or that one

This was my thought too.

Rod,

I would carry on with this if I were you, we're going to need it and with it some of the other little wiggly issues may fall into place a little better. I can't see how we can make the full project converter without this stuff, and that is our main goal.

Will do. Just wanted to check in with the group with my efforts so far.

[Wayne Suite]

Conversion

Why not provide an option box and let the user decide which way to do the conversion. This will provide the most flexibility based upon the complexity of the project to convert. This will also allow you to develop the file conversion aspect first then when satisfied with its results check the box allowing full conversion automatically. Both could be developed at the same time allowing you to start with the file conversions then just partially code the full conversion and test it as the file conversions/project conversion proceeds to maturity.

When offered a choice BOTH options is ALWAYS a better choice then this one or that one

[Rodney Hicks]

John,

The first method is to scan the VB Project file (.VBP), gather up the necessary data from this file and set up the conversion accordingly,

Funny that you should be posting this now. I was having similar thoughts as I perused just how to set up my Diagnostic app.

The second method is to allow the user to convert VB files on a file by file basis by simply loading a particular file in the editor and running the Tokenizer.

This is a good idea, to have the option to go whole project, selected file. While attempting to figure out what goes on in a VB app, I've noticed that some of the stuff would convert rather quickly, and really doesn't even need the much of the Visual component. Almost a cut and paste into a new PBForms layout even.

I am in the process of coding the project related stuff right now. I didn't want to get too far into my project coding efforts if this isn't a direction the group wants the converter to take.

I would carry on with this if I were you, we're going to need it and with it some of the other little wiggly issues may fall into place a little better. I can't see how we can make the full project converter without this stuff, and that is our main goal.

Just for clarification, I am using a list of seven file extensions VBP, FRM, CTL, CLS, BAS, BI, INC. I have not actually encountered a BI or CLS yet in my studies but Stan had it in his list so I included it in mine. Are there any others we should be aware of(text type)?

[John R. Heathcote]

To All:

While attempting to deal with the VB files at a project level I came to the realization that there will be two basic conversion methods where the level of automation will be somewhat different from the other, but nothing the user will not be able to handle.

The first method is to scan the VB Project file (.VBP), gather up the necessary data from this file and set up the conversion accordingly, create PB files, fill in the blanks, etc. The .VBP file provides a basic starting point via a start up form or Main() procedure from which to begin building the conversion for the project. It should also be possible to order the files to be converted so the entire VB project could be converted at once. This option could be highly automated, or be a user defined option. I see this option being used to create a basic framework of PB files that would be compiled to a complete application.

The second method is to allow the user to convert VB files on a file by file basis by simply loading a particular file in the editor and running the Tokenizer. This option is less automated requiring more interaction from the user, but would be more flexible and provides the user more control opver the conversion process. This method allows the user to convert files from a variety of locations. I view this option being used to convert a limited number of VB files to be used in another project.

I can see advantages and disadvantages to both scenarios, but I would like to get your feedback on this issue as I am in the process of coding the project related stuff right now. I didn't want to get too far into my project coding efforts if this isn't a direction the group wants the converter to take.

[Rodney Hicks]

From those figures we should be able to create a conversion ratio to use. Nifty idea to use WinSpy.

[Wayne Suite]

Code from PBWINSPY 1.17 for VBTESTFORM

Most interesting, most of it is the same just a line or two initially is different.

PBWINSPY 1.17 DDT Code for TESTFORMVB

  DIALOG NEW 0, "Dialog1VB", , , 447, 261, _
              %WS_VISIBLE OR %WS_CLIPSIBLINGS OR %WS_CLIPCHILDREN OR %WS_CAPTION, _
              %WS_EX_APPWINDOW OR %WS_EX_WINDOWEDGE TO hDlg
  'Note: in PB/WIN 7.0 and later, you can also use DIALOG SET ICON hDlg, newicon$
  'For icon from resource, use something like, LoadIcon(hInst, "APP_ICON")
  DIALOG SEND hDlg, %WM_SETICON, %ICON_SMALL, LoadIcon(%NULL, BYVAL %IDI_APPLICATION)
  DIALOG SEND hDlg, %WM_SETICON, %ICON_BIG, LoadIcon(%NULL, BYVAL %IDI_APPLICATION)

PBWINSPY 1.17 SDK Code for TESTFORMVB

 hDlg = CreateWindowEx(%WS_EX_APPWINDOW OR %WS_EX_WINDOWEDGE, szClassName, "Dialog1VB", _
              %WS_VISIBLE OR %WS_CLIPSIBLINGS OR %WS_CLIPCHILDREN OR %WS_CAPTION, _
              (GetSystemMetrics(%SM_CXSCREEN) - 677) / 2, _
              (GetSystemMetrics(%SM_CYSCREEN) - 450) / 2, _
               677, 450, 0, 0, GetModuleHandle(""), BYVAL %NULL)

[Wayne Suite]

Testform DDT / SDK Code as generated by PBWINSPY 1.17

I thought it was also interesting to compare the PBWINSPY v1.17 code generated in both DDT and SDK for the same TestformPB application. Here is what it created.


PBWINSPY 1.17 DDT STYLE CODE FOR TESTFORMPB

DIALOG NEW 0, "Dialog1PB", , , 447, 261, _
              %WS_POPUP OR %WS_VISIBLE OR %WS_CLIPSIBLINGS OR %WS_CAPTION OR _
              %DS_3DLOOK OR %DS_NOFAILCREATE OR %DS_SETFONT OR %DS_MODALFRAME, _
              %WS_EX_DLGMODALFRAME OR %WS_EX_CONTROLPARENT OR %WS_EX_WINDOWEDGE TO hDlg
  'Note: in PB/WIN 7.0 and later, you can also use DIALOG SET ICON hDlg, newicon$
  'For icon from resource, use something like, LoadIcon(hInst, "APP_ICON")
  DIALOG SEND hDlg, %WM_SETICON, %ICON_SMALL, LoadIcon(%NULL, BYVAL %IDI_APPLICATION)
  DIALOG SEND hDlg, %WM_SETICON, %ICON_BIG, LoadIcon(%NULL, BYVAL %IDI_APPLICATION)

PBWINSPY 1.17 SDK STYLE CODE FOR TESTFORMPB

  hDlg = CreateWindowEx(%WS_EX_DLGMODALFRAME OR %WS_EX_CONTROLPARENT OR %WS_EX_WINDOWEDGE, szClassName, "Dialog1PB", _
              %WS_POPUP OR %WS_VISIBLE OR %WS_CLIPSIBLINGS OR %WS_CAPTION OR _
              %DS_3DLOOK OR %DS_NOFAILCREATE OR %DS_SETFONT OR %DS_MODALFRAME, _
              (GetSystemMetrics(%SM_CXSCREEN) - 677) / 2, _
              (GetSystemMetrics(%SM_CYSCREEN) - 450) / 2, _
               677, 450, 0, 0, GetModuleHandle(""), BYVAL %NULL)

It will be interesting to see if PBWINSPY 1.17 generates the same code over the TESTFORMVB application since they are both the same.

[Rodney Hicks]

Bringing some more joy to the aspect of twips/pixel/dialog unit fun is the following style for DIALOG NEW

%DS_SETFONT
The font to be used by a DDT dialog and its controls can be predetermined with the DIALOG FONT statement. If the DIALOG FONT statement is not used, the default font (MS Sans Serif, 8 point) is used. The size of the dialog font proportionately affects the conversion of dialog units values into pixels, so an increase in default font size will automatically create a larger dialog, even through the dialog dimensions have remained constant. As child controls are added to a %DS_SETFONT dialog, they will be sent a %WM_SETFONT message to ensure they also make use of the specified dialog font. DDT dialogs are always created with this style. (default)

This may also be true of VB, I do not know.

[Rodney Hicks]

Wayne

Very nice. The size (W x H) gives a pretty direct correspondence that we can use for a base.
Ratios: (Dialog units)
Height 6360:261-----24.37:1
Width 10065:447----22.g2:1
Ratios: (Pixels)
Height 6360:424------15:1
Width 10065:670-----15:1

When I checked the MSDN the term StartUpPosition said that 3 was x=0, y=0 therefore one question, does the inclusion of values for 'ClientTop' and 'ClientLeft' override the StartUpPosition? Not important just yet, just curious.

I think too that the LinkTopic= "Form1" is a rough equivalent of %IDD_DIALOG1
I don't understand why ScaleWidth and ScaleHeight are needed if the window isn't resizable so I assume that it puts them there, needed or not.

Nice job, since I don't have VB I couldn't do dat.

[Wayne Suite]

PB and VB Identical Files with sources for comparison

Ok, I had a few minutes tonight so I created a PB Form using PB Forms and a VB Form using VB on the same screen and made sure they were the EXACT same size the same verbage, look and behave exactly the same.

This means if you execute each .exe they will be identical - this also means you will have to call task manager to close the application when done.

Then I gathered the corresponding text sources the .vbp/.vbw files and pb files and zipped up each in its own zip file the name is TESTFORM1 with PB or VB added to the end to indicate which is which.

So here they are. I have not analyzed any of the info just made sure both were exactly the same. When I used PBFORMS I did not make any changes to the default settings that were set when PBFORMS was installed so whatever they are they are.

Hope this helps someone.

[Brian Chirgwin]

This is true if scalemode is twips. If scalemode is pixel (confirmed), decimal pixels are allowed.

Of course, 100.4 is at positioned 100 and 100.5 (value changed to 100.533) is at position at 101.

Brian,

I seem to remember that form/control values for location and size are rounded up/down to the nearest integer, at least the values that show up in the various property windows.

[Rodney Hicks]

A couple of points, and I think that we should all try it our own way so we work to common ground.

I for one am in favour of just using a conversion factor, whether to pixels or dialog units, and I favour dialog units at the moment. This is sorta like liking blonds until a hot red head comes along.
In other words let the user make the adjustment as long as the controls, pictures, etc are all within the window dimensions(both in the VB code and the PB code), spaced relatively with the ratio used for conversion. This doesn't sound too clear, but the idea is to get everything close to original intent.

I happen to think familiarity is very important for the newly converted VB user.

This will work against the user if the user is anything like me. I think they need to see how the new and different(PB) creates something similar to the familiar old.

It seems that we've ventured to become teachers, gurus, instead of just converters. This may be natural progression.

[John R. Heathcote]

Brian,

You make some good points. I'm glad there is a VB guru on board to help us point out and answer these questions.

In VB, Left, Top, Width and Height are of the single datatype allowing decimal values. Therefore, it is possible to place something at 15.571 pixels. It looks like VB converts everything to twips (1440 per inch). Of course, in the end the form/control will place at 15 or 16 pixels. But which does VB chose?

I seem to remember that form/control values for location and size are rounded up/down to the nearest integer, at least the values that show up in the various property windows.

The possible "error" that has been discussed previously between VB and PB is that VB can perform the calculation from Pixels to Twips (Twips to Pixels) in a number of ways. Depending on the math used, certain rounding errors are introduced. Does VB use Dialog units internally (hiding the details from the user like many other things VB hides).

Good question, I don't know.

Simply put, VB has the capability to perform these calculations. PB does also. The issue is can the calculations VB performs and the calculations PB performs produce identical results. If the calculations are off the result will be off +- a pixel. Potentially more if the "error" is compounded. Even if VB calculates with errors, the converter will need to produce the same errors.

I, for one, would be glad if the converter could get the form/control locations and sizes within +/- 1 pixel after conversion, this is close enough for me. I think what we are really after here is to get a fairly close, but not exact, representation of a VB form in PB as long as our math does not produce something visually that is totally outrageous.

I am not sure which is the best way to proceed. Do we convert to Dialog Units or does the converter use twips and dynamically convert at runtime...

All we are going to have access to are the VB .FRM and .VBP files and whatever unit of measurement that is contained in those files are the same ones we will be stuck with to use in our conversion. I think all we can reasonably do is generate a close approximation of a VB form and we will have to be satisfied with that. As I mentioned before VB 5.0 and VB 2008 appear to use pixels as a base measurement, whereas VB 6.0 uses twips. Right there is another factor that will complicate our conversion too.

...The answer to this has nothing to do with continuing to use VB and re-convert a form. It has to do with what makes easier code to work with.

Agreed.

On the other hand a seasoned PB developer, that may not know VB, might like everything converted to Dialog Units. This isn't clear though as the code might be difficult to follow as weird values are introduced that don't make sense even to a PB developer.

Before we tackle this issue I would suggest that we get a working VB form conversion using pixels, before we branch out to other forms of dialog/control units and user options.

Currently, I think it is better to keep the new VB developer familiar. I may be biased though as I know VB better than I know PB. Maybe the solution is just some documentation about differences between VB and PB.

I happen to think familiarity is very important for the newly converted VB user. I don't think it is a good idea to bombard them with culture shock all at once of the PB way of doing things.

Anyway, just my thoughts.

[Brian Chirgwin]

One of the things I plan to do this weekend if time permits

Why not try both ways and see which one looks CLOSEST to the original result and use that way?

[Wayne Suite]

I am not sure which is the best way to proceed. Do we convert to
Dialog Units or does the converter use twips and dynamically convert at
runtime. The answer to this has nothing to do with continuing to use 
VB and re-convert a form. It has to do with what makes easier code to
work with.

Why not try both ways and see which one looks CLOSEST to the original result and use that way?

[Brian Chirgwin]

Twips are always 1440 per inch in both X/width and Y/height. Twips are a nice unit to deal with because of the control and use in both screen and print. In print where resolution is 300 dpi or higher. Screen is usually 72 or 90 dpi depending on screen size. The user has the ability to set up custom size as well, but most users don't. (Note: I am not sure if there is a difference internationally).

Pixels per inch vary depending on the size of your screen. VB has the function TwipsPerPixelX/Y which varies depending on screen size/resolution. On my screen, I get TwipsPerPixelX=15, TwipsPerPixelY=15.

Dialog Units vary depending on the size of the Dialog Box Font being used, which is usually 8-point MS Sans Serif. The user has control over this font though. For instance (unconfirmed), if the user uses Large Font option, this changes the Dialog unit scale. http://support.microsoft.com/kb/145994/en-us
It looks like PBForms always the same font (8-point MS Sans Serif) for its calculation of Dialog Units. At least changing the font size does not change the number of DUs displayed in PBForms Size tab.

In VB, Left, Top, Width and Height are of the single datatype allowing decimal values. Therefore, it is possible to place something at 15.571 pixels. It looks like VB converts everything to twips (1440 per inch). Of course, in the end the form/control will place at 15 or 16 pixels. But which does VB chose?

The possible "error" that has been discussed previously between VB and PB is that VB can perform the calculation from Pixels to Twips (Twips to Pixels) in a number of ways. Depending on the math used, certain rounding errors are introduced. Does VB use Dialog units internally (hiding the details from the user like many other things VB hides).

Simply put, VB has the capability to perform these calculations. PB does also. The issue is can the calculations VB performs and the calculations PB performs produce identical results. If the calculations are off the result will be off +- a pixel. Potentially more if the "error" is compounded. Even if VB calculates with errors, the converter will need to produce the same errors.

The complications include:
* Are Dialog units used internally.
* The Left, Top, Width, Height, "Single" values converted to another data type for calculations. Is it possible for performance that these values are converted to Longs *1000 (move the decimal place and truncate/round).
* How many decimal places are significant?
...

As also mentioned, VB has ClientWidth and ClientHeight calculations. This takes into account spacing for menus, scroll bars, with of borders, etc... These may also produce differences between VB and PB. It was pointed out that PB generated a form with -Y values.

I am not sure which is the best way to proceed. Do we convert to Dialog Units or does the converter use twips and dynamically convert at runtime. The answer to this has nothing to do with continuing to use VB and re-convert a form. It has to do with what makes easier code to work with.

For a VB developer new to PB the converter should not throw code at them that looks like nothing they are familiar with. Do this and it insures that the VB develop will continue to develop in VB and re-convert.

On the other hand a seasoned PB developer, that may not know VB, might like everything converted to Dialog Units. This isn't clear though as the code might be difficult to follow as weird values are introduced that don't make sense even to a PB developer.

Currently, I think it is better to keep the new VB developer familiar. I may be biased though as I know VB better than I know PB. Maybe the solution is just some documentation about differences between VB and PB.

Maybe the solution is to give a choice.

If I have time this weekend I'll create a project that will answer a lot of questions.

Decisions, Decisions...

More fooforaw on these twips, twips to pixels, twips to dialog units.

If there are 20 twips per pixel horizontally, are there 20 twips per pixel vertically.
Dialog unit=1.50 pixels horizontally, 1.625 vertically.
Does this dichotomy apply to twips?

[Rodney Hicks]

More fooforaw on these twips, twips to pixels, twips to dialog units.

If there are 20 twips per pixel horizontally, are there 20 twips per pixel vertically.
Dialog unit=1.50 pixels horizontally, 1.625 vertically.
Does this dichotomy apply to twips?

[John R. Heathcote]

Rod,

Would we not be making the converter a tool for development rather than conversion?

Not necessarily. The problem is how to bring the equivalent VB functionality over to PB, so the converted app gives the user the correct answer. To do that we have to delve deeper into the workings of VB IMO.

What I mean here, wouldn't such a capability encourage users to continue to program in VB6 then convert?

No, I don't see that at all. I can't speak for the other "former" VB'ers, but I wanted to know how to convert my VB code over to PB. I knew there were differences between the two languages. I knew PB interfaced with Windows at a lower level than VB did. But most of all, I wanted an example of how to do VB the PB way and was frustrated by the lack of examples and the overall research I had to do to even accomplish something simple, such as, how to respond to a simple button click.

I would've loved to have the converter to use as an example of how to do things in PB, something I could emulate in my next PB app, something that provided most of the answers under one bonnet (as the British say), and something I could expand on at my leisure. I made the decision to use and learn PB from that point forward, I think other users will do the same. Having said that, there will always be those who don't wish to learn PB, who will always use our converter as a panacea for their reluctance (and laziness?) to learn something new, and the simple fact is we never will to stop this from happening.

I myself don't understand the value of these 'containers', and have never needed anything like what I understand them to be while programming in PB.

Containers provide a convenient way of dealing with controls as a group without defining them as such. The best example I can use to illustrate the concept is the Tab control. In VB you can use the individual Tab control pages as a container to associate a group of controls to a specific Tab control page. The container controls what is displayed when you click on an individual tab. This is more convenient than having to keep track of the controls on each tab page and showing/hiding them individually as PB forces you to do.

[Rodney Hicks]

Quote:
I disagree as most VB applications use some third party controls (OCX) that do not load properly in PB Forms. PB Forms visual editor is limited as it doesn't work with these OCX controls. It also doesn't provide container type functionality (i.e. frames, panels picture boxes in VB are part of the container. Move the container and these controls move as well). I think as part of the converter framework. (Maybe this is beyond converter functionality. Still, I'd like to take the best features of VB and keep them):End Quote

Yeah, I know these types of controls will be a problem, perhaps if these same .OCX files have a type library maybe we could use PB 9.0 object interface? Just a thought. You and I are probably the only two individuals in existence in the PB community that think VB had some good points too. And I do agree it would be nice to bring those positive aspects of VB over to our converter.

Bringing these "positive aspects" to PB may mean letting the converter convert to what PB does, then using PB to create what is desired. This sounds more like an add on to the PBForms than a conversion issue, even though it might be stuffed into the converter.

Would we not be making the converter a tool for development rather than conversion? What I mean here, wouldn't such a capability encourage users to continue to program in VB6 then convert?

I myself don't understand the value of these 'containers', and have never needed anything like what I understand them to be while programming in PB.

I realize that I'm interjecting a PB attitude into the discussion of this VB feature, but it is amongst my goals to help VBers get accustomed to doing things the PB way rather than the VB way, since VB has gone the way of DOS, DODOS, and MY_YOUTH.

[John R. Heathcote]

Brian,

I agree that a visual editor would be nice and using PBForms is a big plus as a visual editor. I think it would be short lived though.

I was thinking more of a short term solution myself, as I said it was early this morning when I typed my reply. I'm trying to keep in mind the fact that many who are using our converter will probably be the user's first exposure, or have limited exposure, to PB. In this case there are tools at hand to do the job graphically, even if it is somewhat limited in scope.

I disagree as most VB applications use some third party controls (OCX) that do not load properly in PB Forms. PB Forms visual editor is limited as it doesn't work with these OCX controls. It also doesn't provide container type functionality (i.e. frames, panels picture boxes in VB are part of the container. Move the container and these controls move as well). I think as part of the converter framework. (Maybe this is beyond converter functionality. Still, I'd like to take the best features of VB and keep them)

Yeah, I know these types of controls will be a problem, perhaps if these same .OCX files have a type library maybe we could use PB 9.0 object interface? Just a thought. You and I are probably the only two individuals in existence in the PB community that think VB had some good points too. And I do agree it would be nice to bring those positive aspects of VB over to our converter.

I think it would be nice to have a visual editor that works better than the VB editor works. I know this isn't all a version 1 of the product, but I think the vision of the finished product (at least in my mind).

Yes, this would be nice and I would like to have it myself, but it is definitely way down the version road.

I am not saying we will be able to make a complete replacement, but I am confident we can create some commonly used controls.

Again, I agree.

My source code template idea was born out of the necessity of having a library of common controls that we can plug in to the converted VB code whenever and where ever we want. Grids will be interesting to deal with, I know James Klutho has a free version of MLG, perhaps we could use that as our grid control, giving proper credit of course. I know from personal experience using the VB MSFlexGrid control is very similar to the common Windows ListView control. We may be able to simulate most of the MSFlexGrid features by making it an OWNERDRAW control, that too, is for future versions, but it doesn't hurt to talk about these things now.