VB Form Conversion

[StanHelton]

Stan,

Just so you know the Mile High City is Denver, not that other city you mentioned.

I'm walking around Colorado with a TOURIST sign on my forehead. {sigh}

My basic questions concerning tracking is based on the fact the converter will be using multiple passes, possibly at different times and/or steps during the conversion process. This being the case we must keep track of the processes and status of the converter at any given point in time. The reason for this is to account for the possibility of the user stopping the converter to make some changes in the converted code in the editor, then starting the converter again....

Ok. I think I understand what you're getting at now. (Please pardon; sometimes my onboard CPU has a clock speed near 4 Mhz.)

It sounds like my TYPE structures would need to include a VB file and line reference for each item. Then the arrays would list every occurrence of every item. It's certainly doable. Am I getting any warmer?

Stan

[John R. Heathcote]

Stan,

I'm walking around Colorado with a TOURIST sign on my forehead. {sigh}

Don't worry, I'm not keeping count.

Ok. I think I understand what you're getting at now. (Please pardon; sometimes my onboard CPU has a clock speed near 4 Mhz.)

I understand. My daughter keeps telling me I'm over the hill. Funny, I don't ever remember getting to the top of the hill.

It sounds like my TYPE structures would need to include a VB file and line reference for each item. Then the arrays would list every occurrence of every item. It's certainly doable. Am I getting any warmer?

Your modified TYPE structure would probably do it, as long as the converter is running. What I was thinking about is when the user converts a VB project that spans multiple days and they turn off the computer. We should have a method in place to preserve the status of the converter between power up cycles, otherwise, how do we determine what has already been converted or not? The individual files converted to date may or may not always give us the answer or even a clue as to what conversions were previously done and pending conversions that still need to be performed.

As I mentioned before we also need to track the possibility of VB form/modules level changes where these references span multiple forms and module level procedures. In this case we have to track every instance of these changes, such as a procedure name or module level variable, throughout the project, so the references to these changed procedures/variables can be updated wherever they occur in the source code.

Maybe we should think about this functionality for Version 2, but I think we need to get our heads around the issue now.

[StanHelton]

...
I understand. My daughter keeps telling me I'm over the hill. Funny, I don't ever remember getting to the top of the hill.

There was a hilltop???? Darn! I missed it, too.

Your modified TYPE structure would probably do it, as long as the converter is running. What I was thinking about is when the user converts a VB project that spans multiple days and they turn off the computer. We should have a method in place to preserve the status of the converter between power up cycles, otherwise, how do we determine what has already been converted or not? The individual files converted to date may or may not always give us the answer or even a clue as to what conversions were previously done and pending conversions that still need to be performed.

My favorite PC game does something that might work here. Automatic backups that amount to a data segment dump. If we set such a beast for every 5 or 10 minutes, perhaps give the user an option for how often, we might be able to track progressive states in the conversion process without having to make it all nice and neat to look at.

As I mentioned before we also need to track the possibility of VB form/modules level changes where these references span multiple forms and module level procedures. In this case we have to track every instance of these changes, such as a procedure name or module level variable, throughout the project, so the references to these changed procedures/variables can be updated wherever they occur in the source code.

A data segment dump can snapshot what VB2BP is doing, but I think you're talking about dressing it up for the user see. Not sure how we would do that, or how much we'd have to show, but it should be possible.

Maybe we should think about this functionality for Version 2, but I think we need to get our heads around the issue now.

My gut tells me full implementation is a Version 2 thing. We might be able to come up with a starting point for Version 1. I'll play with it this week (something to do while I work through my insomnia ). Hopefully, I'll have something solid by the weekend.

You said you had an idea how to do this. How are you thinking of handling the issue?

Stan

[Rodney Hicks]

Has anyone implemented a method of tracking multiple form conversion for the purpose of variable and procedure renaming, equates, etc.? As I was fiddling with my code I came the the realization we need to keep track of converted VB forms to avoid unwanted side effects and to insure everything VB that is supposed to be altered is altered f

