Announcement

Collapse
No announcement yet.

VB Form Conversion

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • John R. Heathcote
    replied
    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.

    Leave a comment:


  • Brian Chirgwin
    replied
    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.


    Originally posted by John R. Heathcote View Post
    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:

    Code:
       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?
    Last edited by Brian Chirgwin; 11 Nov 2008, 08:56 AM. Reason: Clarification

    Leave a comment:


  • John R. Heathcote
    replied
    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:

    Code:
       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?

    Leave a comment:


  • John R. Heathcote
    replied
    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.

    Leave a comment:


  • John R. Heathcote
    replied
    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?

    Leave a comment:


  • Rodney Hicks
    replied
    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.
    Last edited by Rodney Hicks; 3 Nov 2008, 11:45 PM. Reason: Adding info.

    Leave a comment:


  • StanHelton
    replied
    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.

    Originally posted by John R. Heathcote View Post
    ...
    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.


    Originally posted by John R. Heathcote View Post
    ...
    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:

    Code:
    [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:

    Code:
    [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:


    Originally posted by Rodney Hicks View Post
    ...
    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.

    Originally posted by John R. Heathcote View Post
    ...
    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.



    Originally posted by Rodney Hicks View Post
    ...
    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.

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • John R. Heathcote
    replied
    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.

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • John R. Heathcote
    replied
    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:

    Code:
    VB Procedure Name, VB Object Call, PB Procedure Name
    We could also use the .INI file format:

    Code:
    [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:

    Code:
    [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?

    Leave a comment:


  • John R. Heathcote
    replied
    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.

    Leave a comment:


  • Rodney Hicks
    replied
    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.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    ...
    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

    Leave a comment:


  • John R. Heathcote
    replied
    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.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    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

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

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

    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.

    An example of this would be converting a form, then maybe converting a module file, then back to another form. Where the tracking comes into play is when a module file, or even another form, potentially calls a procedure or VB event contained in the first form file. We have to know what variables and procedure names have been changed so the proper call can be made throughout the conversion process. Tracking also applies to equates and anything else where those values and strings may be carried forward to another form or module.

    Been thinking a lot about this feature in the shower. I have an idea, but I would like to get other thoughts on this issue too.

    Leave a comment:


  • StanHelton
    replied
    John, Rod, and all;

    I've been off the reservation for awhile now, so I'm not current on everything. Just looked in on the forums this evening from the Mile High City (Boulder). I've got some time to myself tomorrow, so I'll try to catch up. It might keep me from spending any of that hard earned cash I've been piling up in the corner.

    Here are 2 of the include files I'm working with right now. I use GLOBAL arrays to track these things. The first code is vb2pbGlobals.inc and the second is vb2pbTypes.inc so you guys can see what I'm trying to track. I haven't been thinking about VB forms as much as you have, so if you think we need to track more info, feel free to modify. Just keep me posted so I can keep up with you guys.... or at least tell which way you went with it.

    You may notice some GLOBALS and TYPES that we decided not to use. I've left them in for development just in case it turns out later... well, you know. Also, I've fallen out of the habit of dating the files... reverted back to my old habit of using the last modified date to track files on my system. Apologies if this causes any confusion. The last time I modified these files was yesterday, 10/31/08.

    vb2pbGlobals.inc
    Code:
    'vb2pb GLOBAL definitions
    
    GLOBAL gVbProjectName AS STRING                  'what it says  :)
    GLOBAL gParseReportFileList AS STRING            'holds files to be processed by Tokenizer
    
    GLOBAL gPropertyArray() AS PropertyType          'use these arrays only for
    GLOBAL gFunctionArray() AS MethodType            '   properites, functions,
    GLOBAL gEventArray() AS EventType                '   events, variables, and
    GLOBAL gClassArray() AS ObjectSimulatorType      '   variants contained in
    GLOBAL gVariableNames() AS VariableNamesType     '   current VB6 project.
    GLOBAL gVariantNames() AS STRING
    
    GLOBAL gConverterOptions AS ConverterOptionsType
    
    GLOBAL gPBWinSubFolder   AS STRING               'completed PBWin project files go here with ".bas" or ".inc" extension
    GLOBAL gpbSourceFileList AS STRING               'intermediate PBWin files with ".pbas" or ".pinc" extension
    GLOBAL gConcordance() AS ConcordanceType         'array for VB & PB code lines w/indexed line nos.
    
    GLOBAL gMainWindow AS DWORD                      'hDlg for the main Tokenizer window
    GLOBAL gSaveOptionsWindow AS DWORD               'hDlg for the Tokenizer save window
    
    GLOBAL gTokenizerStatus  AS LONG                 'current program status
    GLOBAL gPreviousStatus AS LONG                  'previous program status
    GLOBAL gAutoDelay AS LONG                       'converter autodelay between processing steps
    GLOBAL gAutoPause AS LONG                       'converter pause interval
    GLOBAL gProjectIsSaved AS LONG                  'curremt save status of current project
    GLOBAL gProjectIsParsed AS LONG                 'current parse status of current project
    GLOBAL gParseReportFileList AS STRING           'list of parsed files in current project
    
    
    'Editor/Converter Message Queue
    GLOBAL gMessageQueue() AS MessageType               'message queue
    GLOBAL gVbCodeBlock AS STRING                   'VB6 code to be converted
    GLOBAL gPbCodeBlock AS STRING                   'converted PBWin code
    
    'vb2pb Directories
    GLOBAL gVbProjectFiles AS STRING                'delimited string
    GLOBAL gPbOutputFiles AS STRING                 'delimited string
    
    'initialize global objects
    GLOBAL oConverterInterface AS MessageInterface      'initialize internal object for communication with editor
    GLOBAL oEventHandler AS MessageEvents               'initialize internal object for event handling
    vb2pbTypes.inc
    Code:
    'Type structures
    '=====================
    
    
    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
        Scope AS LONG                   'use equates above
        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
        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
        Eventss 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
    
    TYPE ParsedCodeType
        LineNo AS LONG
        TermNo AS LONG
        Term AS STRING * 32
    END TYPE
    
    TYPE pbPseudoCodeType
        LineNo AS LONG
        TermNo AS LONG
        Term AS STRING * 32
        DictionaryRef AS LONG       'use physical record # for now
    END TYPE
    
    TYPE DictionaryRecordType       'modified from Rod's example below
        reference AS LONG           'ref # for the word ? -- Dictionary record # ?
        vbTerm AS STRING * 64       'any VB term
        level AS LONG               'level of complexity
        pbTerm AS STRING * 64       'mathcing PB term
        termType AS LONG            'type of complication ? -- type of term ?
        pointerToCode AS DWORD      'self descriptive
        params AS LONG              'params for pointerToCode if needed
        Comment AS STRING * 128     'possibly used for comment insert to PB source file
        location AS LONG            'placement of PB term in code
        referral AS LONG            'xRef to other term/s
        reserved1 AS LONG
        reserved2 AS LONG
        reservedStr1 AS STRING * 256
        reservedStr2 AS STRING * 256
    END TYPE
    
    
    '==============================================================================
    '   *** NEW DICTIONARY DEFINITIONS FROM ROD *** 7/26/2008
    '==============================================================================
    #IF 0   'original prototype commented out to minimize necessary code changes elsewhere
    TYPE VBterminPB AS whatever
      reference AS LONG           'reference number for the word- do we want to make them equates???
      VBterm AS STRING*32         'any VB term, keyword, function, reserved word, constant, etc.
      level AS LONG               'level of complexity see below
      PBterm AS STRING*32         'the matching PB term
      termtype AS LONG            'type of complication
      pointertocode AS LONG       'just what it says
      params AS LONG              'for parameter info to above if required
      comment AS STRING*128       'comment string, possibly used in code if not too verbose
      location AS LONG            'where the PBterm should be in code see below
      referral AS LONG            'for referring to another term
      reserved1 AS LONG           'reserved- for use in difficult times
      reserved2 AS LONG           'reserved- for use in even worse times
      reservedStr1 AS STRING*256    'reserved- for saying what we think of it all
      reservedStr2 AS STRING*256    'reserved- for jokes, comedic efforts and the like and things that aren't funny but should be
    END TYPE
    #ENDIF  'end of original TYPE prototype
    '=================================================================================
    
    TYPE SpecialTermsType
        Term AS STRING * 32
        LineNo AS LONG
    END TYPE
    
    TYPE ConstantsType
        Constant AS STRING * 32
        LineNo AS LONG
        Value AS LONG
    END TYPE
    
    TYPE ConverterOptionsType
        DefaultArrayBase AS LONG            '0 or 1
        CaseInsensitiveCompare AS LONG      '%False = Normal PBWin compare, %True = case insensitive compare (UCASE$ required)
        DimAll AS LONG                      '%False = OPTION EXPLICIT not present in VB code, %True = present
        PrivateModule AS LONG               '%False = OPTION PRIVATE MODULE not present in VB coe, %True = present
        LineByLineProgress AS LONG          '%True = user selected, %False = very fast, if any, updates
        LineByLineEdit AS LONG              '%True = user wants to go slow, %False = user wants to edit later
        pbStyleEquates AS LONG              '%True, %False = insert "MACRO CONST = MACRO" and %UseMacros = %True to preserve VB6 style constants
        WholeFileConversion AS LONG         '%True = file will be converted without intermediate feedback, %False = convert a VB6 string of x lines
    END TYPE
    
    TYPE ConcordanceType                    'use in Concordance() to keep track of which VB line matches which PB line
        vbLineNo AS LONG
        vbCodeString AS STRING * 256
        pbLineNo AS LONG
        pbCodeString AS STRING * 256
    END TYPE
    
    TYPE DirDataType                        'PBWin structure for directory data returned from DIR$
      FileAttributes        AS DWORD
      CreationTime          AS QUAD
      LastAccessTime        AS QUAD
      LastWriteTime         AS QUAD
      FileSizeHigh          AS DWORD
      FileSizeLow           AS DWORD
      Reserved0             AS DWORD
      Reserved1             AS DWORD
      FileName              AS ASCIIZ * 260
      ShortName             AS ASCIIZ * 14
    END TYPE
    
    
    TYPE MessageType
        SendTo AS LONG              '%Editor or %Converter or %MikesGUIThingy
        SentFrom AS LONG            '%Editor or %Converter or %MikesGUIThingy
        MsgGrp AS LONG              'one of %INFO, %WARNING, %ERROR, %FATALERROR (see vb2pbEquates.inc for list)
        MsgID AS LONG               'a value from the message list in vb2pbEquates.inc
        ResponseTo AS LONG          'OPTIONAL - array index of message this one responds to
        ResponseReqd AS LONG        'OPTIONAL - %True or %False
        ResponseRcvd AS LONG        'OPTIONAL - %True or %False
    END TYPE
    I'm concentrating on the internal messaging for VB2PB right now. When you identify a message that you need to include in the list, please post it so we can all read off the same page.

    I've finally figured out PB 9 objects. I'm using a Message object to handle the gMessageQueue() and an Event object to trigger message alerts. The last TYPE in the second file is what the gMessageQueue() looks like. More as soon as I get it working properly.

    Stan

    Leave a comment:


  • John R. Heathcote
    replied
    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 for PB.

    If you have implemented such a method how did you do it? I think we need to keep this type of tracking mechanism standardized too.

    Leave a comment:


  • Rodney Hicks
    replied
    Somewhere, sometime, in the development of this converter we're going to need a list of messages generated by Windows, and this link is to a fairly comprehensive list in the twentieth post.
    http://www.powerbasic.com/support/pb...essages&page=2

    Leave a comment:

Working...
X