VB Form Conversion

[Rodney Hicks]

Separate files affords us the flexibility to include only those controls that actually appear in the VB dialog box in our PB conversion source code, thereby allowing us to customize the conversion of the fly. Separate files would also help keep source code as small as is practical, thus, producing a smaller executable.

This may be a moot point simply because our source code that the end user gets from us is going to have to have the whole nine yards. Whether the converter extracts from one file or several won't make too much difference. The converter will have to either select the right file then search for the term(s) or open a file and search for the term(s). There are about 35 to 40 .INC file that come with PB that are there for almost the same purpose that we need. Just slightly different than what we need.
There is a file for this project already in existence with all the equates found in all the .INC files, but I'm not sure it has all message/notification terms in it. I will look into that.

[John R. Heathcote]

Rod,

I took a look at the file posted by Dave Biggs and it appears to be Windows messages you send to a control. If we already have the equates to define the event messages then a combination of the two files should give us a good start with whatever Windows message we want to send or receive.

This may be a moot point simply because our source code that the end user gets from us is going to have to have the whole nine yards.

Technically, if we extract the relevant callback structure for an individual control from a single template callback file it won't make a difference, you're right about that.

My idea here was to name these PB template files after the VB control name found in the *.FRM file. For example, a PB template file of a VB button would be called "VB-CommandButton", an Option button "VB-OptionButton", Listbox "VB-ListBox". The above 3 template filenames also appear in the *.FRM file so we would be able to tell which template files we would need to include from the *.FRM file. No parsing text/extracting text would be necessary. This would also allow us to throw up an error, or obnoxious comment, if a VB control was not represented as a PB template file.

Also, since our coding effort is to be open source I tend to think we should keep VB control callbacks as simple, direct, and small as is possible, easier to maintain that way. This would also better afford the opportunity to the user by allowing them to add to and/or enhance their collection of PB template files.

Here is an example of a *.FRM file from one of my old VB projects to help put things into perspective. As you can see everything is there, just formatted differently, but certainly not impossible to parse and interpret correctly.

