Announcement

**Rodney Hicks** · 17 Jul 2008, 10:33 PM

The first version of this converter should be, in my opinion only, very straight forward and simple.

Mostly taking VB terms and replacing them with PB terms, much like your Debug.Print to #DEBUG PRINT. Whether we give the converter(and thus the user) a stepper control I don't think has yet been decided, but it has merit. The biggest drawback to it is the size of some of the programs that ex VBers are going to want to convert. If someone has 10,000 lines of code to convert, they aren't likely to want to parse each line themselves. Productivity demands quick and seamless conversion, in as much as we can fashion such.

I think it has been decided that we would use the PB IDE for viewing the code, in order to cut down on the tasks that would be done by a bunch of volunteers working as they had the time. The PB IDE with its debugging capabilities should be an essential part of the conversion process to help familiarize VBers with the PB method. Not all VBers that have switched to PB are going to want to buy a host of other products which should not be necessary, nor should we favor some other product over PB, all things considered.

There may be an awful lot of changes to our methods before this is done, but keeping the product simple comes first. Once we have a version released, those using it will give us lots of ideas on how to make it better.

I do think that the user should be able to view within the converter, but to add editing features takes time away from the actual converting features to reinvent the wheel.

There needs to be some method of rolling back the changes made to a source code module in case something did not work as expected.

We may need to have conversion options of some sort to help with this problem, because we know that it isn't going be a straight line by line coding success. To get the optimum PB code from VB code may require several different runs of the converter at first, each with different options set.

It is nice to get your views on these matters, so if you have others please state them. Only please don't be one of those people who say "My way or nothing!" Part of the benefit of this project is to work with others and learn or show different concepts without losing our project focus.

Rod

**John R. Heathcote** · 18 Jul 2008, 01:14 PM

Rodney,

Just wanted to propose some user issues that will have to be addressed sooner or later. I thought if we could visit some of the user issues now it wouldn't be too hard to make changes and enhancements later.

The first version of this converter should be, in my opinion only, very straight forward and simple.

I agree 100%.

The biggest drawback to it is the size of some of the programs that ex VBers are going to want to convert. If someone has 10,000 lines of code to convert, they aren't likely to want to parse each line themselves. Productivity demands quick and seamless conversion, in as much as we can fashion such.

I didn't mean to suggest that the user would have to parse each line in the editor manually, but have the converter do this, but show the results in the editor as they happen. The main VB source code for my surface modeling program is almost 12,000 lines long, and I agree, I would hate to try to convert this file by hand.

I think it has been decided that we would use the PB IDE for viewing the code, in order to cut down on the tasks that would be done by a bunch of volunteers working as they had the time.

I suppose the PB editor is ok for the first version of the converter, but it wouldn't be my first choice for subsequent versions. There are many editors out there, JellyFish and SED just to name two that are free, that offer much better code navigation, more features, and generally are more intuitive to use than the PB editor.

The PB IDE with its debugging capabilities should be an essential part of the conversion process to help familiarize VBers with the PB method. Not all VBers that have switched to PB are going to want to buy a host of other products which should not be necessary, nor should we favor some other product over PB, all things considered.

...I do think that the user should be able to view within the converter, but to add editing features takes time away from the actual converting features to reinvent the wheel.

As far as compiling the VB conversion, by all means use the PB editor/debugger. As I mentioned before there are free editors available not to mention the Scintilla SciLexer.dll edit control is free. If we use the Scintilla control for our editor, for example, we can package the necessary Scintilla .DLLs as part of the installation routine, what is so difficult about that? And they are free! I have used the Scintilla edit control in one of my FireFly projects and despite some cumbersome aspects unique to the edit control it does work and works quite well.

One other thing to consider is the fact that Mr. Roca has a PB project called PBSCIED.bas based on the Scintilla edit control that was his first attempt at what has now become SED, and is available from the PB Source Code forums and is also located in POFFS. Much of the source code for this editor could be ported over to the conversion application as is, with proper credit given to Mr. Roca of course. The functionality of the PBSCIED source code would provide just about everything a user could want in the way of features necessary to augment the conversion process. I find it difficult to believe that a working editor couldn't be put together using the PBSCIED source code in a couple of weeks without having to reinvent the wheel so to speak. IMHO the difficulty of putting together a source code text editor is really a non-issue.

It is nice to get your views on these matters, so if you have others please state them. Only please don't be one of those people who say "My way or nothing!" Part of the benefit of this project is to work with others and learn or show different concepts without losing our project focus.

Have no fear, my ego is not that big, in fact when I had my concussion it knocked out the biggest part of my ego, not to mention knocking some sense (and humility) into me. I was just putting out some ideas to stimulate discussion, that's all. If the group chooses not to accept my ideas and concepts, fine, but I felt they were important enough to be put out for public consideration and comments.

**StanHelton** · 18 Jul 2008, 09:03 PM

Originally posted by John R. Heathcote View Post

To All:

It must be close to the time to officially create this beast so I would like to take some time to express some user issues, if I may.

Of course. There are no egos here, just open discussion.

...
Personally I prefer software that doesn't do too much processing/decision making in one shot. I also prefer software that allows (forces?) me to make the ultimate decision to achieve the result ...

I think we all agree on this point.

...
I'm assuming (and please correct me if I'm wrong) that the conversion process will be an iterative one, convert a little, compile a little, debug a little.

Actually, I hadn't thought about the possibility that the user might want to debug as he goes. But you are correct. This is something that definately must be an option.

...
To this point I still do not know how much VB to PB conversion will be done per pass, assuming we will have a multi-pass system. If this is the case then how we choose to set up the converter will have an obvious direct bearing on your coding efforts.

Another excellent point. The code below is what I've got on the Tokenizer, the module where most of the real simple initial passes will be made. I agree with Rod here that the first release will be limited in what it can do. We have discovered that the Terms Dictionary is going to be very large. In order to get enough in there to be useful the first release will have to be limited in what it does: 1:1 equivalents; syntax changes (ie. PRIVATE in Function prototypes); basic file handling; more if we have time. As I see it right now there will be at least 4, possibly 6 passes to get this done.

...
I think some of these more mundane conversions could be done in a multi pass preprocessor before we get into the exotic stuff like VB objects. Since I tended to stay away from using VB objects in my source code, this type of exotic conversion is not much use to me, but would be of use to someone else. About 95% of my conversions would fall into the preprocessor category.

I'm calling it a "Tokenizer", but we share the same concept for it.

...
I am firmly convinced that the converter should be coupled with a text edit control ...

I like the idea of giving the user an option to use whatever editor he wants. I'm thinking a CMD button that shells out to the editor. The PB IDE, PBForms, and the VB6 IDE would be the defaults. If you compile the skeleton code below you'll see how I've set it up. Any suggestions welcome on this.

Just my ideas and observations.

Constructive discussion is ALWAYS welcome. It's the process.

Originally posted by Rodney Hicks View Post

The first version of this converter should be, in my opinion only, very straight forward and simple.

Sounds to me like we're all on the same page here, Rod.

... the size of some of the programs that ex VBers are going to want to convert. If someone has 10,000 lines of code ... Productivity demands quick and seamless conversion, in as much as we can fashion such.

If you don't mind compiling my skeleton code and giving some feedback on the user interface, I think there's an easy way to include the quick option in right along with the slower option. Still haven't figured out the debug part, though. I'd like to hear more -- John, if you have ideas on how to implement a debug without resorting to the IDEs I am very interested!

...
I think it has been decided that we would use the PB IDE for viewing the code, in order to cut down on the tasks that would be done by a bunch of volunteers working as they had the time. The PB IDE with its debugging capabilities should be an essential part of the conversion process to help familiarize VBers with the PB method. Not all VBers that have switched to PB are going to want to buy a host of other products which should not be necessary, nor should we favor some other product over PB, all things considered.

