Announcement

Collapse
No announcement yet.

Module Messaging Spec

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

  • #21
    Is it not our job as converter gods of creation to find a way to tie all the aspects of the VB, in this case a textbox and a button, together. Can we not access the ShowDialog1 procedure(others as created by PBForms) and find the textbox features, then the button features from the other VB files and put them in their appropriate places in the ShowDialogx procedure or the Callback function.

    What these questions are leading up to is that if we use PBForms for the first stage and convert the files via the converter it would save us trying to tie PBForms(or its alternative) functionality with WinSpy functionality and any other program's functionality. I recognize that there are a lot of programs(tools) to do a lot of the things that we need done but trying to get them to work together might be just as big a problem as our original project.

    I am trying to ascertain if we are better off just getting the basics working, then adding a step here, a step there, etc. until it becomes time for a rewrite.

    We already have here in this forum a lot of capability, but we don't have it together in one place so that we can just add a new feature as we develop it.

    If we were to all stand back and take a look at the forest, I think that we might see a beautiful sight, even though not one of us is satisfied with it yet. With an edge trimmer and a bulldozer we could make the forest presentable as a wildlife preserve(VBers being what they are). We add human creature comforts a bit at a time.
    Last edited by Rodney Hicks; 16 Sep 2008, 02:42 PM. Reason: bad grammar
    Rod
    In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

    Comment


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

      Tokenizer keeps a log of line numbers associated with target terms (like CLASS, OPTION xxx, DIM, & etc.). If the message system sends an insertion point it's a simple matter to update the array (SpecialTerms().Term and SpecialTerm().LineNo). An %InsertAfterLineNo message ... and while I'm thinking about it, a %ReplaceLineNoWith message for when the user changes the VB source, just in case the SpecialTerms().Term needs to be changed or deleted. The new line would be passed as a VB code line in the usual way as a single line of code.

      For structures requiring more than one line of .... Pardon. I had a brain storm as I was typing. All of a sudden, multiple messages to get a whole structure seems a bit redundant.

      This may simplify the communication process. Suppose we have a GLOBAL gCurrentSourceFile() STRING array where each element is one line of the current VB source file. The Editor still has primary responsibility for this, but when it gets updated, the Toknzr only has to rescan the array to refresh the information. Allows for bigger changes by the user, even complete rewrites (which I am sure will happen) as the user edits his code. Reduces the number of times we have to pass things around internally. As I think about it, it will let me reduce the number of arrays the Toknzr has to maintain as well.

      The %ConvertThis message becomes a function call something like this:
      Code:
      FUNCTION ConvertThis(StartElement AS LONG, EndElement AS LONG) AS LONG
      Then function returns a status message to let the Editor know how it went. And the PB text could still be posted to the pbCodeBlock GLOBAL. The vbCodeBlock GLOBAL goes away. The SpecialTerms() array might go away too if the Toknzr has access to the entire file in this format. Tracking VB line nos. goes away because the array index is the line number. The Editor can use ARRAY SCAN/INSERT/DELETE and REDIM PRESERVE to update the array because it's a simple string array.

      We could use either method, but I favor this new idea right now. What do you think?

      The other alternative is to read source lines from one edit dialog and write the conversions to another dialog.
      Could go either way. gConcordance() tries to keep the VB & PB source lines separate while working on them.

      If you like the idea of putting the entire VB source file into a GLOBAL array, I believe we can dispense with the gConcordance() array altogether. If we keep it gConcordance() is going to use a LOT of memory.


      ...
      if 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.
      It's a shame, but your absolutely correct on this point.

      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'm currently scouring the forums for code and tools. I going to adapt any useful public domain code and forum contributor code with permissions.



      ...
      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).
      Some while back we talked about naming conventions. If I remember, part of that discussion (which included underscores) was to make the PB function names as close as possible to the function/method/event names used in the original. Hopefully doing this will preserve some of that flavor.


      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.
      wow! Great Minds run along parrallel paths. I was looking at that code this morning. It is the most promising I've found so far. If you've already tweaked a bit, please share. Maybe we can integrate it in short order.
      Do not go quiet into that good night,
      ... Rage, rage against the dark.

      Comment


      • #23
        Rod,

        Originally posted by Rodney Hicks View Post
        ....

        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.
        After viewing my VB form files the text to create the form as well as the individual event code for the controls and the form itself is also included in this code set. I believe the Callback Function(s) to make the VB event code work is included in the VB runtime module. All the VB user/programmer sees is the visual of the form and the individual event source code.

        Is it not our job as converter gods of creation to find a way to tie all the aspects of the VB, ...
        I must mildly disagree with you my friend. I think it is our goal to tie all aspects of VB together in order to generate a reliable PB conversion. I'm thinking of the relatively new (and maybe even an experienced) PB user who is running our converter. When the resulting PB code is generated they will be expecting it to work like their VB app. To do that we have to dig into the guts of VB and tie everything together that we can to make this work. I do agree that we may have to take this issue a step at a time.

        Can we not access the ShowDialog1 procedure(others as created by PBForms) and find the textbox features, then the button features from the other VB files and put them in their appropriate places in the ShowDialogx procedure or the Callback function.
        Yes, this was my idea as well, but the same functionality has to be duplicated in PB as well, we might not be forced to emulate the same VB events, but the functionality must be there.

        I am trying to ascertain if we are better off just getting the basics working, then adding a step here, a step there, etc. until it becomes time for a rewrite.

        We already have here in this forum a lot of capability, but we don't have it together in one place so that we can just add a new feature as we develop it.
        My sentiments exactly. We must merge the editor, Tokenizer, and Dictionary together now and see what happens.
        Later...

        JR

        "When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson

        Comment


        • #24
          Stan,

          As I mentioned to Rod I think we may be overstating the problem just a bit, getting lost in the details. The only way I see to know the full effect of what we are doing is to put the pieces together and try to make this converter thing work.

          Tokenizer keeps a log of line numbers associated with target terms...
          This being the case it doesn't make any sense to me to constantly update the Tokenizer arrays. Since your code appears to be set up to scan the VB file/procedure and rely on the critical targets it finds let's keep that functionality and let the editor create a separate PB conversion output dialog/edit box. This way we keep the VB input code and converted PB output code separate from each other. To make this work all I would need is a message from the Tokenizer that a change occurred in a source code line and to output that line, or the original source code line to the output dialog box.

          wow! Great Minds run along parrallel paths. I was looking at that code this morning. It is the most promising I've found so far. If you've already tweaked a bit, please share. Maybe we can integrate it in short order.
          I will send it to so you can take a look. Right now it is designed to read PB source code files and comment out the unused procedures, but it should work with VB code too.
          Later...

          JR

          "When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson

          Comment


          • #25
            Is it not our job as converter gods of creation to find a way to tie all the aspects of the VB, in this case a textbox and a button, together.
            I must mildly disagree with you my friend.
            Even I have to disagree with me. When I was creating that post I did some editing and I cut out more than I realized. It was supposed to be a funny line. Ah, well.

            We must merge the editor, Tokenizer, and Dictionary together now and see what happens.
            Couldn't agree more. Until we see these things operating together it is too hard to see which direction is the better one to go in when we come to a choice and it's too easy to get lost in details.
            You guys have done a tremendous amount of work, and letting and seeing your work work will work to make you a happy camper.(That sentence work for you?)
            Rod
            In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

            Comment


            • #26
              Rod.

              It was a lot of work.
              Later...

              JR

              "When governments fear the people there is liberty. When people fear the government there is tyranny." - Thomas Jefferson

              Comment

              Working...
              X