VERSION 5.00
Object = "{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0"; "MSCOMCTL.OCX"
Object = "{BDC217C8-ED16-11CD-956C-0000C04E4C0A}#1.1#0"; "TABCTL32.OCX"
Begin VB.Form frmTinDebug 
   Caption         =   "TIN Debug"
   ClientHeight    =   2112
   ClientLeft      =   48
   ClientTop       =   432
   ClientWidth     =   17556
   LinkTopic       =   "Form1"
   ScaleHeight     =   2112
   ScaleWidth      =   17556
   StartUpPosition =   3  'Windows Default
   Begin TabDlg.SSTab SSTab1 
      Height          =   2112
      Left            =   0
      TabIndex        =   5
      Top             =   0
      Width           =   17556
      _ExtentX        =   30967
      _ExtentY        =   3725
      _Version        =   393216
      TabsPerRow      =   5
      TabHeight       =   420
      TabCaption(0)   =   "Create"
      TabPicture(0)   =   "PbTinDebug.frx":0000
      Tab(0).ControlEnabled=   -1  'True
      Tab(0).Control(0)=   "Label3"
      Tab(0).Control(0).Enabled=   0   'False
      Tab(0).Control(1)=   "Label2"
      Tab(0).Control(1).Enabled=   0   'False
      Tab(0).Control(2)=   "lblNpts"
      Tab(0).Control(2).Enabled=   0   'False
      Tab(0).Control(3)=   "Label5"
      Tab(0).Control(3).Enabled=   0   'False
      Tab(0).Control(4)=   "lblNtri"
      Tab(0).Control(4).Enabled=   0   'False
      Tab(0).Control(5)=   "Label1"
      Tab(0).Control(5).Enabled=   0   'False
      Tab(0).Control(6)=   "Label4"
      Tab(0).Control(6).Enabled=   0   'False
      Tab(0).Control(7)=   "sldrDbgSpeed"
      Tab(0).Control(7).Enabled=   0   'False
      Tab(0).Control(8)=   "lstDebug"
      Tab(0).Control(8).Enabled=   0   'False
      Tab(0).Control(9)=   "cmdInitTin"
      Tab(0).Control(9).Enabled=   0   'False
      Tab(0).Control(10)=   "cmdTin0"
      Tab(0).Control(10).Enabled=   0   'False
      Tab(0).Control(11)=   "cmdGoSeq"
      Tab(0).Control(11).Enabled=   0   'False
      Tab(0).Control(12)=   "cmdSeqPnt"
      Tab(0).Control(12).Enabled=   0   'False
      Tab(0).Control(13)=   "cmdStop17"
      Tab(0).Control(13).Enabled=   0   'False
      Tab(0).Control(14)=   "cmdReset"
      Tab(0).Control(14).Enabled=   0   'False
      Tab(0).Control(15)=   "cmdCancel"
      Tab(0).Control(15).Enabled=   0   'False
      Tab(0).Control(16)=   "optnDim(1)"
      Tab(0).Control(16).Enabled=   0   'False
      Tab(0).Control(17)=   "optnDim(0)"
      Tab(0).Control(17).Enabled=   0   'False
      Tab(0).Control(18)=   "lstDupe"
      Tab(0).Control(18).Enabled=   0   'False
      Tab(0).ControlCount=   19
      TabCaption(1)   =   "Constrain"
      TabPicture(1)   =   "PbTinDebug.frx":001C
      Tab(1).ControlEnabled=   0   'False
      Tab(1).ControlCount=   0
      TabCaption(2)   =   "Trim"
      TabPicture(2)   =   "PbTinDebug.frx":0038
      Tab(2).ControlEnabled=   0   'False
      Tab(2).ControlCount=   0
      Begin VB.ListBox lstDupe 
         BeginProperty Font 
            Name            =   "Courier New"
            Size            =   8.4
            Charset         =   0
            Weight          =   400
            Underline       =   0   'False
            Italic          =   0   'False
            Strikethrough   =   0   'False
         EndProperty
         Height          =   1476
         Left            =   8940
         Sorted          =   -1  'True
         TabIndex        =   23
         Top             =   540
         Width           =   8475
      End
      Begin VB.OptionButton optnDim 
         Caption         =   "2D"
         Height          =   252
         Index           =   0
         Left            =   7260
         TabIndex        =   18
         Top             =   360
         Width           =   612
      End
      Begin VB.OptionButton optnDim 
         Caption         =   "3D"
         Height          =   252
         Index           =   1
         Left            =   7260
         TabIndex        =   17
         Top             =   660
         Width           =   552
      End
      Begin VB.CommandButton cmdCancel 
         Caption         =   "Cancel"
         Height          =   300
         Left            =   5220
         TabIndex        =   13
         Top             =   1380
         Width           =   795
      End
      Begin VB.CommandButton cmdReset 
         Caption         =   "Reset"
         Height          =   300
         Left            =   3540
         TabIndex        =   12
         Top             =   1380
         Width           =   795
      End
      Begin VB.CommandButton cmdStop17 
         Caption         =   "Stop"
         Height          =   300
         Left            =   4380
         TabIndex        =   11
         Top             =   1380
         Width           =   795
      End
      Begin VB.CommandButton cmdSeqPnt 
         Caption         =   "Seq. Pnt"
         Height          =   300
         Left            =   1740
         TabIndex        =   10
         Top             =   1380
         Width           =   795
      End
      Begin VB.CommandButton cmdGoSeq 
         Caption         =   "Go"
         Height          =   300
         Left            =   2580
         TabIndex        =   9
         Top             =   1380
         Width           =   795
      End
      Begin VB.CommandButton cmdTin0 
         Caption         =   "TIN Init"
         Height          =   300
         Left            =   900
         TabIndex        =   8
         Top             =   1380
         Width           =   792
      End
      Begin VB.CommandButton cmdInitTin 
         Caption         =   "Initialize"
         Height          =   300
         Left            =   60
         TabIndex        =   7
         Top             =   1380
         Width           =   795
      End
      Begin VB.ListBox lstDebug 
         BeginProperty Font 
            Name            =   "Courier New"
            Size            =   8.4
            Charset         =   0
            Weight          =   400
            Underline       =   0   'False
            Italic          =   0   'False
            Strikethrough   =   0   'False
         EndProperty
         Height          =   1068
         Left            =   60
         TabIndex        =   6
         Top             =   300
         Width           =   7035
      End
      Begin MSComctlLib.Slider sldrDbgSpeed 
         Height          =   312
         Left            =   480
         TabIndex        =   14
         Top             =   1740
         Width           =   5652
         _ExtentX        =   9970
         _ExtentY        =   550
         _Version        =   393216
         Min             =   1
         Max             =   100
         SelStart        =   1
         TickFrequency   =   10
         Value           =   1
      End
      Begin VB.Label Label4 
         Caption         =   "Duplicate and Skipped points..."
         Height          =   192
         Left            =   8940
         TabIndex        =   24
         Top             =   300
         Width           =   4452
      End
      Begin VB.Label Label1 
         Alignment       =   1  'Right Justify
         Caption         =   "Triangles: "
         Height          =   192
         Left            =   7200
         TabIndex        =   22
         Top             =   1380
         Width           =   732
      End
      Begin VB.Label lblNtri 
         Alignment       =   1  'Right Justify
         Height          =   192
         Left            =   8040
         TabIndex        =   21
         Top             =   1380
         Width           =   732
      End
      Begin VB.Label Label5 
         Alignment       =   1  'Right Justify
         Caption         =   "Points:"
         Height          =   192
         Left            =   7380
         TabIndex        =   20
         Top             =   1080
         Width           =   552
      End
      Begin VB.Label lblNpts 
         Alignment       =   1  'Right Justify
         Height          =   192
         Left            =   8040
         TabIndex        =   19
         Top             =   1080
         Width           =   732
      End
      Begin VB.Label Label2 
         Caption         =   "Slow"
         Height          =   192
         Left            =   6180
         TabIndex        =   16
         Top             =   1800
         Width           =   372
      End
      Begin VB.Label Label3 
         Caption         =   "Fast"
         Height          =   192
         Left            =   120
         TabIndex        =   15
         Top             =   1800
         Width           =   312
      End
   End
   Begin VB.Frame Frame1 
      Caption         =   "Debug Speed"
      Height          =   912
      Left            =   9600
      TabIndex        =   4
      Top             =   4320
      Width           =   3435
   End
   Begin VB.CommandButton cmdGo17 
      Caption         =   "Go"
      Height          =   375
      Left            =   2160
      TabIndex        =   3
      Top             =   2760
      Width           =   795
   End
   Begin VB.CommandButton cmd17thPnt 
      Caption         =   "17th Pnt"
      Height          =   375
      Left            =   900
      TabIndex        =   2
      Top             =   2580
      Width           =   795
   End
   Begin VB.CommandButton cmdGo 
      Caption         =   "Go"
      Height          =   375
      Left            =   4740
      TabIndex        =   1
      Top             =   2820
      Width           =   795
   End
   Begin VB.CommandButton cmdDebug 
      Caption         =   "Debug"
      Height          =   372
      Left            =   7260
      TabIndex        =   0
      Top             =   2820
      Width           =   795
   End