That was my first thought, too. If we shell out to the PB/PBForms/VB IDEs we can bypass the debug altogether in the first release. Some sort of text editor will have be included, but it won't be very fancy at first , I think.

...
Mr. Roca has a PB project called PBSCIED.bas based on the Scintilla edit control...
Much of the source code for this editor could be ported over ... as is ...

Jose Roca has a rich collection of resources. I find his code very useful. If there's time, let's look into this. I think he would not mind letting us use some of the things he's posted -- with full credit in the AboutBox!

Here's the Tokenizer/Preprocessor Skeleton. Feedback please.

Code:

#PBFORMS CREATED V1.51
#COMPILE EXE
#DIM ALL

'------------------------------------------------------------------------------
'   ** Includes **
'------------------------------------------------------------------------------
#PBFORMS BEGIN INCLUDES
#IF NOT %DEF(%WINAPI)
    #INCLUDE "WIN32API.INC"
#ENDIF
#INCLUDE "PBForms.INC"
#PBFORMS END INCLUDES
'------------------------------------------------------------------------------

'------------------------------------------------------------------------------
'   ** Constants **
'------------------------------------------------------------------------------
#PBFORMS BEGIN CONSTANTS
%IDC_cmdALTERNATEEDITOR1       = 1035
%IDC_cmdALTERNATEEDITOR2       = 1036
%IDC_cmdALTERNATEGUITOOL1      = 1037
%IDC_cmdALTERNATEGUITOOL2      = 1038
%IDC_cmdAutoDelay              = 1026
%IDC_cmdBEGINPROCESS           = 1023
%IDC_cmdLineByLine             = 1025
%IDC_cmdNoDelay                = 1028
%IDC_cmdPAUSE                  = 1012
%IDC_cmdPBFORMS151             = 1034
%IDC_cmdQUIT                   = 1020
%IDC_cmdSAVEANDEXIT            = 1013
%IDC_cmdVIEWPBWIN804SOURCECODE = 1033
%IDC_cmdVIEWVB60SOURCECODE     = 1032
%IDC_LABEL1                    = 1001
%IDC_LABEL2                    = 1003
%IDC_LABEL3                    = 1005
%IDC_LABEL4                    = 1009
%IDC_LABEL5                    = 1024
%IDC_lblPROGRESSOPTIONS        = 1027
%IDC_lblSTATUSMESSAGES         = 1015
%IDC_lbxVBPROJECTFILES         = 1007
%IDC_LINE1                     = 1008
%IDC_LINE3                     = 1031
%IDC_txtPowerBASICcodeLine     = 1004
%IDC_txtVBcodeLine             = 1002
%IDC_txtVBProjectName          = 1006
%IDD_VB2PBVBCODETOKENIZER      =  101
#PBFORMS END CONSTANTS

%ListBoxLineLength = 79     'measured for 10 point Courier New as ListBox font

$Title = "vb2pb Tokenizer"  'application Title
$Separator = "|"             'data separator = pipe character
'------------------------------------------------------------------------------

'PBWin variable types & term descriptors
%pbByte                 = 501
%pbInteger              = 502
%pbLong                 = 503
%pbQuad                 = 504
%pbWord                 = 505
%pbDword                = 506
%pbSingle               = 507
%pbDouble               = 508
%pbExtended             = 509
%pbCurrency             = 510
%pbExtendedCurrency     = 511
%pbString               = 512
%pbFixedLengthString    = 513
%pbAscizString          = 514
%pbFieldString          = 515
%pbGUID                 = 516
%pbVariant              = 517

%pbUserDefinedType      = 518
%pbArray                = 519
%pbObject               = 520

%pbNumericLiteral       = 521
%pbStringLiteral        = 522
%pbNumericEquate        = 523
%pbStringEquate         = 524

%pbCompilerDirective    = 525
%pbOperator             = 526
%pbKeyword              = 527

%pbFunctionPrototype    = 567
%pbSubPrototype         = 568
%pbComment              = 528

'VB6 variable types & term descriptors
%vbBoolean              = 529
%vbByte                 = 530
%vbConst                = 531
%vbCurrency             = 532
%vbDouble               = 533
%vbInteger              = 534
%vbLong                 = 535
%vbSingle               = 536
%vbString               = 537
%vbFixedLengthString    = 538
%vbVariant              = 539

%vbUserDefinedType      = 541
%vbArray                = 542

%vbObject               = 543
%vbCollection           = 544
%vbProperty             = 545
%vbFunction             = 546
%vbMethod               = 547
%vbEvent                = 548
%vbStatement            = 549
%vbKeyword              = 550
%vbConstant             = 551
%vbOperator             = 552
%vbControl              = 553
%vbActiveXControl       = 554

%vbCompilerDirective    = 555
%vbComment              = 556

'VB Class, Properties, Methods, & Events
%vbClassPrototype       = 557
%vbFunctionPrototype    = 558
%vbSubPrototype         = 559

'TokenizerStatus equates
%IsPaused               = 560
%IsReady                = 561
%IsRunning              = 562
%IsFinished             = 563
%IsSearching            = 564
%IsEditing              = 565
%IsBrowsing             = 566

'   *** Last number used = 568 as of 7/16/2008 ***

'------------------------------------------------------------------------------

TYPE PropertyType                   'use in PropertyArray(); property list developed in first run through VB code
    vbTerm AS STRING * 32
    VarType AS LONG                 'use equates above
    DefaultValue AS STRING * 32
    Comment AS STRING * 128
END TYPE

TYPE MethodType                     'use in MethodArray(); find in first run through Vb code
    vbTerm AS STRING * 32
    ProcedureType AS LONG           'use equates above
    ReturnType AS LONG              'use equates above
    Arguments AS STRING POINTER
    Prototype AS STRING * 256
    Comment AS STRING * 128
END TYPE

TYPE EventType                      'use in EventArray(); find in first run through
    vbTerm AS STRING * 32
    OccursOn AS LONG                '*** need to develop list, possibly from the VB source?
    ReturnType AS LONG              'use equates above
    DefaultValue AS STRING * 32
    Comment AS STRING * 128
END TYPE

TYPE ObjectSimulatorType            'use in ClassArray(); first run through
    ObjectName AS STRING * 32
    ObjectType AS LONG              'use equates above
    Properties AS STRING * 256
    Methods AS STRING * 256
    Events AS STRING * 256
    Comment AS STRING * 128
END TYPE

TYPE VariableNamesType              '1st run thru
    Variable AS STRING * 32
    VarType AS LONG                 'use equates above
END TYPE

TYPE pbProcedureTemplateType
    ProcName AS STRING * 32
    ProcType AS LONG                'use equates above
    ProcText AS STRING * 512
END TYPE

'------------------------------------------------------------------------------
'   *** Globals ***
'------------------------------------------------------------------------------
GLOBAL vbProjectName AS STRING
GLOBAL ParseReportFileList AS STRING    'holds files to be processed by Tokenizer

GLOBAL PropertyArray() AS PropertyType          'use these arrays only for
GLOBAL FunctionArray() AS MethodType            '   properites, functions,
GLOBAL EventArray() AS EventType                '   events, variables, and
GLOBAL ClassArray() AS ObjectSimulatorType      '   variants contained in
GLOBAL VariableNames() AS VariableNamesType     '   current VB6 project.
GLOBAL VariantNames() AS STRING

GLOBAL PBWinSubFolder   AS STRING               'completed PBWin project files go here with ".bas" or ".inc" extension
GLOBAL pbSourceFileList AS STRING               'intermediate PBWin files with ".pbas" or ".pinc" extension

'------------------------------------------------------------------------------
'   ** Declarations **
'------------------------------------------------------------------------------
DECLARE CALLBACK FUNCTION ShowVB2PBVBCODETOKENIZERProc()
DECLARE FUNCTION ShowVB2PBVBCODETOKENIZER(BYVAL hParent AS DWORD) AS LONG
#PBFORMS DECLARATIONS

'------------------------------------------------------------------------------