I came to a similar conclusion in my diagnostic app, and it really is a diagnostic app, since I don't know VB very well.
The only way I have figured so far is that every term has to be counted and that all VB term locations (form1.frm, formstart.frm)have to be stored with the count, possibly even including the line number for some terms. This seems to require that all files pertaining to the project have to be tokenized, parsed, collected, sorted? before the converting can even begin. I have not yet been able to figure out a structure dynamic enough to store the incredible complexity that I've a feeling can exist in a large project.
If I am right in my calcutypelations, this does not bode well for using the converter to convert selected lines or code snippets, unless the user has a very good understanding of PB and VB.(which would be an option for advanced users? adequate warnings, caveats, etc.)

With regard to renaming, I think to be useful to the user, merely appending the % to the VB term is probably the best way to convert equates. This would help them with understanding the resulting code since it would provide the least change. Functions, Procedures, Types, Variables etc will have to be checked against the PB keywords(reserved, etc) but other than that I think that most will be usable as is.(I'm counting on it.)(The little devil in me says we should ignore this to see what kind of bugs will spring to life!)

What I was thinking about is when the user converts a VB project that spans multiple days and they turn off the computer.

I really wish you hadn't said that!:afraid:
That brings up a whole host of issues that we had, until now completely ignored. Power disruptions, and things that are beyond the norm. We can't anticipate everything, and as you point out, maintaining a resumption point is likely the only way to preserve the stage, work, etc. This though, may have to wait a version or two because, well, I can see issues with a resumption point as well. For example, if it was to create a restore point every x minutes and the process was in the middle of a nested loop, 6 levels deep, the code would have to handle an immense number of unknowns to be reliable. IMO. There are some natural restore points, which is probably the way to go, Like when the converter is finished some task on some file and prior to starting the next file it sets the restore point. But even that could result in a loss of considerable info.
The other reason for interruption, I'm not so sure about. I recognize that there is code that will have to be adjusted, added to, subtracted from after the converter is done its business, but to try and do these things while in the midst of conversion seems ..., well, wrong. Let the converter finish its job, then the user can mess with it to their hearts content. My opinion only. A strictly advanced user option.

[John R. Heathcote]

Rod and Stan,

Gee guys, I really didn't intend the headaches, just got to thinking "what if" in the shower. Maybe I should stop taking showers!? Naaah!!!

Maybe a little clarification is needed.

In VB it is possible to have an event that has the same procedure name as could be found in another VB form. For example, two forms, both with an OK button that are named "cmdOK". The most common event for these buttons is the Click() event, so both forms have a "cmdOK_Click()" event. Now if we convert both of the VB forms using the event procedures "as is" we will generate a compiler error in PB by having two procedures with the same name. Now I think we decided to append a unique prefix to the procedure name to prevent this phenomenon, however, we have to insure that the "cmdOK_Click()" event in VB form 1 applies to that form, including all references in the source code for that form and the "cmdOK_Click()" VB form 2 event applies to that form to the same degree. If we convert in multiple passes we need to store the procedure name change somehow so the name change can be applied throughout ALL source code modules in subsequent passes.

This is the extent of the status "save" I was thinking about. I don't think we need to save every status change as we convert, but any change we make to the source code itself should be saved for future use. I think this is doable and shouldn't present too much of a problem.

Now I didn't make a habit of this coding style but if I wanted to exit a VB app and there was a specific shut down procedure necessary to exit cleanly, and on the main VB form there was a button called, cleverly enough, "Exit", and the specific procedure for exiting the app was embedded within the "Exit" button event, I would sometimes just called the "Exit" event from anywhere in my code, for example, "CALL Form1.cmdExit_Click()". Normally, I would make the exit code a module level procedure and call it from the _Click() event, but you get the idea.

The same goes for the control and menu equates we generate from the VB source code.

The question is how will we deal with this possibility if we intend to utilize the source code "as is"? If we start changing variable and procedure names so as to limit their scope to emulate the same intent found in VB we have to track these types of changes and modifications, I don't see any other way around this problem.

If I am right in my calcutypelations, this does not bode well for using the converter to convert selected lines or code snippets, unless the user has a very good understanding of PB and VB.(which would be an option for advanced users? adequate warnings, caveats, etc.)

For best results the user will have to convert the VB forms first, save those necessary changes, then proceed on to the module level source code. With the VB form changes saved the module level conversion could be done one line at a time, or by procedure, or by file.

I really wish you hadn't said that!
That brings up a whole host of issues that we had, until now completely ignored. Power disruptions, and things that are beyond the norm. We can't anticipate everything, ...

You are right about that.

There are some natural restore points, which is probably the way to go, ...

Yes, my thinking exactly.

The other reason for interruption, I'm not so sure about. I recognize that there is code that will have to be adjusted, added to, subtracted from after the converter is done its business, but to try and do these things while in the midst of conversion seems ..., well, wrong. Let the converter finish its job, then the user can mess with it to their hearts content.

IMHO this depends on the size and functionality of the VB app. A large, involved VB project may require user intervention during the conversion process, whereas a smaller project could be run from start to finish. The point is user intervention during conversion is a possibility. Do we want to contend with it or not?

My opinion only.

And much appreciated.

[John R. Heathcote]

Stan,

My gut tells me full implementation is a Version 2 thing. We might be able to come up with a starting point for Version 1. I'll play with it this week (something to do while I work through my insomnia ). Hopefully, I'll have something solid by the weekend.

Don't lose sleep over this issue please. As I mentioned before I think we have to track direct changes to source code.

You said you had an idea how to do this. How are you thinking of handling the issue?

Well, my idea was to create tables on the fly as source code is processed through the converter. The procedure name table layout might look something like this:

VB Procedure Name, VB Object Call, PB Procedure Name

We could also use the .INI file format:

[Form Name]
VB Procedure Name = VB Object Call, PB Procedure Name

With the section header pointing to the particular form being converted, so an entry might look like this:

[frmTIN]
mnuFileSortPntNo = frmTIN.mnuFileSortPntNo, FRMTIN_mnuFileSortPntNo

We scan the VB Form source code file and extract procedure names and format their equivalent for PB in our table. Then we read the entire contents for an individual section and then parse each VB source code line and comparing that line against our table and substitute procedure names as necessary within the proper context as dictated by VB. This method allows us to use the VB event source code, limit the scope as per VB, and creates a unique procedure name for the PB compiler.

The same idea could be done for dialog, control, or menu equates.

Whaddythink?

Do I need another shower?

[Rodney Hicks]

Maybe I should stop taking showers!? Naaah!!!

Maybe get someone to join you, keep your mind on other things!

In VB it is possible to have an event that has the same procedure name as could be found in another VB form.

I guess in addition to the PB key/reserved words then we'll have to compare against names already accessed/processed VB Functions, Procedures, Types, Variables, Arrays etc. If it is only possible to use the same name in separate files then we could automatically append the sequential number of the file to any of these terms within the file. I.E. "cmdOK2" from the second file handled, (cmdOK9) from the ninth where this animal first shows up in the file and all subsequent references within that file.

A large, involved VB project may require user intervention during the conversion process,

A strictly advanced user option.

Such a project has likely been developed by an advanced user. We could recommend that it not be used on file of less than x number of lines until
users are familiar with the converter. An advanced(in both PB and VB) user will know when to use it whereas someone with a one sided knowledge may be interfering with the process.
It seems to me that this has all the trimmings of the shutdown problem, stopping the converter at obvious break points rather than midstride.
On the other hand, solving this issue for one feature will likely solve it for the other.

[John R. Heathcote]

Rod,

I guess in addition to the PB key/reserved words then we'll have to compare against names already accessed/processed VB Functions, Procedures, Types, Variables, Arrays etc.

This would work if the necessary variable/procedure names were maintained for the entire project. Somehow I got the concept into my mind that this type of data was only available for each form/module as they are individually converted. If this is not the case then maybe the point is moot.

If it is only possible to use the same name in separate files then we could automatically append the sequential number of the file to any of these terms within the file. I.E. "cmdOK2" from the second file handled, (cmdOK9) from the ninth where this animal first shows up in the file and all subsequent references within that file.

If I understand this correctly, you are proposing incrementing a variable/procedure as they occur, correct? If so, I don't think this will work as the context of variable/procedure usage must be determined so we can point to the correct variable/procedure at the proper location in the source code.

Also, while incrementing variable/procedure names may work, it introduces an ambiguity not present in the original VB source code. A new PB user may find this a bit confusing. Personally, I would prefer to search for a variable/procedure name called "FRMTIN_cmdOK" instead of "cmdOK2" as the former declaration is more descriptive of where the VB variable/procedure name came from and the form it applies to, and it also implies scope. In short I think the former declaration will be more readily identified and familiar to the VB/PB user.

Just my opinion.

If other members of the team have tackled this problem I would love to know what other solutions exist to solve this issue.

[Rodney Hicks]

Personally, I would prefer to search for a variable/procedure name called "FRMTIN_cmdOK" instead of "cmdOK2"

Well, I guess we're not very far apart because I was at first tempted to relate the item to the file it was found in, but decided to go with the PB implementation like they do with PBForms when you create something with 2 or more windows/dialogs, they merely differentiate with a number appended. One way is as good as another, and whatever gets the user up and running is fine by me. For what ever difference in execution time it sure won't make a difference. One is no more difficult for us code than the other.

If I understand this correctly, you are proposing incrementing a variable/procedure as they occur, correct?

Pretty much correct. As they are defined, dimmed, or established. If more same names are run across in other files we've prevented a mixup. I concur that there may be an issue with slightly or vastly different calls, scope, whathaveyou, but this just gives us a chance to warn the user with an obnoxious comment, or even with an undeclared item so the compiler catches an error for them to correct the code on. I prefer the former, there might be enough of the latter without us intentionally setting them in place.
How does VB know how to segregate them? Shouldn't our converter be able to find the difference and convert appropriately? I don't know VB and as a result I don't know these answers, but it seems if VB can do it, we can convert as close as possible to the same intention.

Part of this issue may be our level of comfort with associating different files with one program. In PB I've always found it simpler to keep as much as possible in one file, using includes for multi-program stuff like macros and generic type functions, hence I may be over cautious about duplicate names. I expect that anyone with a background of VB will expect a lot of files specific to a program. The answer has to be in the middle of the muddle.(sorry about that, couldn't resist.)