End
Attribute VB_Name = "frmTinDebug"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit

Dim bGo As Long
Dim bGo17 As Long
Dim bGoSeq As Long

Dim lCount As Long
Dim l17thPnt As Long
Dim lBegTri As Long

Private Sub cmd17thPnt_Click()

Dim i As Long
Dim iNtri As Long

Dim sRecord As String
'---------------------------------------------------------------------------
  
    If lCount = 3 Then
      lCount = lCount + 1
    
    Else
      lCount = lCount + 17
      
        If lCount > UBound(uPNTS) - 1 Then
          l17thPnt = l17thPnt + 1
            If l17thPnt > UBound(uPNTS) Then
              frmTinDebug.Caption = "TIN Debug - FINISHED"
              cmdCancel.SetFocus
              
              Exit Sub
            End If
          lCount = l17thPnt
        End If
    End If
    
  lstDebug.Selected(lCount) = True
  
  'iNtri = tin_InsertPoint(lCount, True)
  'lblNtri.Caption = CStr(iNtri)
  lblNtri.Refresh

End Sub

Private Sub cmdCancel_Click()

Hide

End Sub


Private Sub cmdDebug_Click()

Dim i As Long
Dim iNtri As Long

Dim sRecord As String
'---------------------------------------------------------------------------
lCount = lCount + 1

Select Case lCount
  Case 0
    For i = 0 To 3
      lstDebug.Selected(i) = True
      
      sRecord = lstDebug.List(i)
    Next i
    
      If tin_SetSuperTriangle() = False Then
        Exit Sub
      End If
    
    '///////////////////////////////////////////////////////////////////////
    ' Set number of triangles in the tessellation.  This is the initial
    ' Delaunay super triangle formed from the "false" data points derived
    ' from the actual point data.
    '
    NT = 2
    lblNtri.Caption = CStr(NT)
    lblNtri.Refresh
    
    lCount = 3
  
    'Call Debug_DrawAllTriangles(4, True)   'Draw triangle in dark red
    
  Case Is > 3
    lstDebug.Selected(lCount) = True
    
    'iNtri = tin_InsertPoint(lCount, True)
    'lblNtri.Caption = CStr(iNtri)
    lblNtri.Refresh

End Select

End Sub

Private Sub cmdGo_Click()

Dim i As Long
Dim iNtri As Long

Dim sRecord As String
'---------------------------------------------------------------------------
lCount = lCount + 1

Select Case lCount
  Case 0
    For i = 0 To 3
      lstDebug.Selected(i) = True
      
      sRecord = lstDebug.List(i)
    Next i
    
      If tin_SetSuperTriangle() = False Then
        Exit Sub
      End If
    
    '///////////////////////////////////////////////////////////////////////
    ' Set number of triangles in the tessellation.  This is the initial
    ' Delaunay super triangle formed from the "false" data points derived
    ' from the actual point data.
    '
    NT = 2
    lblNtri.Caption = CStr(NT)
    lblNtri.Refresh
    
    lCount = 3
  
    Call Debug_DrawAllTriangles(4, True)   'Draw triangle in dark red
    
  Case Is > 3
    Do
      lCount = lCount + 1
      
      lstDebug.Selected(lCount) = True
    Loop
    
    'iNtri = tin_InsertPoint(lCount, True)
    'lblNtri.Caption = CStr(iNtri)
    'lblNtri.Refresh