'------------------------------------------------------------------------------
'   ** Main Application Entry Point **
'------------------------------------------------------------------------------
FUNCTION PBMAIN()
    ShowVB2PBVBCODETOKENIZER %HWND_DESKTOP
END FUNCTION
'------------------------------------------------------------------------------

'------------------------------------------------------------------------------
'   ** CallBacks **
'------------------------------------------------------------------------------
CALLBACK FUNCTION ShowVB2PBVBCODETOKENIZERProc()
    'local string manipulation vars
    LOCAL tempString        AS STRING
    LOCAL sTemp             AS STRING
    LOCAL promptString      AS STRING
    LOCAL defaultString     AS STRING

    'local drag-drop handling vars
    LOCAL lOffset           AS LONG
    LOCAL lLength           AS LONG
    LOCAL i                 AS LONG
    LOCAL lFileCnt          AS LONG
    LOCAL szFile            AS ASCIIZ * %MAX_PATH
    LOCAL lResult           AS LONG

    'application vars & message flags
    LOCAL vb2pbSaveFile     AS INTEGER              'Progress file for SaveAndExit
    LOCAL ErrorCode         AS LONG

    STATIC TokenizerStatus  AS LONG                 'current program status
    STATIC PreviousStatus   AS LONG                 'previous program status
    STATIC ProjectIsParsed  AS LONG
    STATIC ProjectIsSaved   AS LONG
    STATIC ErrorCount       AS LONG                 'count parsing errors ignored
    STATIC AutoDelay        AS LONG                 'length of display window delay in 250msec increments
    STATIC AutoPause        AS LONG                 'T/F pause after each line until user clicks NEXT/PREV/FIRST/LAST

    'VB6 source code variables
    LOCAL vbSourceFileName  AS STRING               'VB6 input file name
    LOCAL vbSourceFile      AS STRING               'VB6 input file #
    LOCAL vbCodeLine        AS STRING               'VB6 source code line

    STATIC CurrentTerm      AS STRING               'VB6 term being analyzed

    'PBWin source code variables
    LOCAL pbSourceFileName  AS STRING               'PBWin output file name
    LOCAL pbSourceFile      AS INTEGER              'PBWin output file #
    LOCAL pbCodeLine        AS STRING * 256         'PBWin codeline build string


    'handle callback messages
    SELECT CASE AS LONG CBMSG
        CASE %WM_INITDIALOG
            ' Initialization handler
            DragAcceptFiles CBHNDL, %TRUE           'set initial flag values
            TokenizerStatus = %IsReady
            PreviousStatus = %Isready
            ProjectIsParsed = %False
            ProjectIsSaved = %True
            CurrentTerm = SPACE$(32)
            AutoDelay = 0
            AutoPause = %False

            'Make subfolder for completed PBWin files
            PBWinSubFolder = CURDIR$ & "\PBWinFiles"
            MKDIR PBWinSubFolder


        CASE %WM_DROPFILES
            ' Drag+Drop file handler
            lFileCnt = DragQueryFile(CBWPARAM, -1, BYVAL 0, 0)
            FOR i = 0 TO lFileCnt - 1
                DragQueryFile CBWPARAM, i, szFile, SIZEOF(szFile)

                tempString = TRIM$(szFile)
                ParseReportFileList = ParseReportFileList & tempString & $Separator   'master list to process

                lLength = LEN(tempString)
                IF lLength > %ListBoxLineLength THEN    'reduce drv/path/file string to displayable size
                    sTemp = STRREVERSE$(tempString)     '   (ParseReportFileList retains full path info)
                    lOffset = INSTR(sTemp, ANY "\/") - 1
                    sTemp = RIGHT$(tempString, lOffset)
                    tempString = LEFT$(tempString, (%ListBoxLineLength - (LEN(sTemp) + 4))) & "...\" & sTemp
                END IF
                LISTBOX ADD CBHNDL, %IDC_lbxVBPROJECTFILES, tempString
            NEXT i
            DragFinish CBWPARAM

        CASE %WM_DESTROY
            ' Clean up before dialog is destroyed
            DragAcceptFiles CBHNDL, %FALSE

        CASE %WM_NCACTIVATE
            STATIC hWndSaveFocus AS DWORD
            IF ISFALSE CBWPARAM THEN
                ' Save control focus
                hWndSaveFocus = GetFocus()
            ELSEIF hWndSaveFocus THEN
                ' Restore control focus
                SetFocus(hWndSaveFocus)
                hWndSaveFocus = 0
            END IF

        CASE %WM_COMMAND
            ' Process control notifications
            SELECT CASE AS LONG CBCTL
                '%IDC_txtVBcodeLine
                '%IDC_txtPowerBASICcodeLine
                CASE %IDC_cmdBEGINPROCESS
                    IF CBCTLMSG = %BN_CLICKED THEN
                        TokenizerStatus = %IsRunning
                        ProjectIsSaved = %False

                        IF ISFALSE ProjectIsParsed THEN
                            'parse the files in the ListBox
                            lFileCnt = TALLY(ParseReportFileList, $Separator)

                            FOR i = 1 TO lFileCnt
                                tempString = "StansVbCodeLineParser.exe " _
                                             & PARSE$(ParseReportFileList, $Separator, i)

                                SHELL tempString
                                ErrorCode = ERRCLEAR    'check for error & clear err value
                                IF ErrorCode THEN       'if error offer some choices
                                    lResult = MSGBOX ("Parsing error." & $CRLF _
                                                     & REMAIN$(tempString, "StansVbCodeLineParser.exe ") _
                                                     & "Error: " & ERROR$(ErrorCode), _
                                                     %MB_ABORTRETRYIGNORE OR %MB_TASKMODAL, $Title)
                                    SELECT CASE lResult
                                        CASE IS %IDABORT
                                            CLOSE
                                            CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, "Aborting Program"
                                            CONTROL POST CBHNDL, %IDC_cmdQUIT, %BN_CLICKED, 0, 0
                                            EXIT FUNCTION

                                        CASE IS %IDRETRY
                                            CLOSE
                                            CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, "Redoing Parse VB6 code"
                                            CONTROL POST CBHNDL, %IDC_cmdBEGINPROCESS, %BN_CLICKED, 0, 0
                                            EXIT FUNCTION

                                        CASE IS %IDIGNORE
                                            INCR ErrorCount
                                            tempString = "Ignoring Parse Error #" & TRIM$(STR$(ErrorCount))
                                            CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, tempString

                                    END SELECT
                                END IF
                            NEXT i
                            ProjectIsParsed = %True
                        END IF

                        'main Tokenizer code goes here !!


                    END IF

                CASE %IDC_cmdAutoDelay      'INCR AutoDelay by 250 msec per click
                    IF CBCTLMSG = %BN_CLICKED THEN
                        AutoDelay = AutoDelay + 250
                        tempString = "AutoDelay = " & TRIM$(STR$(AutoDelay)) & " mSecs"
                        CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, tempString
                    END IF

                CASE %IDC_cmdLineByLine     'pause after each line is displayed
                    IF CBCTLMSG = %BN_CLICKED THEN
                        AutoPause = %True
                        tempString = "Line by line review"
                        CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, tempString
                    END IF

                CASE %IDC_cmdNoDelay        'no delay / reset AutoDelay = 0
                    IF CBCTLMSG = %BN_CLICKED THEN
                        AutoDelay = 0
                        AutoPause = %False
                        tempString = "Normal speed operation"
                        CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, tempString
                    END IF

                CASE %IDC_cmdPAUSE
                    IF CBCTLMSG = %BN_CLICKED THEN
                        IF TokenizerStatus = %IsPaused THEN
                            TokenizerStatus = PreviousStatus
                            CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, "Status Messages"
                        ELSE
                            PreviousStatus = TokenizerStatus
                            TokenizerStatus = %IsPaused
                            CONTROL SET TEXT CBHNDL, %IDC_lblSTATUSMESSAGES, "Paused"
                        END IF

                        IF TokenizerStatus = %IsPaused THEN    'enter pause mode
                            CONTROL SET TEXT CBHNDL, %IDC_cmdPAUSE, "Continue"
                            CONTROL DISABLE CBHNDL, %IDC_cmdBEGINPROCESS
                        ELSE                                    'exit pause mode
                            CONTROL SET TEXT CBHNDL, %IDC_cmdPause, "Pause"
                            CONTROL ENABLE CBHNDL, %IDC_cmdBEGINPROCESS
                        END IF
                    END IF

                CASE %IDC_cmdSAVEANDEXIT
                    IF CBCTLMSG = %BN_CLICKED THEN
                        ProjectIsSaved = %True

                        'open vb2pbSaveFile
                        vb2pbSaveFile = FREEFILE
                        OPEN "SaveFile.vb2pb" FOR BINARY AS vb2pbSaveFile

                        'save GLOBALS -- no need to save temp files, just leave them where they are
                        PUT #vb2pbSaveFile, , vbProjectName
                        PUT #vb2pbSaveFile, , ParseReportFileList
                        PUT #vb2pbSaveFile, , PropertyArray()
                        PUT #vb2pbSaveFile, , FunctionArray()
                        PUT #vb2pbSaveFile, , EventArray()
                        PUT #vb2pbSaveFile, , ClassArray()
                        PUT #vb2pbSaveFile, , VariableNames()
                        PUT #vb2pbSaveFile, , VariantNames()
                        PUT #vb2pbSaveFile, , pbSourceFileList
                        PUT #vb2pbSaveFile, , PBWinSubFolder

                        CLOSE #vb2pbSavefile    'close the file

                        'verify quit
                        lResult = MSGBOX("Process saved. Quit now?", %MB_TASKMODAL OR %MB_YESNO, $Title)
                        IF lResult = %IDYES THEN
                            DIALOG END CBHNDL       'quit and go home
                        ELSE
                            KILL "SaveFile.vb2pb"   'kill the save file - we'll make another if we need it
                        END IF
                    END IF

                CASE %IDC_cmdQUIT
                    IF CBCTLMSG = %BN_CLICKED THEN
                        lResult = MSGBOX("Do you really want to quit without saving?", %MB_TASKMODAL OR %MB_YESNO, $Title)
                        IF lResult = %IDYES THEN
                            'remove any .parsRpt files
                            IF LEN(ParseReportFileList) > 0 THEN
                                ON ERROR RESUME NEXT        'ignore any file errors in FOR/NEXT loop
                                lFileCnt = TALLY(ParseReportFileList, $Separator)
                                FOR i = 1 TO lFileCnt
                                    tempString = PARSE$(ParseReportFileList, $Separator, i) & ".parsRpt"
                                    KILL tempString
                                NEXT i
                                ON ERROR GOTO 0     'turn off error trap
                                ERRCLEAR            'reset system error
                            END IF

                            'remove any .pbas files
                            IF LEN(pbSourceFileList) > 0 THEN
                                ON ERROR RESUME NEXT        'ignore any file errors in FOR/NEXT loop
                                lFileCnt = TALLY(pbSourceFileList, $Separator)
                                FOR i = 1 TO lFileCnt
                                    tempString = PARSE$(pbSourceFileList, $Separator, i) & ".pbas"
                                    KILL tempString
                                NEXT i
                                ON ERROR GOTO 0     'turn off error trap
                                ERRCLEAR            'reset system error
                            END IF

                            'remove PBWin subfolder
                            CHDIR PBWinSubFolder
                            SHELL ENVIRON$("COMSPEC") & "/C del *.*"
                            CHDIR " .."
                            RMDIR PBWinSubFolder

                            'now the program commits suicide
                            DIALOG END CBHNDL
                        END IF
                    END IF

