Conventions

[Chris Holbrook]

Hash Table? Will we really need it?

ask me again when you want to go faster.

From the code I've written so far what seems to be the case is that many relatively small arrays holding all these goodies are what we need....All that is really needed is a small array to hold all the properties of a text box (50).

I saw it as scanning a VB statement for components between "separators", and translating those components, then reassembling the whole VB statement. There is an assumption in this that the expression is translated in the same way irrespective of its position in a statement. In other words, the context doesn't matter. Does this hold water? If so, then one big symbol table will work.

Question: objects and their properties/methods/events are OK if the objects are standard ones, but how do you deal with user-defined objects, etc. Presumably you have to dig the properties etc out of the code somehow.

It would be possible to have one large property array ...but why have to scan through an array holding 500 elements when you...know for absolute certin that you are dealing ...with a textbox and its 50 properties?

if the speed of access is not an issue then neither is the table size.

In terms of my early goal of first determining what general type of statement a program line is, i.e., assignment statement, use of reserved word, user function call, object method call -- well, "How many catagories do we really need?"

do you really need to know what sort of statement it is, or can you just identify expressions within the statement and translate them?

Should statements starting with a VB reserved word (verb?) be seperated out from Object Method calls? If there isn't an assignment statement involved, all these are rather similiar in terms of handling...

lstVBConverterMembers.AddItem "Stan Helton", 0
Erase vbObj
Call frmName_btnClose_Click()

