Module Messaging Spec

[StanHelton]

Everybody,


Okay, here it is. Everybody will immediately see that I have returned to procedural methods to set this up. My excuse for not using the new objects is that I have been working closely with Mr. Murphy and you know how that goes.

I've included everything needed to add messages and the prototypes for the two functions required to send and receive messages. These functions are in Tokenizer.bas under "Helper Functions". Using the gMessageQueue() array seemed the simplest way to keep track.

New messages are appended to the end of the array. When a module checks for its own messages the first message in the queue addressed to the calling module is returned and deleted from the array. So it is important that the module retrieving messages act on them. As I am thinking about it, the action could be as simple as adding an acknowledgment to the queue or as complex as converting an entire VB project. Tried to make it flexible.

gVbCodeBlock is a global that should only be set by the Editor since that is the main user interface. Once gPbCodeBlock is filled, the Tokenizer will send a message back to the Editor that it's done.

The list of equates at the end is provided for information. If it gives you any ideas for messages, that's good.

'The gMessageQueue()

TYPE MessageType
    SentTo AS LONG              '%Editor or %Converter or %MikesGUIThingy
    SentFrom AS LONG            '%Editor or %Converter or %MikesGUIThingy
    MsgID AS LONG               'a value from the message INI file
                                '    ie., from one of INFO, WARNING, ERROR, FATALERROR groups
                                '    (see below under Message Equates)    
END TYPE

'MessageQueue FUNCTIONS

'%True = message successfully added to MessageQueue
DECLARE FUNCTION PostVB2PBMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG) AS LONG

'call with SentTo set to self (%Editor, %Converter, %MikesGUIThingy)
DECLARE SUB GetNextVB2PBMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG)



'Relevant GLOBALS in Tokenizer:

'Editor/Converter Message Queue
GLOBAL gMessages() AS MessageType               'message queue

GLOBAL gVbCodeBlock AS STRING                   'VB6 code to be converted
GLOBAL gPbCodeBlock AS STRING                   'converted PBWin code

GLOBAL gTokenizerStatus  AS LONG                'current program status, can be checked from any module

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



'EQUATES

'module IDs for intenal messaging -- use these in SentTo and SentFrom params
%Editor             = 628
%Converter          = 629
%MikesGUIThingy     = 630

'Message Equates
'    This is set up as a flat INI file (per John). Anybody can add to this list.
'    NOTE: %RequestStatus is removed because gTokenizerStatus is updated internally
'              by the Tokenizer and available to any module.
'          %BlockConverted is deprecated because the Tokenizer will convert whatever
'              the Editor puts into gVbCodeBlock. Editor decides how much code to convert.
'              (Note to John: Tokenizer expects $CRLF as a line delimiter and will return
'              gPbCodeBlock with $CRLF line delimiters.)

'   Editor/Converter/GUI Messages:
'       %Info: 1101 - 1200
            'implied message that ConverterCOM class is ready to be processed
            %NewCodePosted              = 1101  'editor to converter:
                                                '    ConverterCOM class has been updated with new VB code
            %DoNotProcessEntireProject  = 1103  'editor to converter:
                                                '    do not parse entire VB project, only the code I send you

            'implied message that ConverterCOM class contains PB code for editor to access
            %Converted                  = 1110  'converter to editor:
                                                '    gPbCodeBlock has been updated with new PB code
            %ParsingProjectFiles        = 1112  'converter to editor: VB Project files are being parsed preparatory to processing

'       %Warning: 1201 - 1400
            %OptionExplicit_NotFound    = 1201  'VB module without OPTION EXPLICIT (obnoxious comment required)

'       %Error: 1401 - 1600
            %VB_SourceCorrupted         = 1401  'converter cannot read the VB source code
            %VB_StructureWithoutEND     = 1402  'converter found a FUNCTION, SUB, CLASS, METHOD, PROPERTY, EVENT without END

'       %FatalError: 1601 - 1800
            %UndefinedFatalError        = 1601  'duh... I think its broke somewhere.

'   *** Numbers used internally = 501-630 as of 9/5/2008 ***
'   *** Numbers reserverd = 1100 - 1900 for messages - see list above for values ***
'   *** values 601-615 are NOT used by vb2pb v1 - internal PB8 compiler errors) ***
 