End Select

End Sub


Private Sub cmdGo17_Click()

Dim i As Long
Dim iNtri As Long

'Dim lCRFX As Long
'Dim lCRFY As Long

Dim sRecord As String
'---------------------------------------------------------------------------
  
bGo = True

Do While bGo = True
  DoEvents
  
    If lCount = 3 Then
      lCount = lCount + 1
    
    Else
      lCount = lCount + 17
      
        If lCount > UBound(uPNTS) - 1 Then
          l17thPnt = l17thPnt + 1
            If l17thPnt > 21 Then
              frmTinDebug.Caption = "TIN Debug - FINISHED"
              cmdCancel.SetFocus
              'bGo17 = False
              Exit Do
            End If
          lCount = l17thPnt
        End If
    End If
    
  lstDebug.Selected(lCount) = True
  
  'iNtri = tin_InsertPoint(lCount, True)
  'lblNtri.Caption = CStr(iNtri)
  lblNtri.Refresh
  
  DoEvents
Loop

lstDebug.Clear

sRecord = " "

lstDebug.AddItem sRecord
lstDebug.AddItem sRecord
lstDebug.AddItem sRecord
lstDebug.AddItem sRecord

For i = 0 To lstDupe.ListCount - 1
  sRecord = lstDupe.List(i)
    If InStr(1, sRecord, " Skip") > 0 Then
      sRecord = Replace$(sRecord, " Skip", "", 1, -1)
      lstDebug.AddItem sRecord
    End If
Next i

lstDupe.Clear

For i = 4 To lstDebug.ListCount - 1
  sRecord = lstDebug.List(i)
  lstDebug.Selected(i) = True
Next i
              
bGo = False

Call Debug_SetAllTrianglesDisplay(lCrfX, lCrfY)
Call Debug_DrawAllTriangles(12, lCrfX, lCrfY)

End Sub

Private Sub cmdGoSeq_Click()

Dim i As Long
Dim iNtri As Long

Dim lCrfX As Long
Dim lCrfY As Long

Dim sRecord As String
'---------------------------------------------------------------------------
  
bGo = True

Do While bGo = True
  DoEvents
  
  lCount = lCount + 1
    
    If lCount < lstDebug.ListCount - 1 Then
      lstDebug.Selected(lCount) = True
      
    Else
      frmTinDebug.Caption = "TIN Debug - FINISHED"
      cmdCancel.SetFocus
      
      Exit Do
    End If
    
  lblNtri.Refresh
  
  DoEvents
Loop


'lstDebug.Clear
'
'sRecord = " "
'
'lstDebug.AddItem sRecord
'lstDebug.AddItem sRecord
'lstDebug.AddItem sRecord
'lstDebug.AddItem sRecord
'
'For i = 0 To lstDupe.ListCount - 1
'  sRecord = lstDupe.List(i)
'    If InStr(1, sRecord, " Skip") > 0 Then
'      sRecord = Replace$(sRecord, " Skip", "", 1, -1)
'      lstDebug.AddItem sRecord
'    End If
'Next i
'
'lstDupe.Clear
'
'For i = 4 To lstDebug.ListCount - 1
'  sRecord = lstDebug.List(i)
'  lstDebug.Selected(i) = True
'Next i

              
bGo = False

Call Debug_SetAllTrianglesDisplay(lCrfX, lCrfY)
Call Debug_DrawAllTriangles(12, lCrfX, lCrfY)

End Sub


Private Sub cmdInitTin_Click()
    
  Dim i As Long
  'Dim lCRFX As Long
  'Dim lCRFY As Long
  
  For i = 0 To 3
    lstDebug.Selected(i) = True
  Next i
  
    If tin_SetSuperTriangle() = False Then
      Exit Sub
    End If
  
  '///////////////////////////////////////////////////////////////////////
  ' Set number of triangles in the tessellation.  This is the initial
  ' Delaunay super triangle formed from the "false" data points derived
  ' from the actual point data.
  '
  NT = 2
  lblNtri.Caption = CStr(NT)
  lblNtri.Refresh
  
  lCount = 3

  cmd17thPnt.SetFocus
  
  Call Debug_SetAllTrianglesDisplay(lCrfX, lCrfY)
  
End Sub

Private Sub cmdReset_Click()

Dim i As Long

frmTin.picTin.Cls

For i = 1 To UBound(uTIN)
  uTIN(i).SKIP = False
Next i

lstDupe.Clear

lCount = -1

lstDebug.TopIndex = 0
lstDebug.Selected(0) = True

cmdDebug.SetFocus

End Sub


Private Sub cmdSeqPnt_Click()

  Dim i As Long
  Dim iNtri As Long
  
  Dim sRecord As String
  '---------------------------------------------------------------------------
  
  lCount = lCount + 1

    If lCount < lstDebug.ListCount - 1 Then
      lstDebug.Selected(lCount) = True
      
    Else
      frmTinDebug.Caption = "TIN Debug - FINISHED"
      cmdCancel.SetFocus
    End If
        
  
  'iNtri = tin_InsertPoint(lCount, True)
  'lblNtri.Caption = CStr(iNtri)
  lblNtri.Refresh