And yes more input from others would be nice.

[StanHelton]

Rod, John, Everybody!

I had a brainstorm (or maybe it was a soapstorm) in the shower this morning and I can't get it out of my head.

(After a bit of reading I remembered that segment dumps won't work in a flat memory model. :SHOCKED: Segments don't exist anymore. )


Some time ago Chris suggested using an SQL database. It was a good idea, I just didn't recognize it at the time. I'm not going to suggest a 3rd party DB, BUT...

Using RANDOM files and a few simple object interfaces for maintaining them we can easily construct our own VB2PB database. The array & type structures (read "tables") are already built and require only a bit of modification. I think this may be the best way to track all the data we're talking about here. The Dictionary would be static, but the everything else we get from the VB source files.

On duplicate control IDs in different VB forms I like the idea of using the file name as part of the control name rather than a number -- human readable.

...
In VB it is possible to have an event that has the same procedure name as could be found in another VB form. For example, two forms, both with an OK button that are named "cmdOK"....

For best results the user will have to convert the VB forms first, save those necessary changes, then proceed on to the module level source code. With the VB form changes saved the module level conversion could be done one line at a time, or by procedure, or by file.

I had the impression that whole files has always been in the plan. The code I've been working on doesn't care how large or small the source block is. I didn't think about the order of conversion, though. Forms files first sounds like a good way to go.