'OTHER EQUATES

'These equates are defined in vb2pbEquates.inc and can be used to describe terms
'in communication between the editor and the converter.

'PBWin variable types & term descriptors
%pbByte
%pbInteger
%pbLong
%pbQuad
%pbWord
%pbDword
%pbSingle
%pbDouble
%pbExtended
%pbCurrency
%pbExtendedCurrency
%pbString
%pbFixedLengthString
%pbAscizString
%pbFieldString
%pbGUID
%pbVariant

%pbUserDefinedType
%pbArray
%pbObject

%pbNumericLiteral
%pbStringLiteral
%pbNumericEquate
%pbStringEquate

%pbCompilerDirective
%pbOperator
%pbKeyword

%pbFunctionPrototype
%pbSubPrototype
%pbMethodPrototype
%pbComment


'VB6 variable types & term descriptors
%vbBoolean
%vbByte
%vbConst
%vbCurrency
%vbDouble
%vbInteger
%vbLong
%vbSingle
%vbString
%vbFixedLengthString
%vbVariant

%vbUserDefinedType
%vbArray

%vbObject
%vbCollection
%vbProperty
%vbFunction
%vbMethod
%vbEvent

%vbStatement
%vbKeyword
%vbConstant
%vbOperator
%vbControl
%vbActiveXControl

%vbCompilerDirective
%vbComment

'VB Class, Properties, Methods, & Events
%vbClassPrototype
%vbMethodPrototype
%vbFunctionPrototype
%vbSubPrototype

'variable scope equates
%vbGlobal
%vbModule
%vbStatic
%vbLocal
%vbPrivate
%vbPublic

%pbGlobal
%pbStatic
%pbLocal
%pbInstance

'VB Class equates - identify specific parts of a VB class
%ClassDefinition
%EndClassDefinition
%PropertyDefinition
%EndPropertyDefinition
%MethodDefinition
%EndMethodDefinition
%EventDefinition
%EndEventDefinition
%SubClassDefinition
%EndSubClassDefinition
%FunctionDefinition
%EndFunctionDefinition
%SubDefinition
%EndSubDefinition
%TypeDefinition
%EndTypeDefinition
%EnumDefinition
%EndEnumDefinition
                            
$Separator = "|"            'long string data separator = pipe character
                            '   (note: SEPARATOR is a secondary reserved word,
                            '   name may have to change in version 2 - sjh)

Mike,
As I review this for posting, I noticed that there's no special allowance for the code your GUI converter will produce. Do you think we need a separate STRING codeblock for the GUI code output or can both the GUI converter and the Tokenizer use the same string space for output? Sorry, I didn't think about that when putting this together.

Stan

[Rodney Hicks]

Should there not now be an equate %pbInstance under variable scope equates?

[StanHelton]

Should there not now be an equate %pbInstance under variable scope equates?

Added to the bottom of that list:

%pbInstance = 631

[John R. Heathcote]

Stan,

This looks like a good start.

...that I have been working closely with Mr. Murphy and you know how that goes.

Mr. Murphy certainly gets around doesn't he?

Procedural code is OK by me.

One question, what equate does the Tokenizer send to the editor to keep inputting VB source code lines? I'm still assuming that some of the more advanced converter functions in later versions of VB2PB will require that a code block needs to be submitted to the Tokenizer.

I think Mike's GUI thingy is worth looking into, but should it be included in Version 1?

' (Note to John: Tokenizer expects $CRLF as a line delimiter and will return
' gPbCodeBlock with $CRLF line delimiters.)

Can do. The Scintilla edit control uses a $CRNUL to denote the end of text line. I can subsitute $CRLF for $CRNUL before I send any source code line to the Tokenizer.

Maybe we should change:

DECLARE FUNCTION PostMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG) AS LONG

To:

DECLARE FUNCTION PostVB2PBMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG) AS LONG

Just so it won't be confused with a similar Windows API call.