' *** I put these CASEs in after reading your posts so there's no code yet ***
                CASE %IDC_cmdALTERNATEEDITOR1
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

                CASE %IDC_cmdALTERNATEEDITOR2
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

                CASE %IDC_cmdALTERNATEGUITOOL1
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

                CASE %IDC_cmdALTERNATEGUITOOL2
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

                CASE %IDC_cmdVIEWPBWIN804SOURCECODE
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

                CASE %IDC_cmdVIEWVB60SOURCECODE
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

                CASE %IDC_cmdPBFORMS151
                    IF CBCTLMSG = %BN_CLICKED THEN

                    END IF

            END SELECT
    END SELECT
END FUNCTION
'------------------------------------------------------------------------------

'------------------------------------------------------------------------------
'   ** Dialogs **
'------------------------------------------------------------------------------
FUNCTION ShowVB2PBVBCODETOKENIZER(BYVAL hParent AS DWORD) AS LONG
    LOCAL lRslt  AS LONG

#PBFORMS BEGIN DIALOG %IDD_VB2PBVBCODETOKENIZER->->
    LOCAL hDlg   AS DWORD
    LOCAL hFont1 AS DWORD
    LOCAL hFont2 AS DWORD

    DIALOG NEW hParent, "vb2pb VB Code Tokenizer", 93, 158, 508, 336, _
        %WS_POPUP OR %WS_BORDER OR %WS_DLGFRAME OR %WS_SYSMENU OR _
        %WS_MINIMIZEBOX OR %WS_CLIPSIBLINGS OR %WS_VISIBLE OR %DS_SYSMODAL _
        OR %DS_MODALFRAME OR %DS_3DLOOK OR %DS_NOFAILCREATE OR %DS_SETFONT, _
        %WS_EX_CLIENTEDGE OR %WS_EX_STATICEDGE OR %WS_EX_WINDOWEDGE OR _
        %WS_EX_ACCEPTFILES OR %WS_EX_CONTROLPARENT OR %WS_EX_LEFT OR _
        %WS_EX_LTRREADING OR %WS_EX_RIGHTSCROLLBAR, TO hDlg
    DIALOG  SET COLOR    hDlg, %BLUE, %CYAN
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdBEGINPROCESS, "Begin Process", 130, 5, _
        70, 15, %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP OR %BS_TEXT OR _
        %BS_DEFPUSHBUTTON OR %BS_PUSHBUTTON OR %BS_CENTER OR %BS_VCENTER, _
        %WS_EX_LEFT OR %WS_EX_LTRREADING
    DIALOG  SEND         hDlg, %DM_SETDEFID, %IDC_cmdBEGINPROCESS, 0
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdQUIT, "QUIT", 415, 5, 70, 15
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdPAUSE, "Pause", 225, 5, 70, 15
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdSAVEANDEXIT, "Save and Exit", 320, 5, _
        70, 15
    CONTROL ADD TEXTBOX, hDlg, %IDC_txtVBcodeLine, "", 5, 25, 495, 35, _
        %WS_CHILD OR %WS_VISIBLE OR %WS_VSCROLL OR %ES_LEFT OR %ES_MULTILINE _
        OR %ES_AUTOVSCROLL OR %ES_READONLY, %WS_EX_CLIENTEDGE OR %WS_EX_LEFT _
        OR %WS_EX_LTRREADING OR %WS_EX_RIGHTSCROLLBAR
    CONTROL ADD TEXTBOX, hDlg, %IDC_txtPowerBASICcodeLine, "", 5, 85, 495, _
        35, %WS_CHILD OR %WS_VISIBLE OR %WS_VSCROLL OR %ES_LEFT OR _
        %ES_MULTILINE OR %ES_AUTOVSCROLL OR %ES_READONLY, %WS_EX_CLIENTEDGE _
        OR %WS_EX_LEFT OR %WS_EX_LTRREADING OR %WS_EX_RIGHTSCROLLBAR
    CONTROL ADD TEXTBOX, hDlg, %IDC_txtVBProjectName, "", 70, 135, 290, 15, _
        %WS_CHILD OR %WS_VISIBLE OR %ES_LEFT OR %ES_AUTOHSCROLL OR _
        %ES_READONLY, %WS_EX_CLIENTEDGE OR %WS_EX_LEFT OR %WS_EX_LTRREADING _
        OR %WS_EX_RIGHTSCROLLBAR
    CONTROL ADD LISTBOX, hDlg, %IDC_lbxVBPROJECTFILES, , 55, 155, 440, 105, _
        %WS_CHILD OR %WS_VISIBLE OR %WS_HSCROLL OR %WS_VSCROLL OR _
        %LBS_EXTENDEDSEL OR %LBS_SORT OR %LBS_NOTIFY OR %LBS_HASSTRINGS OR _
        %LBS_WANTKEYBOARDINPUT, %WS_EX_CLIENTEDGE OR %WS_EX_LEFT OR _
        %WS_EX_LTRREADING OR %WS_EX_RIGHTSCROLLBAR
    CONTROL ADD LABEL,   hDlg, %IDC_LABEL1, "VB 6.0 Code Line", 5, 10, 75, 15
    CONTROL SET COLOR    hDlg, %IDC_LABEL1, %BLUE, %CYAN
    CONTROL ADD LABEL,   hDlg, %IDC_LABEL2, "PowerBASIC 8.04 Code Line", 5, _
        70, 120, 15
    CONTROL SET COLOR    hDlg, %IDC_LABEL2, %BLUE, %CYAN
    CONTROL ADD LABEL,   hDlg, %IDC_LABEL3, "VB 6.0 Project", 7, 135, 65, 15
    CONTROL SET COLOR    hDlg, %IDC_LABEL3, %BLUE, %CYAN
    CONTROL ADD LINE,    hDlg, %IDC_LINE1, "Line1", 1, 125, 504, 5, %WS_CHILD _
        OR %WS_VISIBLE OR %SS_GRAYRECT
    CONTROL ADD LABEL,   hDlg, %IDC_LABEL4, "UnSelect VB6 files you don't " + _
        "want to process", 5, 155, 50, 55
    CONTROL SET COLOR    hDlg, %IDC_LABEL4, %BLUE, %CYAN
    CONTROL ADD LABEL,   hDlg, %IDC_lblSTATUSMESSAGES, "Status Messages", _
        365, 135, 130, 15, %WS_CHILD OR %WS_VISIBLE OR %SS_CENTER, _
        %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL SET COLOR    hDlg, %IDC_lblSTATUSMESSAGES, %BLUE, %YELLOW
    CONTROL ADD LABEL,   hDlg, %IDC_LABEL5, "default:        all selcted " + _
        "files will be processed", 5, 210, 50, 45
    CONTROL SET COLOR    hDlg, %IDC_LABEL5, %BLUE, %CYAN
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdLineByLine, "Line by Line", 225, 65, _
        70, 15
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdAutoDelay, "Auto Delay", 320, 65, 70, _
        15
    CONTROL ADD LABEL,   hDlg, %IDC_lblPROGRESSOPTIONS, "Progress Display " + _
        "Options", 155, 60, 65, 25
    CONTROL SET COLOR    hDlg, %IDC_lblPROGRESSOPTIONS, %BLUE, %CYAN
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdNoDelay, "No Delay", 415, 65, 70, 15
    CONTROL ADD LINE,    hDlg, %IDC_LINE3, "Line1", 2, 265, 504, 5, %WS_CHILD _
        OR %WS_VISIBLE OR %SS_GRAYRECT
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdVIEWVB60SOURCECODE, "View VB 6.0 " + _
        "Source Code", 8, 280, 60, 45, %WS_CHILD OR %WS_VISIBLE OR _
        %WS_TABSTOP OR %BS_TEXT OR %BS_MULTILINE OR %BS_PUSHBUTTON OR _
        %BS_CENTER OR %BS_VCENTER, %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdVIEWPBWIN804SOURCECODE, "VIEW PBWin " + _
        "8.04 Source in PB IDE", 80, 280, 60, 45, %WS_CHILD OR %WS_VISIBLE _
        OR %WS_TABSTOP OR %BS_TEXT OR %BS_MULTILINE OR %BS_PUSHBUTTON OR _
        %BS_CENTER OR %BS_VCENTER, %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdPBFORMS151, "PBForms 1,51", 152, 280, _
        60, 45, %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP OR %BS_TEXT OR _
        %BS_MULTILINE OR %BS_PUSHBUTTON OR %BS_CENTER OR %BS_VCENTER, _
        %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdALTERNATEEDITOR1, "Select Alternate " + _
        "Editor #1", 224, 280, 60, 45, %WS_CHILD OR %WS_VISIBLE OR _
        %WS_TABSTOP OR %BS_TEXT OR %BS_MULTILINE OR %BS_PUSHBUTTON OR _
        %BS_CENTER OR %BS_VCENTER, %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdALTERNATEEDITOR2, "Select Alternate " + _
        "Editor #2", 296, 280, 60, 45, %WS_CHILD OR %WS_VISIBLE OR _
        %WS_TABSTOP OR %BS_TEXT OR %BS_MULTILINE OR %BS_PUSHBUTTON OR _
        %BS_CENTER OR %BS_VCENTER, %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdALTERNATEGUITOOL1, "Select Alternate   " + _
        "GUI Tool #1", 368, 280, 60, 45, %WS_CHILD OR %WS_VISIBLE OR _
        %WS_TABSTOP OR %BS_TEXT OR %BS_MULTILINE OR %BS_PUSHBUTTON OR _
        %BS_CENTER OR %BS_VCENTER, %WS_EX_LEFT OR %WS_EX_LTRREADING
    CONTROL ADD BUTTON,  hDlg, %IDC_cmdALTERNATEGUITOOL2, "Select Alternate   " + _
        "GUI Tool #2", 440, 280, 60, 45, %WS_CHILD OR %WS_VISIBLE OR _
        %WS_TABSTOP OR %BS_TEXT OR %BS_MULTILINE OR %BS_PUSHBUTTON OR _
        %BS_CENTER OR %BS_VCENTER, %WS_EX_LEFT OR %WS_EX_LTRREADING

    hFont1 = PBFormsMakeFont("MS Sans Serif", 10, 400, %FALSE, %FALSE, _
        %FALSE, %ANSI_CHARSET)
    hFont2 = PBFormsMakeFont("Courier New", 10, 400, %FALSE, %FALSE, %FALSE, _
        %ANSI_CHARSET)

    DIALOG  SEND hDlg, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdBEGINPROCESS, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdQUIT, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdPAUSE, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdSAVEANDEXIT, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_txtVBcodeLine, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_txtPowerBASICcodeLine, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_txtVBProjectName, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_lbxVBPROJECTFILES, %WM_SETFONT, hFont2, 0
    CONTROL SEND hDlg, %IDC_LABEL1, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_LABEL2, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_LABEL3, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_LINE1, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_LABEL4, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_lblSTATUSMESSAGES, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_LABEL5, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdLineByLine, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdAutoDelay, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_lblPROGRESSOPTIONS, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdNoDelay, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_LINE3, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdVIEWVB60SOURCECODE, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdVIEWPBWIN804SOURCECODE, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdPBFORMS151, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdALTERNATEEDITOR1, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdALTERNATEEDITOR2, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdALTERNATEGUITOOL1, %WM_SETFONT, hFont1, 0
    CONTROL SEND hDlg, %IDC_cmdALTERNATEGUITOOL2, %WM_SETFONT, hFont1, 0