The 1st will resolve ultimately (for me the Sdk'er) to a SendMessage() call on the listbox to add an item.

The second is a procedure call that VB itself sets in motion. The last is an ordinary procedure call.

As things stand now the 1st and 3rd will be identified and found in the Symbol Table. The middle one in a list of reserved words.

I think our views are converging!

[Rodney Hicks]

Gentlemen
There are VB specific words in all of the following categories:
Objects
Properties
Functions
Methods
Events
Statements
Keywords
Constants
Operators

There seems to be hundreds of them in total and the parser has to find our solution to each term.

The list I supplied earlier contains only 95 STATEMENTS and their equivant(or lack thereof)

In that list of statements it becomes readily apparent which areas of VB we need solutions for of those 95 statements for Stan's ultimate converter.

As KEYWORDS, FUNCTIONS, OPERATORS, are added to the list more items requiring specific code will become apparent. Some are quite innocuous, others not so.

And then come the more difficult(for me) ones. OBJECTS, EVENTS, METHODS,etc., although these still have to be parsed the same as a simple keyword.

The parser is going to have to decide which of the hundreds of possibles is applicable at each instance, possibly in some recursive fashion, and pass control over to the appropriate code, also possibly in recursive fashion. The parser may also need a 'look ahead' feature as well. EG: When it encounters "IF" it searches the following code to discern whether a single line "IF" statement or an "IF" block.

In my next submission I will post an array example since that's the only way I can see making this work.

This is causing neurons to go into some sort of recursive algorithm which at this point I'm not sure is resulting in me going in circles or spiraling. If the latter I hope I'm spiraling inwards.

Rod

[StanHelton]

so you see the keyword table as being a subset of the symbol table?

Yes. An instance table can be built from the master within the converter so that the master only gets scanned once.

Fred asks: objects and their properties/methods/events are OK if the objects are standard ones, but how do you deal with user-defined objects, etc. Presumably you have to dig the properties etc out of the code somehow.

User defined objects are built pretty much the same way a class is built, aren't they? If so, then the class convert module should be built to handle it.

from Chis:
if the speed of access is not an issue then neither is the table size.

do you really need to know what sort of statement it is, or can you just identify expressions within the statement and translate them?

I think our views are converging!

I think we need to know if it's an object.attribute reference or a udt.member reference. Can these two types be identified within the code line?

Fred points out the 50+ attributes built in. The number of attributes probably varies quite a bit between object, event, and method types, especially the user-defined ones. I don't see any other option than digging some (or all) of these out of the code itself.

Dumb question: don't all 3 get coded as classes?

[Rodney Hicks]

Chris asked:

do you really need to know what sort of statement it is, or can you just identify expressions within the statement and translate them?

Interesting question. My first response was what if the expression was used in an IF statement, it could be similar to a WHILE expression, or others. Further thought leads me to think that there may be opportunities to cut out needless code with some complicated statements. We may have to come back to this.

Does VB use short-circuit evaluation?

Rod

[Rodney Hicks]

Two possible UDTs to help us out. Other ideas welcomed.

TYPE SpecificWord
    vbTERM AS STRING*32   'the delimited word the parser will encounter
    pbTERM AS STRING*32   'the current equivalent of the vbTERM or if null a function call
    IsWhat AS LONG        '0=statement,1=keyword,2=function,4=Object,8=Event,16=Methods,32=constants,64=Properties,128=Operators
    Comment AS STRING*48  'a comment that may or may not be suitable to include in output source code
    QFlag AS LONG         'an as of yet undetermined usage
END TYPE

STATIC ParseTerm() AS SpecificWord
DIM ParseTerm(1000)

FUNCTION GetTerm(sParseWord,ParseTerm(?).IsWhat,QFlag)AS STRING

or

TYPE SpecificWord
    vbTERM AS STRING*32   'the delimited VB word the parser will encounter all are listed
    pbTERM AS STRING*32   'the current equivalent of the vbTERM or if null a function call
    IsWhat AS LONG        '0=statement,1=keyword,2=function,4=Object,8=Event,16=Methods,32=constants,64=Properties,128=Operators
    Params AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    Objcts AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    Props AS LONG         'the quantity for the sParseWord or the quantity it could be used in
    Meths AS LONG         'the quantity for the sParseWord or the quantity it could be used in
    Events AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    consts AS LONG        'the quantity for the sParseWord or the quantity it could be used in
    Options AS LONG       'the quantity for the sParseWord or the quantity it could be used in
    comment AS STRING*48  'a comment that may or may not be suitable to include in output source code
    QFlag AS LONG         ' an as of yet undetermined usage
END TYPE

The only element that we can be sure of having a value is the very first, vbTerm, all the rest depend upon that term and must be appropriately filled. All these are examples only.

The function for the second UDT would have to be a little different, but the function would only end up calling another function I expect. Some would return a word to take the place of the non-existent pbTerm.

Any sParseWord not found in the first elements of the UDT would be one of the following:
a variable, an array, a User Defined Function/Sub, something else , all of which would require handling by better minds than me, I mean by the converter.
Note the use of Static. comments?
Should the TYPE definition be included in the *.inc file?
I feel the functions should be in a separate *.inc file or DLL perhaps.
I have to put the word comparison in something usable.

Am I getting close with this?

Rod

[Chris Holbrook]

An instance table can be built from the master within the converter so that the master only gets scanned once.

how do you decide what to leave out?

I think we need to know if it's an object.attribute reference or a udt.member reference. Can these two types be identified within the code line?

only by reference to the symbol table, same way as VB distinguishes them?

Fred points out the 50+ attributes built in. The number of attributes probably varies quite a bit between object, event, and method types, especially the user-defined ones...don't all 3 get coded as classes?

Yes but we don't see the source code for the built-in classes

[Chris Holbrook]

The parser is going to have to decide which of the hundreds of possibles is applicable at each instance, possibly in some recursive fashion, and pass control over to the appropriate code, also possibly in recursive fashion.

Yes! But do we have to pre-scan to build the symbol table or can it be done "on the fly". I would guess that it could.

The parser may also need a 'look ahead' feature as well. EG: When it encounters "IF" it searches the following code to discern whether a single line "IF" statement or an "IF" block.

Can't see that, why should we care?

[Rodney Hicks]

Quote:
Originally Posted by Rodney Hicks View Post
The parser may also need a 'look ahead' feature as well. EG: When it encounters "IF" it searches the following code to discern whether a single line "IF" statement or an "IF" block.
Can't see that, why should we care?
Reply With Quote

Perhaps I should have not put that thought down in black and white just yet.
However, there may be certain conditions that VB requires that are unneeded in PB, but that will be obvious to us in time for a later version.

Rod

[Chris Holbrook]

... there may be certain conditions that VB requires that are unneeded in PB

Rod, if the VB has IFs shouldn't the PB have corresponding IFs, even if it could have coded in PB in a nicer way? Otherwise we are optimising not just translating.

[StanHelton]

how do you decide what to leave out?

A pre-scan of the VB source to pull relevant items from the master based on what turns up? May be the easy way.

only by reference to the symbol table, same way as VB distinguishes them?

yes. I think you're right about that.

Yes but we don't see the source code for the built-in classes

hmmm. True. I'll have to think about that.

[StanHelton]

Rod, if the VB has IFs shouldn't the PB have corresponding IFs, even if it could have coded in PB in a nicer way? Otherwise we are optimising not just translating.

My 2 cents: except for the short-circuit processing, IF works the same way in both compilers.

[Fred Harris]

I havn't gotten to conditional logic yet, but I will soon. At a first pass through this, I'd say PB conditional logic and loop constructs are the same as VB. The only issues would be something lile this...

Select Case txtData.Text
  Case "Fred"

  Case "Stan"

  Case "Chris"

  Case "Elias"

End Select

I believe we've already found ways to handle this, so that doesn't bother me.

In terms of VB's built in "Classes", such as the way they've 'wrapped' text boxes, listboxes, etc., in OOP constructs, we already have the documentation on that and will need to use it. This is also true of the 'Common Controls', i.e., listviiews, tab, progress, etc. In terms of ActiveX controls their properties, methods, etc are found within type libraries and these are accessable through various COM Apis. In the case of user created classes, we'll have the class modules themselves for that, unless its a binary. If a binary the creator should have produced a valid type library. If not it won't be able to be used.

I'd be careful to not confuse VB language reserved words with objects, properties and methods. Why? Don't know exactly. Just feel it in my bones. Somehow, they are different kinds of animals.

Back to object.attribute vs userType.member. The only way I can see seperating these is from the Symbol Table. For example, a user could name a text box txtData and it would have a txtData.Text property for the text string in it. A user could create a TYPE as follows...

Type MyData
Text As Asciiz * 64
End Type

Dim txtData As MyData

Then you would have...

txtData.Text for a text box and for a UDT. I'm hoping VB doesn't allow that. Would someone check? If it does, I'm not sure the solution. We absolutely must be able to determine what any given symbol is.

[StanHelton]

Just ran a quick test w/VB6 Pro sp6. Duplication like that generates a compile time error so it's not likely we'll find such an animal in working VB code.

[Rodney Hicks]

Chris,

Rod, if the VB has IFs shouldn't the PB have corresponding IFs, even if it could have coded in PB in a nicer way? Otherwise we are optimising not just translating.
Reply With Quote

Well, we'd likely be optimising instead of converting, and anticipation requires a sort of AI that we don't need to get into. The IF was just an example of the simplest kind.

The whole idea was a meandering thought, while waiting for direction on the structure of our PB word list. (and we know what thinking does.)

Rod

[Rodney Hicks]

I see we're posting while other's are posting and other's are reading and replying and posting. Good show.

Fred, you wrote:

I'd be careful to not confuse VB language reserved words with objects, properties and methods. Why? Don't know exactly. Just feel it in my bones. Somehow, they are different kinds of animals.

These all show up under the heading reference, but I too am not sure about how to handle them from a lookup point of view. That's why the two UDTs I posted earlier.

If someone else agrees with your thinking here I will go ahead with the first(smaller) UDT for the STATEMENTS, FUNCTIONS, KEYWORDS, and OPERATORS. I don't see any other way of constructing that array other than typing and I would like to start soon.

Rod

[StanHelton]

I see we're posting while other's are posting and other's are reading and replying and posting. Good show.

Fred, you wrote:


These all show up under the heading reference, but I too am not sure about how to handle them from a lookup point of view. That's why the two UDTs I posted earlier.

If someone else agrees with your thinking here I will go ahead with the first(smaller) UDT for the STATEMENTS, FUNCTIONS, KEYWORDS, and OPERATORS. I don't see any other way of constructing that array other than typing and I would like to start soon.

Rod

I think that's a good place to start, Rod.

Thinking about the objects, properties, events, and methods ....
and building on the udt idea ...
Here are some simple type structures I've been playing with -- anything look useful?

   'VB6 & PB project file names
   TYPE vb2pbFileNamesType
      vbProjectFile AS STRING * 128     'VB6 project file name
      vbCurrentFile AS STRING * 128     'Current VB6 file name
      pbMainFile AS STRING * 128        'Main PB project file name
      pbClassFile AS STRING * 128       'PB .bi for class simulation file name
      pbMacroFile AS STRING * 128       'PB .bi for PB MACROs file name
   END TYPE

   'vb6 class description type - process one vb class file at a time
   TYPE vb2pbClassDescType
      Namee AS STRING * 48                'name of class being processed
      PropertyCount AS LONG               'number of properties in class being processed
      FunctionCount AS LONG               '# of functions
      SubCount AS LONG                    '# of subs
      EventCount AS LONG                  '# of events
      SubClassCount AS LONG               '# of subclasses
      PropertyList AS STRING * 32750      'property names w/separator: $ItemSeparator
      FunctionList AS STRING * 32750      'function names w/separator: $ItemSeparator
      SubList AS STRING * 32750           'subs w/separators: $ItemSeparator
      SubClassList AS STRING * 32750      'subclasses w/separators: $ItemSeparator
   END TYPE

   'vb6 property description type
   TYPE vb2pbPropertyDescType
      Namee AS STRING * 48
      DataType AS LONG
      Declaration AS STRING * 256
   END TYPE

   'vb6 method description type
   TYPE vb2pbMethodDescType
      Namee AS STRING * 48
      DataType AS LONG
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
   END TYPE

   'vb6 event description type
   TYPE vb2pbEventDescType
      Namee AS STRING * 48
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
   END TYPE

   'Symbol table description
   TYPE SymbolTableItemType
      vbSymbol AS STRING * 32
      pbEquivalent AS STRING * 32
   END TYPE

[Rodney Hicks]

Stan, after a quick look at your UDTs, the only thing I might add at this time to each is a comment component, which could clarify anything about that item and might also be used as a comment in output code. A good starting point for each.

I have begun.

Rod.

[StanHelton]

Stan, after a quick look at your UDTs, the only thing I might add at this time to each is a comment component, which could clarify anything about that item and might also be used as a comment in output code. A good starting point for each.

I have begun.

Rod.

Done. I've updated these types in my vb2pbClassModule working file. Just in case anybody's wondering, the class module is dependent on the code line parser so that has to be usable before I can go much further with it.


New version:

 'VB6 & PB project file names
   TYPE vb2pbFileNamesType
      vbProjectFile AS STRING * 128     'VB6 project file name
      vbCurrentFile AS STRING * 128     'Current VB6 file name
      pbMainFile AS STRING * 128        'Main PB project file name
      pbClassFile AS STRING * 128       'PB .bi for class simulation file name
      pbMacroFile AS STRING * 128       'PB .bi for PB MACROs file name
      vb2pbComment AS STRING * 256   'explain & insert to output code
   END TYPE

   'vb6 class description type - process one vb class file at a time
   TYPE vb2pbClassDescType
      Namee AS STRING * 48                'name of class being processed
      PropertyCount AS LONG               'number of properties in class being processed
      FunctionCount AS LONG               '# of functions
      SubCount AS LONG                    '# of subs
      EventCount AS LONG                  '# of events
      SubClassCount AS LONG               '# of subclasses
      PropertyList AS STRING * 32750      'property names w/separator: $ItemSeparator
      FunctionList AS STRING * 32750      'function names w/separator: $ItemSeparator
      SubList AS STRING * 32750           'subs w/separators: $ItemSeparator
      SubClassList AS STRING * 32750      'subclasses w/separators: $ItemSeparator
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'vb6 property description type
   TYPE vb2pbPropertyDescType
      Namee AS STRING * 48
      DataType AS LONG
      Declaration AS STRING * 256
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'vb6 method description type
   TYPE vb2pbMethodDescType
      Namee AS STRING * 48
      DataType AS LONG
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'vb6 event description type
   TYPE vb2pbEventDescType
      Namee AS STRING * 48
      Arguments AS STRING * 256     'use $TermSeparator between each arg definition
      vb2pbComment AS STRING * 256   'explain & insert to output code
    END TYPE

   'Symbol table description
   TYPE SymbolTableItemType
      vbSymbol AS STRING * 32
      pbEquivalent AS STRING * 32
       vb2pbComment AS STRING * 256   'explain & insert to output code
   END TYPE

[Rodney Hicks]

Stan

Silly question here.

Some *&()%%$ fool went and set TODAY as the day to set the conventions in STONE. Are we okay for now?

Rod

[StanHelton]

Stan

Silly question here.

Some *&()%%$ fool went and set TODAY as the day to set the conventions in STONE. Are we okay for now?

Rod

This &%^?!!% clown is okay with it.