End Sub

Private Sub cmdStop17_Click()

bGo = False

End Sub

Private Sub cmdTin0_Click()

'*************************************************************************
' Purpose:
'
' Subprogram to respond to the cmdTin0_Click event.  This event creates
' the coarse TIN model by inputting every 17th point into the initial
' tessellation.  The coarse TIN is used to construct the final
' tessellation and to provide an "existing" triangle data set to insert
' subsequent points.  The coarse TIN helps eliminate undesireable (skinny)
' triangles that can play havoc with Intel floating point processing.
'
'*************************************************************************

Dim iNop As Long

Dim lCrfX As Long
Dim lCrfY As Long
Dim lInCircle As Long
Dim lPointNo As Long

Dim dChkX As Double
Dim dChkY As Double

Dim sItem As String

bGo = True
dChkX = uPNTS(4).PNTX
dChkY = uPNTS(4).PNTY

lCount = lCount + 1
lstDebug.Selected(lCount) = True
lBegTri = 1

Do While bGo = True
  DoEvents
  
  lCount = lCount + 17
  
    If lCount > UBound(uPNTS) - 1 Then
      Exit Do
    End If
    
  'sItem = lstDebug.List(lCount)
  'lPointNo = Val(sItem)
  '
  'lInCircle = tin_PntInCircle(uPNTS(lPointNo).PNTX, _
  '                               uPNTS(lPointNo).PNTY, _
  '                               dChkX, dChkY, 200#)
  '
  'Select Case lInCircle
  '  Case 0, 1
      lstDebug.Selected(lCount) = True
  '    dChkX = uPNTS(lPointNo).PNTX
  '    dChkY = uPNTS(lPointNo).PNTY
  '  Case Else
  '
  'End Select
  
  'iNtri = tin_InsertPoint(lCount, True)
  'lblNtri.Caption = CStr(iNtri)
  lblNtri.Refresh
  
  DoEvents
Loop

lCount = 3
lstDebug.Selected(lCount) = True

bGo = False

Call Debug_SetAllTrianglesDisplay(lCrfX, lCrfY)
Call Debug_DrawAllTriangles(12, lCrfX, lCrfY)

For iNop = 1 To UBound(uTIN)
  uTIN(iNop).SKIP = False
Next iNop
lBegTri = 1

End Sub

Private Sub Form_Activate()

optnDim(0).value = True

lstDebug.Selected(0) = True

sldrDbgSpeed.value = 50

cmdInitTin.SetFocus

End Sub

Private Sub Form_Load()

bGo = False
lCount = -1
l17thPnt = 4

End Sub


Private Sub lstDebug_Click()

Dim iNtri As Long
Dim iNum As Long
Dim iAtIndex As Long
Dim lPointNo As Long

Dim sItem As String

iAtIndex = lstDebug.ListIndex

  If iAtIndex > 3 Then
    sItem = lstDebug.List(iAtIndex)
    lPointNo = Val(Trim$(sItem))
    
    iNum = NT
    
    iNtri = tin_InsertPoint(lPointNo, lBegTri, True, bGo, sItem)
    
'      If iNtri = iNum Then
'        lstDupe.AddItem sItem
'      End If
      
    lblNpts.Caption = CStr(NP)
    lblNtri.Caption = CStr(iNtri)
    lblNtri.Refresh
  End If
  
End Sub

Private Sub optnDim_Click(INDEX As Integer)

sTINDIM = optnDim(INDEX).Caption

End Sub


Private Sub sldrDbgSpeed_Change()

Dim fPercent As Single

fPercent = sldrDbgSpeed.value / 100#

lDBGSPEED = CLng(524280 * fPercent)

End Sub

Private Sub sldrDbgSpeed_Click()

Call sldrDbgSpeed_Change

End Sub

[Rodney Hicks]

I'm glad you posted that file of yours, things take a different perspective immediately. Again.

I have been downloading VB files from a website just to see what was what, but they were all a lot simpler than what you show, and I mean a lot.

I'm gonna run this through PBForms to see what it looks like. I assume the position and size figures are those 'twirps' I've been reading about?

This would also better afford the opportunity to the user by allowing them to add to and/or enhance their collection of PB template files.

This alone is reason enough to go your way with this.

I'll post later this evening, got company out of the blue.(hope they brought food)

[John R. Heathcote]

Rod,

I'm gonna run this through PBForms to see what it looks like. I assume the position and size figures are those 'twirps' I've been reading about?

I think M$ refers to them as "twips", on second thought, you may be right after all.

If I remember correctly I think I used pixels as my unit of measure in VB so the dialog should fill most of the screen based on the form dimensions.