#PBFORMS END DIALOG

    DIALOG SHOW MODAL hDlg, CALL ShowVB2PBVBCODETOKENIZERProc TO lRslt

#PBFORMS BEGIN CLEANUP %IDD_VB2PBVBCODETOKENIZER
    DeleteObject hFont1
    DeleteObject hFont2
#PBFORMS END CLEANUP

    FUNCTION = lRslt
END FUNCTION
'------------------------------------------------------------------------------

**Rodney Hicks** · 19 Jul 2008, 02:03 AM

I compiled an ran your last submission in this thread.

Looking at the setup two things come to mind real quick.

First- Could we make it so it just converts selected code from the file. Anything from a single line, a single multi-line function/sub, or two or twenty or the whole file? Or should we save that for a later version? John alluded to something like this when he started this thread I believe. Well, because John said what he said the idea came to my mind about this. More on this later if you think it has merit.

Two- Of the seven options on the bottom, I would only have the first two or three activated. I'm not sure about how we're going to convert the VB into PB forms as well as PB. When using PBForms for a new project it's wonderful, but then a user is using it the way it was designed. We, on the other hand, are going to try and stuff things in the back door so to speak and that may create issues we have never even thought of and know nothing about. Not a big concern at this point in time though.

As for using different editors and such, if those buttons are there inactivated the user can write his own code to support the editor of their choice and activate the appropriate button. This way we only have to worry about making sure that it works with the PB editor, which is the point of the whole project.