On another note, I apologize for not getting the editor to you last week. My next door neighbor (the nice one) had a mild heart attack last Wednesday and she lives alone, so many of the neighbors are taking turns looking in on her and running errands and so forth. So I haven't had a lot of time behind the keyboard.

[Michael Mayerhoffer]

Mike,
As I review this for posting, I noticed that there's no special allowance for the code your GUI converter will produce. Do you think we need a separate STRING codeblock for the GUI code output or can both the GUI converter and the Tokenizer use the same string space for output? Sorry, I didn't think about that when putting this together.

Stan

Since you have a plan to use PBForms , I would stick with that, I can mimic the PBForms output.

That ensures that if I fall behind you have a working converter and not waiting on me.

[StanHelton]

...
Procedural code is OK by me.

One question, what equate does the Tokenizer send to the editor to keep inputting VB source code lines? I'm still assuming that some of the more advanced converter functions in later versions of VB2PB will require that a code block needs to be submitted to the Tokenizer.

The gVbCodeBlock is a dynamic string so 1 line or 100, no difference to the Tokenizer. The message back to the Editor will be %IsFinished -- current gVbCodeBlock now has an equivalent gPbCodeBlock.

I think Mike's GUI thingy is worth looking into, but should it be included in Version 1?

Agreed. Just thinking ahead to v2 here.

...
Maybe we should change:

DECLARE FUNCTION PostMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG) AS LONG

To:

DECLARE FUNCTION PostVB2PBMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG) AS LONG

Just so it won't be confused with a similar Windows API call.

Excellent suggestion. Same change to the Get SUB:

DECLARE SUB GetNextMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG)

is now:

DECLARE SUB GetNextVB2PBMessage(SentTo AS LONG, SentFrom AS LONG, MsgID AS LONG)

On another note, I apologize for not getting the editor to you last week. My next door neighbor (the nice one) had a mild heart attack last Wednesday and she lives alone, so many of the neighbors are taking turns looking in on her and running errands and so forth. So I haven't had a lot of time behind the keyboard.

No worries. Life comes first. Some of my delays are looking in on a very good friend who is ill.

Since you have a plan to use PBForms , I would stick with that, I can mimic the PBForms output.
...

Okay Mike. The development plan allows for your GUI converter whenever it's ready.

[John R. Heathcote]

Stan,

The gVbCodeBlock is a dynamic string so 1 line or 100, no difference to the Tokenizer. The message back to the Editor will be %IsFinished -- current gVbCodeBlock now has an equivalent gPbCodeBlock.

I guess I didn't format my question properly, or clearly.

Since the Tokenizer is the process performing the actual conversion I think it should be in charge to determine how many VB source code lines it needs for any conversion task. The editor can pass source code lines, but it is just text, the editor has no context at this point, it hasn't been programmed (yet?) to decipher a FOR/NEXT code block from an IF/END IF statement. If we decide to put such intelligence in the editor then what would be the purpose of the Tokenizer? Assuming we are going to leave things as they are, the intelligence lies with the Tokenizer. So if the Tokenizer needs additional source code lines the editor needs to know how many to send. The only way to do that is for the Tokenizer to tell the editor to send additional source code lines.

[StanHelton]

John,

...
So if the Tokenizer needs additional source code lines the editor needs to know how many to send. The only way to do that is for the Tokenizer to tell the editor to send additional source code lines.

Doh. Sometime soon I'm going to learn English. Okay I understand now. How about the editor sends 1 line at a time and we use the following, all as INFO messages:

%SendOneLine
%Wait_ConvertingLine

%StructureBeginningDetected
%StructureEndingDetected

%Wait_ConvertingStructure

%ConversionComplete

Editor always sends one line at a time. Tokenizer notifies Editor that another line is needed. Conversion is line by line unless Tokenizer decides it needs more lines to make the conversion.

First pass through code is where the Tokenize identifies variables, classes, functions, et al, so before the user is allowed to select which part of a file to convert (Line, procedure, class, whatever), it needs to scan the entire active file. No conversion on this pass, just gathering info.

Once file info is gathered from the Editor one line at a time, the Editor/user can decide which lines to convert. Tokenizer sends %IsReady while waiting, %SendOneLine when needed, and %ConversionComplete when finished.

When a structure is identified by Start/End lines, Tokenizer will ask for enough lines one at a time to complete the process for the entire structure. During conversion the %Wait_ConvertingLine or %Wait_ConvertingStructure message will be queued.

Summary:
Tokenizer decides when and how many lines it needs.
Editor sends one line at a time.
Tokenizer sends Wait_message while working
Tokenizer sends %ConversionComplete when finished.

When Tokenizer %IsReady, it is waiting for the Editor to send a first line of code. Based on the first line and the info gathered on the first pass, Tokenizer will determine how many lines are to be sent one at a time.

Editor always passes one, and only one, line of code for each Tokenizer request.

[John R. Heathcote]

Stan,

You proposed the following equates:

%SendOneLine
%Wait_ConvertingLine

%StructureBeginningDetected
%StructureEndingDetected

%Wait_ConvertingStructure

%ConversionComplete

Is it necessary to have the %Wait_xxxxxx equates? These equates would be necessary if we are running the Tokenizer asynchronously, however, I was assuming that the Tokenizer would be run synchronously with the editor, but it is quite possible I am missing something here.

Editor always sends one line at a time. Tokenizer notifies Editor that another line is needed. Conversion is line by line unless Tokenizer decides it needs more lines to make the conversion.

OK, sounds good.

First pass through code is where the Tokenize identifies variables, classes, functions, et al, so before the user is allowed to select which part of a file to convert (Line, procedure, class, whatever), it needs to scan the entire active file. No conversion on this pass, just gathering info.

A scan pass is doable. I will implement some skeleton code to do this in the editor.

Once file info is gathered from the Editor one line at a time, the Editor/user can decide which lines to convert. Tokenizer sends %IsReady while waiting, %SendOneLine when needed, and %ConversionComplete when finished.

Does the above get into the synchronous/asynchronous issue? If we run the Tokenizer synchronously why can't the Tokenizer convert lines on the fly? I guess I just don't understand the processing scenario here, sorry for being so (obnoxiously?) dense.

When a structure is identified by Start/End lines, Tokenizer will ask for enough lines one at a time to complete the process for the entire structure. During conversion the %Wait_ConvertingLine or %Wait_ConvertingStructure message will be queued.

Sounds good to me.

[StanHelton]

Stan,

You proposed the following equates:

%SendOneLine
%Wait_ConvertingLine

%StructureBeginningDetected
%StructureEndingDetected

%Wait_ConvertingStructure

%ConversionComplete

Is it necessary to have the %Wait_xxxxxx equates? These equates would be necessary if we are running the Tokenizer asynchronously, however, I was assuming that the Tokenizer would be run synchronously with the editor, but it is quite possible I am missing something here.

No, you are correct. We run synchronously. I was trying to figure out a way to send a progress percent number back to the editor and ended up (late one night) punting. These equates are not necessary.

...
Does the above get into the synchronous/asynchronous issue? If we run the Tokenizer synchronously why can't the Tokenizer convert lines on the fly? ...

You're asking the right questions. On the fly is fine. Focusing on the line-by-line process with theTokenizer calling for more code when needed makes this happen. My conceptual difficulty is that when I set this up originally I was thinking of reading a file. The idea that the Editor handles the file I/O is forcing me to change things for the new concept.

Keep asking questions, especially when I say something that doesn't add up. It helps me to catch all the details before they become problems.


Okay. I think we're good then.

[John R. Heathcote]

Stan,

I was trying to figure out a way to send a progress percent number back to the editor...

If we want to show the progress of the conversion we can do this from the editor by comparing the lines read against the total file text size. Not exact, but would be a close approximation.

My conceptual difficulty is that when I set this up originally I was thinking of reading a file. The idea that the Editor handles the file I/O is forcing me to change things for the new concept.

Not trying to muddy the waters here, but we can still do this, if there is an advantage and need to do it. Perhaps as a user defined option? I was approaching the problem simply from the editor point of view, however, I was guilty of not thinking outside the box.