This alone is reason enough to go your way with this.

I can appreciate that, but I would really like to hear from some of the other members on this subject. I want to hear their ideas too, particularly since I'm relatively new at the art of VB conversion.

[Brian Chirgwin]

I'd work this differently. A template for each VB control event. (click, key_down, etc..)

If the vb event is called, have the appropriate event generated for the given control that called it. This will keep the code as simple as it possibly can be; which will of course make it simpler to understand.

This may be a version 2 optimization.

Brian,

I was thinking more in terms of the generated source code from the converter using a standard control callback template file. I was attempting to create a standard individual callback for each control that contained the general events, most of them anyway, that are usually found in VB source code. To do that it was necessary to expand the Select/End Select Case statements to include Windows messages that may never get referenced in the equivalent VB event. If we find that we need to respond to a Windows message that is missing from the template file it would be a simple matter to add that functionality.

Using multiple callbacks allows us to plug in the combobox template, for example, if it is referenced in the VB source code and utilize the VB event code rather than hard code this functionality into the converter. I think this modular approach has some advantages, but I would like to hear other members comment on this idea too.

[Rodney Hicks]

Well, I put it through PBForms and I got a dialog(window) with 10 buttons(6 visible immediately), a couple of listviews, some labels, frame, and it seems that all was there. However the window height was about 1/5 the width and below, by resizing the window, I discover four of the ten buttons.
In the .frm code the first listbox has a width of 8475 whereas in PBForm it has widths of 312 dialog units,468 pixels.
The tab control is in the background but not recognized as such by PBForms.
I have no idea what it was to look like in VB but I'm still impressed with what PBForms does with the info they have from that one file. I know there is a lot of inaccuracies.

[John R. Heathcote]

Brian,

I think we are essentially talking about the same thing. But just to recap in case I didn't make myself clear (which happens to me a lot the older I get), I was suggesting a template file for each VB control just to trap the Windows event messages. Once the event message was trapped a call to the VB event would be inserted in the template file at the appropriate place that would actually run the code for that event.

A template file for a VB button control, called "VB-CommandButton.TPL", might look like this:

CALLBACK FUNCTION <CB funcname>() as LONG
   
   SELECT CASE AS LONG CB.MSG
      CASE CASE %WM_COMMAND
         SELECT CASE AS LONG CB.CTL
            CASE <idc button>
               SELECT CASE CB.CTLMSG
                  CASE %BN_CLICKED 
                     'Insert the VB button _Click() event here

                     FUNCTION = 1

                  CASE ELSE
                     FUNCTION = 0
							
               END SELECT
					
            CASE ELSE
               FUNCTION = 0
						
         END SELECT
			
      CASE %WM_SETFOCUS
         FUNCTION = 1
			
      CASE %WM_KILLFOCUS
         FUNCTION = 1
			
      CASE ELSE
         FUNCTION = 0
			
   END SELECT

END FUNCTION

This would be just about all that is in the template file. The <CB funcname> and <idc button> would be inserted by the converter after reading the VB .FRM file to resolve these two references. Since the VB code for the button event already exists we would just insert the VB -Click() event call after the %BN_CLICKED message. The purpose of the template file is simply to set up the call to the VB event procedure. If there are additional parameters we might need, such as the row and column the user clicked in a ListView/FlexGrid we would supply that too as part of the template file.

So all in all we would need only three pieces of information from the *.FRM file to set up the PB source code framework for each VB Command Button control.

All I'm suggesting for the dialog conversion at this point is to set up the PB source code framework so all VB control and source code references are resolved. Once the PB dialog box source code has been created we then run it through the Tokenizer to correct the offending VB code still present.

[John R. Heathcote]

Rod,

Doesn't PBForms use Dialog Units by default? If so, that might be one inaccuracy we can account for. The actual VB form should cover most of the screen as I was using it to graphically debug the triangulation surface model application I wrote in VB, and hope to convert it to PB very soon. The purpose of this particular dialog box was to show the triangulated mesh as it was being created which is kinda fun to watch.

As far as the "extra" buttons, I don't remember. It is possible that I defined a lot of buttons for future use and for some reason I just never deleted the ones I didn't use anymore.

Don't know why the tab control didn't show up unless it too was one of those controls I didn't need anymore.

[Rodney Hicks]

Dialog units is the default setting, but you can change it to pixels. That one number I gave you would have given a dialog about 9 or 10 screens wide in dialog units. All or most of the numbers seemed large to me, even for full screen.

I don't know if PBForms converts all the controls that it is set up for in PB, it may just to the simpler ones at this stage. This version has been around for a wee while now I believe.

If you were converting that code with the converter would you have gotten a lot of obnoxious comments for the button that were hidden? Actually, the converter is likely going to waste a lot of time in the user's hands as they experiment with trying to convert unfinished programs I'm sure. T'would be fun to be fly on the wall for that.

Do we have a conversion ratio for 'twirps' or whatever they're called?