Otherwise, a pretty good layout! Some users may want the ability to maximize the window, users not all being the same. (Good thing too.)

The "SAVE and EXIT" button should be just "SAVE" perhaps?
The project file dialog should set some options of its own for saving the file, whether appending to a file, creating an include, likely including default paths and such. We may even have to rely on user input with regards to file saving at each instance.

I will admit that I have not even been thinking about this end of the converter, so now that you've brought it to the forefront of my mind I may have other thoughts and will post them for perusal.

Rod

**StanHelton** · 19 Jul 2008, 06:48 AM

Originally posted by Rodney Hicks View Post

I compiled an ran your last submission in this thread.

Looking at the setup two things come to mind real quick.

First- Could we make it so it just converts selected code from the file. Anything from a single line, a single multi-line function/sub, or two or twenty or the whole file? Or should we save that for a later version? John alluded to something like this when he started this thread I believe. Well, because John said what he said the idea came to my mind about this. More on this later if you think it has merit.

Still a skeleton at this point. We can do anything we want to with it. I like the idea of selecting parts of the code to convert piecemeal, so to speak. Adding a Procedure Lookup is certainly easy enough to do.

Two- Of the seven options on the bottom, I would only have the first two or three activated. I'm not sure about how we're going to convert the VB into PB forms as well as PB. When using PBForms for a new project it's wonderful, but then a user is using it the way it was designed. We, on the other hand, are going to try and stuff things in the back door so to speak and that may create issues we have never even thought of and know nothing about. Not a big concern at this point in time though.

PBForms has a nice import option for VB .frm files. The conversion is almost 100% for standard controls and comes pretty close for most others (except ActiveX of course).

As for using different editors and such, if those buttons are there inactivated the user can write his own code to support the editor of their choice and activate the appropriate button. This way we only have to worry about making sure that it works with the PB editor, which is the point of the whole project.

Great! That's what I was thinking when I read John's opening post.

Otherwise, a pretty good layout! Some users may want the ability to maximize the window, users not all being the same. (Good thing too.)

The "SAVE and EXIT" button should be just "SAVE" perhaps?
The project file dialog should set some options of its own for saving the file, whether appending to a file, creating an include, likely including default paths and such. We may even have to rely on user input with regards to file saving at each instance.

I'll make those changes today.

I will admit that I have not even been thinking about this end of the converter, so now that you've brought it to the forefront of my mind I may have other thoughts and will post them for perusal.

Rod

I think it's time to think about this. I'm not sure when/if Elias is coming back in time for the back end planning. I've been worried about it for a week or more now and John's post got me motivated to begin looking at it seriously.

Stan

**John R. Heathcote** · 19 Jul 2008, 04:44 PM

Stan and Rod,

It is gratifying to know I stimulated some discussion on user issues, my mission is accomplished.

Stan I will take a look at your tokenizer, maybe it will fit in with my Scintilla efforts in FireFly. The main reason I mentioned Scintilla is the fact I actually got the d*mn thing to work. Right now it doesn't do much except show the source code file in a separate tab, but the concept is something to think about.

Hopefully, when I look at the tokenizer it will probably stimulate other ideas as well. My doctor says this type of activity is good for my brain, so the VB converter project is my own form of therapy so to speak.

Did you get the "Forward Refs" application?

**John R. Heathcote** · 19 Jul 2008, 08:09 PM

Stan,

Still haven't figured out the debug part, though. I'd like to hear more -- John, if you have ideas on how to implement a debug without resorting to the IDEs I am very interested!

I really don't know how we would do this either. Personally I think the VB programmer would want to use the step debugger as this is the type of environment that the user is used to while programming VB, so I don't think we want to debug in the background or hide the process, keep everything up front and available. The biggest hurdle the future user faces when they first use PB is the absence of the "Edit and Go" feature in VB. I know I have tried to make code changes in the PB editor only to be told that you can't do this while in PB debug mode. Gentle reminders are everywhere.

I took a look at the "Tokenizer" and it does look functional even if, IMO, it is a bit busy. There is a lot there in the dialog box to digest. Could this be simplified by splitting up like functionality and placing it on a tab, for example? That way not so much information is presented to a user at one time. It has been my experience that users tend to shy away from or are intimidated by Windows applications that have complicated or overly busy dialog boxes. How we present the converter to the user will be just as important as the converter functionality itself.

A rule of thumb I've tried to follow in GUI design is the billboard principle, never present more information in your dialog box than a user could comfortably read while driving by it at 60 mph. The most effective billboards (and dialog boxes) are the ones that contain very little data, few pictures or graphics and instantly conveys the meaning, use, or the message of the product. I have a gut feeling the conversion process will be a rather complicated one once some of the more exotic converter routines are available to the user, so we shouldn't complicate things by making the GUI busy or give the impression that it is complicated to use.

Stan, please don't think I'm going out of my way to pick on your efforts, I'm not. I have personally used applications where companies charged $3500 or more for their software that had horribly designed, complicated dialog boxes (and they thought this was OK) and it was easy to see that the programmer and the quality assurance department did NOT seriously take user needs into account. So it is good that we are talking about user issues and attempting to make the conversion process as painless as possible.

Rod,

First- Could we make it so it just converts selected code from the file. Anything from a single line, a single multi-line function/sub, or two or twenty or the whole file? Or should we save that for a later version? John alluded to something like this when he started this thread I believe. Well, because John said what he said the idea came to my mind about this. More on this later if you think it has merit.

I think this is a great idea!!! Never even remotely considered this functionality myself. I will take a look at this in my FireFly project to see how difficult it is to do. BTW, I will send out my coding efforts to date using Scintilla in an effort to stimulate further discussion after I clean it up a bit and add some more functionality.

**Rodney Hicks** · 20 Jul 2008, 02:20 AM

It is gratifying to know I stimulated some discussion on user issues, my mission is accomplished.

So am I.
Earlier on, while there were a few others helping out, I had left this part to them while I started working on the dictionary. There was a general agreement, consensus, at least thought in the back of our heads, that this was going to be a command line tool first, and develop the GUI to fit. I think our thoughts are past that command line version at the moment, but it still has a lot of merit, especially in terms of simplicity. A few parameters and let it do its thing. Such an animal would have to be quite bit more exact than we can make our first version. I think.

John
Your ideas on keeping the bare minimum of items staring the user in the face does have some merit, and I'll go along with that assuming Stan likes it too. I would like this project to end up like whatever Stan had in mind when he first mentioned it, if he had a picture at all. We've been calling that the KISS principle (billboard) by the way.

I have also had programs that kept it simple, and once I'd used them a time or two and got accustomed to them, I'd wished that I'd had more options staring me in the face, but that's just a me thing.

So it is good that we are talking about user issues and attempting to make the conversion process as painless as possible.

It is the learning process that seems to be the most painful. There seems to be a lot of things that were obfuscated in VB. At least that's what I found when I tried to work with it many years ago.Version 1 or 2. We are hoping that seeing the converted files will help the VBers adjust to PB more easily, as well as make use of a few million lines of code that they worked on and don't want to see go to waste.