...
Don't lose sleep over this issue please.

Nah, just gives me something to do while the body is refusing to sleep.

As I mentioned before I think we have to track direct changes to source code.

... my idea was to create tables on the fly as source code is processed through the converter. ...

We could also use the .INI file format:

[Form Name]
VB Procedure Name = VB Object Call, PB Procedure Name

With the section header pointing to the particular form being converted, so an entry might look like this:

[frmTIN]
mnuFileSortPntNo = frmTIN.mnuFileSortPntNo, FRMTIN_mnuFileSortPntNo

I'm not opposed to using the INI format, but I tend to favor a VB2PB database with TYPE arrays changed to tables with RANDOM files and a fairly simple VB2PB object to manage the data. (Why doesn't it sound simple when I re-read that sentence?)

We scan the VB Form source code file and extract procedure names and format their equivalent for PB in our table. Then we read the entire contents for an individual section and then parse each VB source code line and comparing that line against our table and substitute procedure names as necessary within the proper context as dictated by VB. This method allows us to use the VB event source code, limit the scope as per VB, and creates a unique procedure name for the PB compiler.

The same idea could be done for dialog, control, or menu equates.

Whaddythink?

I like it. :kool:

...
I guess in addition to the PB key/reserved words then we'll have to compare against names already accessed/processed VB Functions, Procedures, Types, Variables, Arrays etc....

Most likely. The up side is that we can do it on the fly with a PB RANDOM file database.

It seems to me that this has all the trimmings of the shutdown problem, stopping the converter at obvious break points rather than midstride.
On the other hand, solving this issue for one feature will likely solve it for the other.

I like this. We can update the DB at these points and minimize data loss throughout the conversion process.

...
This would work if the necessary variable/procedure names were maintained for the entire project. Somehow I got the concept into my mind that this type of data was only available for each form/module as they are individually converted....

We talked about it awhile back. Originally, I wanted to avoid using 3rd party databases (absolutely no idea how much data I was talking about at the time, though). Chris suggested an SQL DB back at the inception. Maybe he really knew what he was talking about!? Anyway, I think we've done the leg work ... just have to convert it to a RANDOM file table format.

...
the context of variable/procedure usage must be determined so we can point to the correct variable/procedure at the proper location in the source code.

IMO, this is a must.

...
I concur that there may be an issue with slightly or vastly different calls, scope, whathaveyou, but this just gives us a chance to warn the user with an obnoxious comment ...

Scope? Scope? :dangarn it! Something else I was taking for granted.

How does VB know how to segregate them? Shouldn't our converter be able to find the difference and convert appropriately?

Separate modules within a single compiled EXE. Could simulate with DLL libraries, but that's too complicated. Much better to use the file name prepended/appended to the ones that are problematic. That way we should be able to corral these ponies.

This is just my thoughts in the morning. I think what we have already adapts nicely into a simple VB2PB database. Other opinions welcome. Criticism encouraged. Corrections appreciated.

[Rodney Hicks]

Using RANDOM files and a few simple object interfaces for maintaining them we can easily construct our own VB2PB database.

With this comment you have stolen the thunder from my Diagnostapp. But not to worry.

Sorry, I got interrupted while writing this post.
The advantage, which I was referring to way back in the SQL discussion, is that it is all completely within our hands and one language.

[John R. Heathcote]

Stan and Rod,

This has been an interesting discussion.

I had thought about using a SQL DB too, perhaps I had read Chris' post and tucked it away in the back of my mind. Random files works for me.

I thought about using .INI files since I already had the necessary routines available to support the individual and block read/writes. This would be a simple solution, but maybe not be able to support everything we want to do. I thought I would give it a shot to see if this technique is adequate for our purposes.

Much better to use the file name prepended/appended to the ones that are problematic.

I hate to throw a spanner in the works, but what do we do if we have two files with the same name? This is possible if you have two files named GLOBALS.BAS, for example, but located in different directories. Using the file name alone doesn't necessarily guarantee a procedure name or variable name will be unique unless we somehow append the directory name too. IMO that would make our procedure and variable names impossibly long and difficult to manage and maintain. That's why I opted to use the form or module name property as defined by VB because it is a unique name, VB insists on that. The property name is available from the .VBP file.

On duplicate control IDs in different VB forms I like the idea of using the file name as part of the control name rather than a number -- human readable.

It is my understanding that the same control id can be used in two different forms as long as there aren't two controls on the form with the same id. If we have a command button in VB called "cmdOK" we could create an equate table with an entry like "%IDC_CMDOK = 28005" and could be made available throughout the entire PB project. We could cut down the number of equates we have to manage and maintain. Personally I like the idea of storing equates in a table because I'm always fiddling around with equate values, editing them manually, etc. A table makes reassigning values a simple matter.

I didn't think about the order of conversion, though. Forms files first sounds like a good way to go.

Neither did I initially, but showers have a way of bringing up these pesky little details. The .VBP file contains a "Start Up" property so I think we could use that as our beginning point as well.

I started writing the file scanning stuff using the loaded file in the editor as the source. From the scan I can identify all sorts of things and write this out to the .INI file just to see how difficult this will be. I don't anticipate any difficulties. Will let you know how this goes.

As Rod correctly points out there will be many other issues we haven't thought of when this beast is finally released.

BTW, Scott Turchin has some tools that we should probably review, with Scott's permission of course. Check out the Third Party forum.

Well, I'm off to take another shower. Anything specific you want me to ponder?

[John R. Heathcote]

To All:

The Third party tools I spoke of are by Tony Burcham. My sincere apologies to Mr. Burcham.

I have looked at the goods Tony is offering and they should be part of your coding tool kit, some really good stuff there.

[John R. Heathcote]

To All,

Need some clarification from some of the VB gurus out there.

I have a VB picture box control with the following properties set:

   Begin VB.PictureBox picTin 
      AutoRedraw      =   -1  'True
      BackColor       =   &H00000000&
      Height          =   11928
      Left            =   -60
      ScaleHeight     =   11880
      ScaleWidth      =   18708
      TabIndex        =   0
      Top             =   480
      Width           =   18756
   End

What does the negative "Left" property signify?

[Brian Chirgwin]

Left = -60 means the left position is -60.

This depends on the form the picture box is placed on and ScaleLeft property. Form.ScaleLeft default is 0. So, a left on the picturebox of -60 means the picture box is off the form by -60 [twips]

A Form.Scaleleft = -120 and picturebox.left = -60 would result in being 60 [twips] from the left side of the form.
A form.ScaleLeft = -60 and and picturebox.left = -60 would place the picturebox at the left side of the form.

Form can set up a viewport with the scale* properties.
Hope this makes sense.

To All,

Need some clarification from some of the VB gurus out there.

I have a VB picture box control with the following properties set:

   Begin VB.PictureBox picTin 
      AutoRedraw      =   -1  'True
      BackColor       =   &H00000000&
      Height          =   11928
      Left            =   -60
      ScaleHeight     =   11880
      ScaleWidth      =   18708
      TabIndex        =   0
      Top             =   480
      Width           =   18756
   End

What does the negative "Left" property signify?

[John R. Heathcote]

Brian,

It makes sense, however, when I view the form in VB the picture box is totally located within the dialog box. I will take a look and see if I reset the picture box control properties within my code, but off hand I don't think I did.