The editor can pass the entire contents of the edit control as a string to the Tokenizer if need be, although it has not been programmed to do this functionality yet. To pass the entire file would not be any more difficult than what is necessary to save the editor contents to a file and I have that functionality already coded. The only thing that would be left to do is to cannibalize the save code and replace the $CR$NUL with $CRLF before we send the string to the Tokenizer. Very simple.

Always trying to keep on the same page as the Big Kahuna.

[StanHelton]

John,

...
If we want to show the progress of the conversion we can do this from the editor by comparing the lines read against the total file text size. Not exact, but would be a close approximation.

Good enough. I'll be satisfied with the FeedMe messages then.

Not trying to muddy the waters here, but we can still do this, if there is an advantage and need to do it. Perhaps as a user defined option? I was approaching the problem simply from the editor point of view, however, I was guilty of not thinking outside the box.

The only real advantage would be that the Tokenizer could do the initial info scan asynchronously. Not sure that is useful at this point, but something we can add later. Thinking about it as I type ... probably not worth the effort until we're sure we can handle the big projects.

The editor can pass the entire contents of the edit control as a string to the Tokenizer if need be, although it has not been programmed to do this functionality yet. To pass the entire file would not be any more difficult than what is necessary to save the editor contents to a file and I have that functionality already coded. The only thing that would be left to do is to cannibalize the save code and replace the $CR$NUL with $CRLF before we send the string to the Tokenizer. Very simple.

Any speed advantage? It would have to be significant to be worthwhile. I'm thinking that by passing the code line-by-line like we talked about, the Editor could allow the user to watch the progress, fast as it may be. Who knows; somebody may want the option of pausing for a cup of coffee or something.

Always trying to keep on the same page as the Big Kahuna.

hmmmm....

"Which way did they go? Please tell me for I am their leader and I must follow them."

Stan

[John R. Heathcote]

Stan,

Good enough. I'll be satisfied with the FeedMe messages then.

I think we need one more Tokenizer return message, a "%NoChange" message. This message would be passed back to inform the editor that the input source line was not changed/no conversion performed, or was necessary. This will help eliminate the multitude of updated source code lines the editor would have to track and redisplay.

Thinking about it as I type ... probably not worth the effort until we're sure we can handle the big projects.

I've been giving the large project issue some thought myself, and the more I think about it the deeper I get into a never ending file maintenance logic issue. I think we will eventually be able to handle large projects, I just don't quite know how to do it yet, may have to spend more time in the shower to solve this problem. Currently, I'm leaning towards something like Lynx or the Project Stuff in the SED editor as a desing/functionality option, but not sure.

Any speed advantage? It would have to be significant to be worthwhile.

It wouldn't take too long to strip out the special Scintilla characters and insert the ones the Tokenizer needs. I was thinking more about the added functionality option than speed.

I'm thinking that by passing the code line-by-line like we talked about, the Editor could allow the user to watch the progress, fast as it may be. Who knows; somebody may want the option of pausing for a cup of coffee or something.

Excellent suggestion. The "Pause" factor could be a user defined option.

[StanHelton]

John,

What do you think about the Tokenizer holding all the converted code for a single session in the gConcordance() array? This was my original design, but now I'm thinking it would be better for the Editor to maintain in the file I/O.

Let me know.

Stan

[John R. Heathcote]

Stan,

What do you think about the Tokenizer holding all the converted code for a single session in the gConcordance() array?

I think this could be a user defined option. I can see where a smaller VB project might benefit from this approach. Displaying the converted information would have to be handled differently than the line by line process I'm using now. I would envision that the contents of the entire gConcordance() array could be converted to a string and then loaded into a new MDI editor form. Technically this would actually be easier than displaying converted code line by line. Think of it as loading a file after you've selected it from the OPENFILE dialog box.

If we do decide to keep this functionality the question we have to ask is, what is the direct benefit to the user?

On a larger project the user might want to have more control over file I/O of the individual conversion files, I know I would want to have this capability, so I would opt for the line by line conversion/display.

On the down side, the user would have to either let the Tokenizer hold the entire converted code and then display, or allow the editor to feed the Tokenizer source code lines. I really don't see any practical way to mix the two conversion input scenarios. Not that it couldn't be done, but I think we have to keep things practical.

This was my original design, but now I'm thinking it would be better for the Editor to maintain in the file I/O.