Stan and John, and anyone else for that matter.

With regard to the debugging of the converted code. Since it is going to have to run through the PB compiler, there isn't much sense in us developing another debugger(yet). Currently, when I write a program, I compile and run it quite often. Like sometimes after adding one line of code, one loop, one block, one function, macro, etc. Since the compiler is so fast, and it catches most of the problems right off the hop, the debugging can be as stringent as the user wants. This may not be a cure all, but it makes it work for the time being. If we set this up so users can quickly load, compile and run in the PB IDE similar to how changes made in PBForms are caught so you reload the file in the PB IDE.

PBForms has a nice import option for VB .frm files. The conversion is almost 100% for standard controls and comes pretty close for most others (except ActiveX of course).

This, not being a VBer, I had forgotten about. This could make our job an awful lot easier. Providing the users of the converter have PBForms. Are we going to make that a requirement along with the PB IDE? I think we should.
That feature alone might solve some of the debugging issues, like how to get it to the debugger quickly.

Stan, please don't think I'm going out of my way to pick on your efforts, I'm not.

If I may be so bold to seem answer for Stan, rest assured that new ways of looking at things can have a very positive effect, so I don't think he'll mind.

Rod

**John R. Heathcote** · 20 Jul 2008, 10:55 AM

Rod,

I think it is possible to send files/projects from our converter to the PB IDE for compiling and debugging. While looking at Jose Roca's latest version of SED I found a code section where he sends the files/project from SED to the PB IDE to be compiled and debugged, and will even start the PB IDE if it is not already running. Sounds to me this is exactly what we want to do. So the grunt work has already been done, all we have to do is use Jose's code, again giving proper credit where it is due.

As far as developing our own debugger, do we really want to do that? I, for one, am perfectly content to use the PB compiler and debugger that I purchased from Mr. Zale. I think the real question here is can we upload the converted files/project into the PB IDE for eventual compiling and debugging in a reliable and consistent manner? Jose has shown us the way.

I know I have been plagued by functionality creep in my applications too, I think this is an inevitable phenomenon in application development. Perhaps I was just thinking out loud, but the experience with that "other" company and their lousy overpriced, overly complicated, and often times confusing software is not something one quickly forgets. What bothered me was the absolute disdain and contempt the developers and management staff had for their end users, and they had the gall to actually charge top dollar for their software.

A thought on the dictionary. You and Stan mentioned the dictionary is getting quite large, and it occurs to me the larger it gets the more difficult it will be to maintain and update it. Would it be possible to break it up in logical sections? Sections such as a separate dictionary to handle the 1:1 VB to PB conversions, maybe a separate dictionary to handle VB objects, etc. Of course the downside here is the possibility that overlapping and conflicting functionality can creep in, as I said, just a thought.

I like the idea of a command based conversion system verses a GUI approach. The command concept puts the responsibility for the conversions squarely on the user's shoulders, which is as it should be. I would strongly suggest that the command concept be carried forward into the GUI. The problem with a totally GUI based approach is the fact that if a certain functionality is not found then the GUI has to be enhanced/complicated to accommodate the new processing requirements. Once this happens the KISS principle no longer has relevance, or is severly crippled. A command based system affords the user the opportunity to combine those commands together however they want to achieve an end result. The beauty here is with commands the user can approach the problem in many different ways to achieve the desired result, whereas the GUI by its very nature forces the user to accept a limited number of ways with rigidly controlled steps to accomplish the same thing.

**John R. Heathcote** · 20 Jul 2008, 02:25 PM

Rod and Stan,

Some additional quick comments on the dictionary, and I promise to keep it short and sweet.

Is it really necessary to have all VB keywords/terms in the dictionary, especially in view of the fact that many of the VB keywords do not need to be converted to PB? When I was a new PB user I was more interested in the VB key words and concepts that didn't work in PB as opposed to the VB keywords and concepts that did. While looking at the dictionary I noticed a great many VB entries that did not require conversion.

We should also look into the possibility to allow the user to create their own supplemental dictionary(s) to augment our dictionary. A future enhancement perhaps? This type of functionality would give the user the ability to customize the converter to their individual needs rather than depend on our concept of what we think the user needs. I think we do need to have a basic starting point and that is where our dictionary comes into play, but I think the user is going to want additional specialized capabilities not found in our dictionary to handle their unique coding styles.

Again, just thinking out loud.

**Rodney Hicks** · 20 Jul 2008, 04:42 PM

John

I promise to keep it short and sweet.

Verbose is okay as long as you're not repeating yourself. I mean as long as you don't say the same thing over and ....You know what I mean.

Besides it could lead to a little more clarity.

Is it really necessary to have all VB keywords/terms in the dictionary,

When the tokenizer, scanner, parser, lexer, thingy finds a term anywhere in the VB source code, it has to find out if that term matches a PB term, and the 'dictionary' is where it will make that distinction.

The dictionary is more than just a dictionary, for it will tell the converter to call up other functions and such, depending on the term. Some terms require assistance, maybe even user assistance, some require special consideration even though the term is similar to PB, and others can move right on by(Same words).

If we leave the similar terms out, we could default to using the same term, but that might allow variables or something worse to sneak willy-nilly into the code as if they were important terms since there would be no check on them.

As well, there a few terms that exist in both languages for entirely different reasons and the dictionary will sort them out. Leaving one less thing for the debugger to worry about.

We should also look into the possibility to allow the user to create their own supplemental dictionary(s) to augment our dictionary.

I like this. Never thought of it, wish I had. It's got an awful lot of potential.

Stan, is there some way that we could poll/ask the general forum members to list the specific terms they'd most like to have included in the converter? This in addition to John's suggestion.

I've been taking a look at the way PBForms converts the .frm files. Wow!

It's been so long since I tried VB that I don't remember the order of the steps taken to develop a project, or if there was an order, would someone refresh my memory, please?
A very brief summary is good.

Rod

**John R. Heathcote** · 20 Jul 2008, 06:15 PM

Rod,

This is how I would develop a VB project. Keep in mind I'm really an old FORTRAN IV/77 guy so I tended to code the same way even in VB. This is vary brief overview, except for the cursing Windows, VB, or both, part which tended to occur on a regular basis.

If this will be a complex project, write a function specification to outline processing requirements, input forms, output forms/files, etc., set up directory structures.
Create a new VB project.
Have a default start up form generated by VB. Alter this form to be the main application form.
Add additional forms, if necessary, as per functional spec.
Work on form design, user issues.
Set form level code to process control events.
Code processing modules, these modules are the guts of the app.
Add previously defined modules as necessary to augment or complete processing.
Debug with user input data.
Curse because VB crashed Windows when it wasn't supposed to.
Serious crash goto step 3.
Other crashes, goto step 4, 5 or 6
Minor crashes goto step 7, 8, or 9 (if user data was invalid)
Otherwise Done

The dictionary.

The dictionary is more than just a dictionary, for it will tell the converter to call up other functions and such, depending on the term. Some terms require assistance, maybe even user assistance, some require special consideration even though the term is similar to PB, and others can move right on by(Same words).

I see, I wasn't aware that this was the level to which we were parsing and identifying VB keywords. Maybe when we get a little more experience with the conversion process some of the VB keyword issues could be accepted as is, since one of PB advertising strengths is the "ability to run VB code as is". By its very nature PB does maintain a good deal of compatibility with VB 6.0. VB Net will be a whole 'nother story.

If we leave the similar terms out, we could default to using the same term, but that might allow variables or something worse to sneak willy-nilly into the code as if they were important terms since there would be no check on them.

Perhaps this should be a user option or an optional configuration. I know my VB code does not require this level of interaction to convert it to PB due to the method I chose to write the original VB source code, but that is just me.

Do you forsee the converter performing a cursory scanning check of the VB source code files for suspicious keyword use or something that cannot be parsed altogether? I think it would be useful to perform this scan as a user defined option. I know I would like to know where these problem areas are in my VB code before I even tried to convert to PB.