With regards to the individual callbacks, that is pretty much what I had in my head from your discription. I think that the first version or two should work along these lines. There may be a bit of redundancy in the code but if it gets it working, it'll be worth the sacrifice.

Someone may come along with a different idea yet, but I think it does allow for smoother 'repairs' and/or additional code by user's.

[John R. Heathcote]

Rod,

Dialog units is the default setting, but you can change it to pixels. That one number I gave you would have given a dialog about 9 or 10 screens wide in dialog units. All or most of the numbers seemed large to me, even for full screen.

I'm wondering if the PBForms import converts dialog/control sizes to Dialog Units automatically. I don't know.

I don't know if PBForms converts all the controls that it is set up for in PB, it may just to the simpler ones at this stage. This version has been around for a wee while now I believe.

I think, as you say, that we should wait for the user feedback, I'm sure they will have plenty to say.

If you were converting that code with the converter would you have gotten a lot of obnoxious comments for the button that were hidden?

That is a very good possibility

Actually, the converter is likely going to waste a lot of time in the user's hands as they experiment with trying to convert unfinished programs I'm sure. T'would be fun to be fly on the wall for that.

Yup, I agree!!!

It's too bad we can't round up a group of newly converted PB users from VB, set them down in front of our converter and watch what happens. I'm sure that experience alone would teach us plenty.

Do we have a conversion ratio for 'twirps' or whatever they're called?

I used to know what it is, but I've forgotten it. I vaguely remember "twips" is another fraction of an inch measurement mostly used for the production of printed documents I believe, but beyond that, I just don't know. I do know that I've never used 'twips' in any of my VB apps. Maybe this calls for some poking around on the web to find the answer.

With regards to the individual callbacks, that is pretty much what I had in my head from your discription. I think that the first version or two should work along these lines. There may be a bit of redundancy in the code but if it gets it working, it'll be worth the sacrifice.

To me it's a trade off. PB allows you to define a callback for the entire dialog and/or individual controls for both DDT and SDK. As such it is the smallest piece of code we can produce for a callback function and still be generic enough to allow additional Windows event messages to be inserted. Granted we may be inserting additional event code in the template files that is never used for a given conversion, but I don't think we will be inserting that much extra code, do you?

It is my contention that most users only utilize a small subset of the total VB events available. Most users, for example, that place a VB command button on their form only respond to the Vb _Click() event, although VB does have other events available to use for a VB button control. If we only put a %BN_CLICKED event message in our template file we will take care of 95% to 99% of all VB apps. Besides, if unused callback code is a concern for the user, they can always go back and comment out or remove the unused code at their leisure.

Someone may come along with a different idea yet, but I think it does allow for smoother 'repairs' and/or additional code by user's.

So true. I think file maintenance will be a critical issue here.

BTW, I think I've finally got a handle on how to deal with all of the VB project files. Will know in a couple of days, I am busy coding up my idea.

[Wayne Suite]

Pixels In Vb

Do we have a conversion ratio for 'twirps' or whatever they're called?

I have found ratios close to 15 in most cases but it does vary dependent on the type of monitor used. (Standard 4:3 or Wide 16:1)

Screen
Resolution Twips

640 x 480 9465 x 6885
800 x 600 9600 x 7590
1024 x 768 12000 x 8700
1280 x 1024 19200 x 15000
1360 x 768 20295 x 11180
1400 x 900 21600 x 13185

Width x Height

Maybe this will help some. However there are other choices than Twips for the screen in vb and they would therefore vary the sizes. Pixels is also a choice as well as others just to complicate things

[Wayne Suite]

Conversions

So lets do the math

'======================================
Private Function PixelsToTwips(pixels as integer)
 
PixelsToTwips = pixels*Screen.TwipsperpixelX
 
End Function
'======================================
 
'======================================
Private Function TwipsToPixels(twips as integer)
 
TwipsToPixels = twips/Screen.TwipsperpixelX
 
End Function
'======================================

Hoping to help along the bumpy path ...

[Rodney Hicks]

Twips<>twirps? Darn. Thought I was onto something.

Thanks for clarifying.

[Wayne Suite]

Twips Conversion

The other component of the conversion is the Y axis.

Just substitute Y where the large X is on Screen.Twipsperpixel to get the other axis.

Don't know if PB has an equal where it reports the Twipsper pixel for the current screen resolution. The Twips change according to the user's current screen resolution, for example on my 1920 x 1200 screen the Twips are reported as 28800 x 18000. So technically you could also use this to determine the current users screen size then size the form according to the real estate you wish your application to occupy on the screen.

Enjoy.

[Rodney Hicks]

I think this might be a case of using default converter values for x, y, height, and width. Or maybe an input box with each occurrence, which could get tedious. I lean toward default value with appropriate comment like 'ALERT. The user could then adjust these figures as necessary by searching the code for the 'ALERTs or 'ALERT DIMENSIONs without it actually preventing compilation of the program.

This too could be a little tedious, but it sure beats having to rewrite a lot more code. I'm talking first version here, possibly subsequent as well, as I think there are more devious problems that we should solve first.

There is one caveat, and that is the default position should maybe calculated as such:
window/dialog height X width= 2000 x 8000
control x,y,h,w=200,500,50,500
If the default PB window/dialog h,w are 400x500 then the control's x pos should be 200/8000*500. Of course similar for other dimensions and controls. This should place whatever is being placed in similar positions as the VB code. The resolution factor should be immaterial.

Just thinking.

[John R. Heathcote]

Rod,

The twips issue might be one of those instances where we may prompt the user with several options like "TWIPS to PIXELS", "TWIPS to DIALOG UNITS", etc., up front and let them choose which conversion factor to apply to the VB dialog box. This seems easier than attempting to determine the dimensions intent of the VB dialog box dynamically. If the conversion doesn't look right the user can always go back and select a new dimension conversion option and try again.

No matter which way we establish the twips conversion factors I think there will always be slight control alignment issues that the user will have to address due to round off errors. In this case the best we may be able to do is to produce a PB dialog box that is reasonably close to the original VB form, but not exact.

I seem to remember that if you selected twips for the dialog box the controls were defined using twips as well.

[John R. Heathcote]

To All,

There may be another aspect of the VB forms conversion issue that the group should consider. After the VB form has been converted over to PB do you think we should provide the user the ability to test the conversion aka like PBForms? I am of the opinion this visual feedback would help the user determine the success or failure of the conversion process before he got too deeply involved in his project. Perhaps in a future version?

[Rodney Hicks]

This was one of the reasons we wanted the .frm files run through PBForms before any converting was done. Having PBForms was going to be required.

It isn't really necessary to use PBForms, but we are in essence going to be reinventing the wheel by not using it. We'll just have to put the dialog and controls for each window into a separate procedure and use PBForms metastatements. PBforms won't adjust any of the code in callbacks. This would still require having PBForms. Anything else would require that the generated code would compile as is, directly from the converter. Commenting out is probably the quickest.

[Brian Chirgwin]

Duplicating work?

Hmm. Don't we need to parse the .FRM file to get the control types and control names and properties anyway to correctly covert VB code to PB code? It isn't that much more work to generate the form layout code?

While I agree PBForms does a decent job converting VB forms for as far as it goes, and I also agree with not reinventing the wheel. I am not convinced that PBForms saves time. In fact, I believe it adds time and unnecessary complexity. PBForms output will need to be parsed for at least where to add VB to the correct callback code. This process will be more complex than generating the code from the VB Forms.

VB .FRM format is not going to change (MS will not be releasing an update for VB6 modifying the .FRM format). PBForms, in the next release most likely will change; updated to use the new PB9 syntax. Parsing PBForms output means having to modify the VB2PB to this new syntax as well. If we don't, and PBForms 1.5 is no longer being sold, the VB2PB product becomes useless to potential new users of PB.

As for Twips conversion, Twips are 1440 per inch. If I remember correctly Pixels in VB are 72 per inch. The conversion is straight fairly forward. Users can also use a custom resolution sie (where the user sets there own width/height conversion size). In any case the calculation to convert is fairly straight forward. If the user has code to move or resize controls, code needs to be converted (or left to the user to figure out). If we are using PBForms, we will need to parse the property details of the FRM and PBForms to correctly convert the code.

An alternative is to force the user to change to all forms to use Twips before a form is converted. A quick verification making sure the form is using twips can be performed. If not fail to convert.

Unless I am missing something I don't see the advantage of PBForms. I actually see it as a disadvantage. It looks to me like more work to parse both VB .FRM files and PBForms output files than just generating the required code directly from the VB .FRM file.

What am I missing?

This was one of the reasons we wanted the .frm files run through PBForms before any converting was done. Having PBForms was going to be required.

[John R. Heathcote]

Rod,

This was one of the reasons we wanted the .frm files run through PBForms before any converting was done. Having PBForms was going to be required.

I certainly think this is doable. My thought was, once the user plays with the converter, most of them will probably convert their VB forms first as they are the initial and usually the most critical interface between the user and the application. The difficulty will be for the new user to interpret what he sees and what to do about it if something doesn't look right.

For example, in the form I posted, PBForms takes the VB PictureBox control and replaces it with the PB PictureBox control. PBForms is replacing the VB control functionality on a one to one basis, however, for this application the assumption PBForms made isn't correct. The VB PictureBox can also be used as a drawing canvas, which is the case here. So PBForms should have set up a GRAPHIC WINDOW as a substitute for the VB PictureBox control, but I understand why it didn't do this. If we use PBForms to convert VB forms, how do we flag the alternate VB control usage possibility to the user? My concern here is that the work flow is introducing "errors" in the process, some of which the new user may not know about or even be aware of.