I tend to agree with you here. Let the editor handle the file display and maintenance stuff and let the Tokenizer handle the all important conversion stuff. I wouldn't get rid of this code, I would keep it in the Tokenizer source, but maybe comment it out so it doesn't create unused procedures in the EXE.

I know we have talked about using PBForms as a method of converting VB forms, however, the observations Wayne made concerning his conversion tests disturbs me. The fact that PBForms apparently "left out" so many individual parts of the original VB form leads me to think that maybe PBForms would not be a good solution after all. I say this from the perspective of a new user attempting to convert a VB program, running it through our converter and ending up with trashed/incomplete dialog boxes. The user is expecting the conversion to work. If it doesn't then what does the new user do to solve the problem?

Some questions I thought of as I was typing...

How do feel about including a "tool" that looks for and comments out unused procedures?

Should we include tools like Inclean?

A Message Box designer?

Should we provide a link to POFFS?

A link to PBWinSpy?

PBForms?

Etc., etc., etc.

Maybe not in Version 1, but certainly in subsequent versions.

[StanHelton]

...
I think this could be a user defined option. I can see where a smaller VB project might benefit from this approach. Displaying the converted information would have to be handled differently ...

,,, don't see any practical way to mix the two conversion input scenarios. Not that it couldn't be done, but I think we have to keep things practical.

Good points. We'll stick to line-by-line for now. Maybe whole projects next iteration.

I tend to agree with you here. Let the editor handle the file display and maintenance stuff and let the Tokenizer handle the all important conversion stuff. I wouldn't get rid of this code ...

Done. Bracketed with #IF/#ENDIF.

I know we have talked about using PBForms as a method of converting VB forms, however, the observations Wayne made concerning his conversion tests disturbs me. The fact that PBForms apparently "left out" so many individual parts of the original VB form leads me to think that maybe PBForms would not be a good solution after all. I say this from the perspective of a new user attempting to convert a VB program, running it through our converter and ending up with trashed/incomplete dialog boxes. The user is expecting the conversion to work. If it doesn't then what does the new user do to solve the problem?

I noticed Wayne's comments also. Actually, the skeleton is in there 95-99% of the time, but it is taxing my brain to track all the code moving around to get a smooth conversion. It's beginning to look like it could turn out easier to build our own DDT converter/designer.

PBForms may be problematic, after all. I'm having some difficulty using it in the code. I've been looking at WinSpy. It produces some very interesting code snippets, but I'm not sure it will do the job either.

I find myself hoping Mike will come up with an alternative soon.

Some questions I thought of as I was typing...

How do feel about including a "tool" that looks for and comments out unused procedures?

Yes. Has anybody in the community posted such a thing? I know there were several for PB/DOS.

Should we include tools like Inclean?

I don't use inclean, but it looks nice, if we can integrate it.

A Message Box designer?

Visual designer? I guess it would have to be. I haven't thought about this possibility before. This brings me back to my struggle getting PBForms to jump through hoops.

Should we provide a link to POFFS?

Yes. The help is likely to be rudimentary in this edition. Links to POFFS and PB Forums should be provided.

A link to PBWinSpy?

I'm evaluating this as a possible aid to the forms translation issue.

Etc., etc., etc.

Maybe not in Version 1, but certainly in subsequent versions.

I think we should tie the help and references very tightly into the resources available here on the forums and any 3rd party sites that look good; Jose Roca's site comes to mind. Third party sites and tools should be part of the help/reference system.

Bubbling in the darker regions of my brain is the possibility of including add-ins. But I want to finish the basic conversion engine before going too far afield.

[StanHelton]

...
What do you think about the Tokenizer holding all the converted code for a single session in the gConcordance() array?
...

...
If we do decide to keep this functionality the question we have to ask is, what is the direct benefit to the user?
...

Second look at this issue. I agree with dropping the WholeFile option for now. Limited benefit and it would be a memory hog the way I set it up initially. I can look at this for the next iteration if feedback justifies it.

So, yes, line-by-line. There is enough tracking built into the Tokenizer to locate code snippets within the proper source code structures. The only part of the WholeFile idea we need to keep for now is the initial scan for the Tokenizer to locate and track everything.

[John R. Heathcote]

Stan,

So, yes, line-by-line. There is enough tracking built into the Tokenizer to locate code snippets within the proper source code structures. The only part of the WholeFile idea we need to keep for now is the initial scan for the Tokenizer to locate and track everything.

When the Tokenizer scans the file and locates its desired targets are those locations cast in concrete? Can they be moved? My reason for asking this is if we intend to comment out the VB portions of the code and insert the PB conversions in the same edit dialog then the total number of lines in the copy of the source file will change and thus destroy the original target locations found by the Tokenizer. Could we have a message to direct the Tokenizer to rescan from the next legitimate VB source line forward?

The other alternative is to read source lines from one edit dialog and write the conversions to another dialog.

I noticed Wayne's comments also. Actually, the skeleton is in there 95-99% of the time, but it is taxing my brain to track all the code moving around to get a smooth conversion. It's beginning to look like it could turn out easier to build our own DDT converter/designer.

I tend to agree with you. IMO the visual aspect of the forms is an important part of the conversion process and if it doesn't reliably work ALL the time the user is going to get frustrated and probably curse the converter, PowerBASIC, etc.

PBForms may be problematic, after all. I'm having some difficulty using it in the code. I've been looking at WinSpy. It produces some very interesting code snippets, but I'm not sure it will do the job either.

In order to do the job it looks like to me that it would require a combination of several separate tools to get the job done and I think this would be unacceptable to a new user. They would want all the conversion functionality they need under one hood.

I find myself hoping Mike will come up with an alternative soon.

Me too.

I actually stayed up until about 1:30 in the morning looking at some of the .FRM files from a couple of VB projects of my own. It didn't look like it was overly impossible to write some code to convert the VB forms to PB. One of the aspects of this conversion that interested me was the conversion of the VB events, Button_Click() and Textbox_Change() for example, to its equivalent PB code.

I could see where a new PB user may want to preserve the original VB event code simply to keep the flavor of the VB application in PB. Perhaps this feature could be a user defined option that could be turned off as the user becomes more familiar with PB CallBacks and Windows Messages (which still confuses me to no end).

Concerning the tool for commenting out unused procedures, I think it is important to have such a process because, as you know, VB includes all source code from a code module in the final application so there will undoubtedly be a lot of VB source code we may not have to convert.

It just so happens I do have such a beast, however, it is a memory hog, but I think it could be rewritten to use a random access file without degrading performance too much. It was based on the PBCodec app that Lance, Borje, and Scott Slater and a host of others contributed to. The difference in my implementation is that it actually outputs the revised source code. I set up another directory called \COMPRESS to hold this revised source so it looks like we will have another subdirectory to add to our processing options.

I don't use inclean, but it looks nice, if we can integrate it.

A good utility, you should try it. As an alternative Jose Roca has created wrapper procedures for the Common dialog and Common control include files which are available from his web site, you have to be a registered member to access them though. Well worth the effort IMO.

[Rodney Hicks]

Not being a VB user, and thus not having VB to test this with, but thinking maybe that possibly that it could be that sorta ....

When you create a form in VB with say a textbox and a button, adding whatever features you wish, VB must create all the files simultaneously. That is the frm file and whatever other file that handles all the features that aren't included in the frm file.

PBForms only access the frm files and creates a skeleton for the project, then each of the features that VB relegates to another file have to be added to the output file in the appropriate places. The frm file may give the location and size of the textbox, but some other file will add the styles, and yet another file will add the manipulations, and yet another file will add the headaches.

Is this not a correct analysis?
This is the first of a few questions of this nature.

[StanHelton]

...
When you create a form in VB with say a textbox and a button, adding whatever features you wish, VB must create all the files simultaneously. That is the frm file and whatever other file that handles all the features that aren't included in the frm file.
...
Is this not a correct analysis?

That's pretty much it. And then vb2pb has to find the correct Button1_Click() to plug into the correct SELECT CASE %WM_COMMAND spot as a function call.

This is the first of a few questions of this nature.

Keep 'em coming. This rapidly turning into a question driven project.