It is beginning to sound like there should be a bare bones attempt at conversion such as converting the 1:1 VB keywords. The more complicated the request, the deeper the converter will parse the VB code.

**Rodney Hicks** · 20 Jul 2008, 10:47 PM

Thanks for the summary, John, it sort of fits the idea that I had in my head but wasn't too sure of.

It is beginning to sound like there should be a bare bones attempt at conversion such as converting the 1:1 VB keywords. The more complicated the request, the deeper the converter will parse the VB code.

I'm thinks similarly on this item.

since one of PB advertising strengths is the "ability to run VB code as is".

I don't ever recall seeing that stated, the closest that comes to mind is that PB for DOS programs might easily be used in PBCC under those conditions. However, I have not had my eye out for VB issues in PB since I never became accustomed to VB.

I have to disappear into the technology free wilds of Manitoba for a couple of days, may not get back until Wednesday.

Rod

**StanHelton** · 21 Jul 2008, 08:26 AM

Originally posted by John R. Heathcote View Post

Stan and Rod,

It is gratifying to know I stimulated some discussion on user issues, my mission is accomplished.

Stan I will take a look at your tokenizer, maybe it will fit in with my Scintilla efforts in FireFly. ...

If the Scintilla works we could insert it into the tokenizer at the appropriate place and solve the problem without overheating anybody's brain... I hope.

...
Did you get the "Forward Refs" application?

Yes, got it. I'm looking at it. Apologies for slow responses, but the desk is getting kind of piled up. I'll try to work through the stack a bit faster.

Stan

**StanHelton** · 21 Jul 2008, 08:40 AM

Originally posted by John R. Heathcote View Post

Stan,

... Personally I think the VB programmer would want to use the step debugger as this is the type of environment that the user is used to while programming VB, so I don't think we want to debug in the background or hide the process, keep everything up front and available...

I have to agree with Rod on the debugger then. Let's stick to the IDEs for now.

I took a look at the "Tokenizer" and it does look functional even if, IMO, it is a bit busy.

I get that a lot. I'm basically a self-taught programmer so I'm not sure what that really means.

One of these days I'm going to ask somebody -- it might be important.

There is a lot there in the dialog box to digest. Could this be simplified by splitting up like functionality and placing it on a tab, for example? ...

... I have a gut feeling the conversion process will be a rather complicated one once some of the more exotic converter routines are available to the user, so we shouldn't complicate things by making the GUI busy or give the impression that it is complicated to use.

I'm all for simple interfaces (KISS). In a later post Rod mentioned his feeling that he needed more functionality after getting used to the basic use of a new product. I tried to strike a balance, but feel free to make specific suggestions aimed at simplifying the GUI. I like the idea of tabs; I'll play with it some more and see what I can come up with.

Stan, please don't think I'm going out of my way to pick on your efforts....

I've had similar experience with large scale applications. Don't worry about my ego. It's tied up in producing a quality end product, not the details of how we get there.

Stan

**StanHelton** · 21 Jul 2008, 08:51 AM

Originally posted by Rodney Hicks View Post

....
Stan and John, and anyone else for that matter.

With regard to the debugging of the converted code. Since it is going to have to run through the PB compiler, there isn't much sense in us developing another debugger(yet). Currently, when I write a program, I compile and run it quite often. Like sometimes after adding one line of code, one loop, one block, one function, macro, etc. Since the compiler is so fast, and it catches most of the problems right off the hop, the debugging can be as stringent as the user wants. This may not be a cure all, but it makes it work for the time being. If we set this up so users can quickly load, compile and run in the PB IDE similar to how changes made in PBForms are caught so you reload the file in the PB IDE.

...

Are we going to make that a requirement along with the PB IDE? I think we should. That feature alone might solve some of the debugging issues, like how to get it to the debugger quickly.

I use a similar method when writing new code in PB. I think I remember one of the manuals suggesting this a long time ago. It's a good practice, a good way to learn the PB compilers, and I find it reduces my overall development time.

Using the respective IDEs is going to be essential in the first release. MS and Bob Zale have spent years building these things and we may as well take advantage of their work.

I also agree on requiring PBForms, at least in the first couple of releases. Hard to imagine how we could improve on its functionality working within the time limits we've established.

Stan

**StanHelton** · 21 Jul 2008, 09:18 AM

Originally posted by John R. Heathcote View Post

Rod,

I think it is possible to send files/projects from our converter to the PB IDE for compiling and debugging....

Absolutely! Jose Roca's name comes up frequently. On one occasion he even gave us a code sample to handle variants. I'm going to have to contact him about this. He's already done a lot of the things the Converter will have to do internally.

...
As far as developing our own debugger, do we really want to do that? ...

Emphatically, no.

A thought on the dictionary. You and Stan mentioned the dictionary is getting quite large, and it occurs to me the larger it gets the more difficult it will be to maintain and update it. Would it be possible to break it up in logical sections? Sections such as a separate dictionary to handle the 1:1 VB to PB conversions, maybe a separate dictionary to handle VB objects, etc. Of course the downside here is the possibility that overlapping and conflicting functionality can creep in, as I said, just a thought.

The size and complexity of the dictionary has been troubling me lately. My first idea was to build an index routine (also in PB) to handle dictionary edits & updates. It wouldn't require too much modification of the existing DictionaryTools module. Then Rod and I discussed some modifications to the record format. (That's in the Technical Issues thread if you want to take a look.) Still wrestling with it.

I like the idea of a command based conversion system verses a GUI approach. The command concept puts the responsibility for the conversions squarely on the user's shoulders, which is as it should be. I would strongly suggest that the command concept be carried forward into the GUI. The problem with a totally GUI based approach is the fact that if a certain functionality is not found then the GUI has to be enhanced/complicated to accommodate the new processing requirements. Once this happens the KISS principle no longer has relevance, or is severly crippled. A command based system affords the user the opportunity to combine those commands together however they want to achieve an end result. The beauty here is with commands the user can approach the problem in many different ways to achieve the desired result, whereas the GUI by its very nature forces the user to accept a limited number of ways with rigidly controlled steps to accomplish the same thing.

That's the best argument for a command line converter I've heard. Let's put it on the schedule for release 2.

Right now, I feel we should be taking the shortest line to the goal. I favor a simple GUI because it provides a built-in granularity (using DDT) for the individual capabilities of the converter. The one negative thought I have about a command line tool is that it requires a fairly complete knowledge of what the converter can be made to do before it's set up. For me, building a small GUI takes only a few minutes and gives me a way to focus on the individual internals.

This may be a completely personal method of working for me. I'm open to other ways of doing things.

Stan

**StanHelton** · 21 Jul 2008, 09:24 AM

Originally posted by John R. Heathcote View Post

Rod and Stan,
...

Is it really necessary to have all VB keywords/terms in the dictionary, especially in view of the fact that many of the VB keywords do not need to be converted to PB? When I was a new PB user I was more interested in the VB key words and concepts that didn't work in PB as opposed to the VB keywords and concepts that did. While looking at the dictionary I noticed a great many VB entries that did not require conversion.

Yes. The converter has to know which terms don't need to be translated. It also has to know how to adjust for syntax differences. I think this is a foundation capability for the converter, albeit one that will be totally transparent to the user.

We should also look into the possibility to allow the user to create their own supplemental dictionary(s) to augment our dictionary....

Excellent idea. Add it to the second release?

Stan

**StanHelton** · 21 Jul 2008, 09:31 AM

Originally posted by Rodney Hicks View Post

...
Stan, is there some way that we could poll/ask the general forum members to list the specific terms they'd most like to have included in the converter? This in addition to John's suggestion.

YES! That's the tag I was looking for to make a post in the general forums! Thank you, Rod.

I've been taking a look at the way PBForms converts the .frm files. Wow!

Neat.

Stan

Announcement

User Issues

User Issues

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment