Announcement

Collapse
No announcement yet.

BIG QUESTION, need answer

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

  • BIG QUESTION, need answer

    Rod, John,

    I plan to order my copy of PB 9 & CC 5 first thing in the morning.

    How does this new release affect your perception of this project?

    I think we should continue.

    Stan
    Do not go quiet into that good night,
    ... Rage, rage against the dark.

  • #2
    Stan,

    Absolutely, we should continue. There will still be problems converting VB to PB 8 or 9, although now that PB handles objects a major portion of what we were planning to do has been taken care of by Mr. Zale and company, many thanks Bob!

    I think the real question is, how soon can we get a handle on the new PB 9.0 features and new function/statements? And, how long will these new PB features delay the release of the converter? OOPs (no pun intended) that's two questions. Given the fact that PB 9 was just announced, perhaps we should hold off on the initial Sept. release date until we have some idea of the ramifications PB 9.0 will have on the converter.

    One thing's for sure, our job just got a whole lot easier. I plan to purchase my copies of PB 9 and PBCC 5 ASAP.

    BTW, did you have a chance to look at my Scintilla app? I know it's rough in a lot of spots, but it is just a concept.
    Later...

    JR

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

    Comment


    • #3
      My order for PBWin 9.0 was acknowledged within half an hour of Mr. Zale's posting that it was available. PBCC 5.0 is going to have to wait a wee while.

      However, since that new forum appeared I have done nowhere near what I should have on this project. Trying to wrap my head around Mr. Zale's posts.

      I too, think this should go on, but a lot of rethinking might be in order the dictionary(AGAIN!!!) not sure there, and the two of you will be better judges, than I. It seems that we have more conditions than I had previously considered.

      All in all, I think the converter should be a piece of cake now.

      Rod
      Rod
      I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

      Comment


      • #4
        Originally posted by John R. Heathcote View Post
        Stan,

        Absolutely ...

        I think the real question is, how soon can we get a handle on the new PB 9.0 features and new function/statements? And, how long will these new PB features delay the release of the converter? ....
        Good question. I think we can make a basic v1 on or about the original deadline aimed at PB 8.04. I think v2 should aim at PB 9. It seems PB is now a COMPLETE OOP compiler!


        ...
        BTW, did you have a chance to look at my Scintilla app? I know it's rough in a lot of spots, but it is just a concept.
        To be honest, no I haven't. I let the deadline anxiety get the better of my judgement. I've been working furiously on Tokenizer code for the last few days. But now that PB 9's here, I think I'll relax a bit and look at the Scintilla first thing in the morning -- right after I place my order.


        Originally posted by Rodney Hicks View Post
        ...

        However, since that new forum appeared I have done nowhere near what I should have on this project. Trying to wrap my head around Mr. Zale's posts.
        I know what you mean. My head's swimming with all that new information. Some of what he posted helped me in simulating simple objects for PB 8, though. So I've been head down in code, coming up for air only when I saw a new post from Bob.

        I too, think this should go on, ...
        That makes it unanimous.


        ...
        but a lot of rethinking might be in order the dictionary(AGAIN!!!) not sure there, and the two of you will be better judges, than I. It seems that we have more conditions than I had previously considered.
        I agree that we need to rethink the dictionary, if nothing else to ensure future feature enhancement. Is it possible we were over-engineering the dictionary?

        I'd like both of you to share your opinions of the VB Terms List text file I've posted in the Dictionary thread. I'm beginning to think we can make a decent version one just using the basic info that shipped as the original VB6 language reference.

        And with this new PB compiler, VB2PB v2 might just be a cadillac!

        Stan
        Do not go quiet into that good night,
        ... Rage, rage against the dark.

        Comment


        • #5
          And with this new PB compiler, VB2PB v2 might just be a cadillac!
          Which makes you prescient, Stan. Good call.
          Rod
          I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

          Comment


          • #6
            Stan,

            I think we can make a basic v1 on or about the original deadline aimed at PB 8.04. I think v2 should aim at PB 9.
            Sounds reasonable to me.

            My head's swimming with all that new information.
            There was a lot of information there. I can see that PB objects will save us some time, but it will be necessary to get them straight in our collective heads before we use them. To be honest, I rarely messed around with my own objects in VB, as an old FORTRAN guy I grew to love the procedural coding style. I did, however, use 3rd party objects, such as AutoCAD for example, got really familiar with them, even more so than I wanted to know.

            I agree that we need to rethink the dictionary, if nothing else to ensure future feature enhancement. Is it possible we were over-engineering the dictionary?
            I think you may have hit upon something. My experience writing my Scintilla app showed me that most of the VB to PB conversions will require very little in the way of conversion, mostly minor tweaks and slight reformatting of variables, etc. This is not to say that we should abandon the more exotic VB conversion stuff, not at all, but save it for future releases. IMHO we can accomplish a lot by concentrating on Level 1, possibly Level 2 conversions, having some sort of reporting facility where we can insert obnoxious messages/comments to get the users attention, and have a rudimentary editor from which the user can view the changes as the converter makes them.

            This is the direction I think we should go, but I will certainly leave it up to you guys to make the final decision which direction the converter should go as you fellows are certainly more knowledgeable than I about the technical stuff.

            And with this new PB compiler, VB2PB v2 might just be a cadillac!
            I prefer Porsche's myself.
            Later...

            JR

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

            Comment


            • #7
              A tad off topic for this thread, but...

              We were considering various conversion options, a line at a time, a function/sub, module, or full project.

              Since imitation is the sincerest form of flattery and all that, why don't we take a page out of PBForms. Sort of.

              Since the users of the converter are going to be programmers, why not let them place the following two lines appropriately wherever and as often as needed by their own estimation.

              CONVERTER ON
              CONVERTER OFF

              In other words the converter handles and reads the files in some established order and starts converting at the first CONVERTER ON statement and stops when it encounters CONVERTER OFF, then starts converting at the next CONVERTER ON statement, and so on, and so on ....

              This suggestion is for the first version of course. This way we don't have to program into the first version a sophisticated code selection system to get what the user wants done converted.

              Necessity may be the mother of invention, laziness is the other parent.

              PS
              In version 2, the sophisticated code selection system would just have to insert these lines into the code to attain a measure of product improvement.
              (If you work at it, laziness can be pushed to extremes.)
              Last edited by Rodney Hicks; 13 Aug 2008, 01:27 AM. Reason: add Post Script
              Rod
              I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

              Comment


              • #8
                Excellent!! We will charge on, then.

                Rod, I like that CONVERTER ON/OFF idea. Did you get a chance to look at the completed list I uploaded?

                John, I'll be looking at your Scintilla app in a couple hours. Give some feedback once I've had a chance to digest it, later today.

                I've been rethinking the parser routine as well. I think I've figured out a way to make it even simpler. Level 1 conversion line by line, with a small LookAhead FUNCTION to keep structures intact (SUBs, FUNCTIONs, etc.).

                Will try to update the SVN tonight around 6pm, my time, so that everybody can see and/or work with the same code and templates.

                I'm off to place my order!!!!!

                Stan
                Do not go quiet into that good night,
                ... Rage, rage against the dark.

                Comment


                • #9
                  Rod,

                  CONVERTER ON
                  CONVERTER OFF
                  Nice idea, I like it. One suggestion though, we might consider:

                  Code:
                  ''//CONVERTER ON
                  ''//CONVERTER OFF
                  With the "CONVERTER" command prefaced by a sequence of "special obnoxious" comment characters, this way, the source would compile in case the user forgot (which in my case is quite easy to do) to remove the CONVERTER ON/OFF directives before the compile. Just a thought.

                  Stan,

                  My Scintilla app fills some of Rod's suggestions that we convert line by line, by procedure, or entire file. This functionality is tied in with the "F5" and "F8" keys, the same ones used by VB and PB for the same purpose. The user can set predefined book marks to accomplish limited conversion as well. Be sure to read the README.doc file first as it explains some things.

                  Thanks.
                  Later...

                  JR

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

                  Comment


                  • #10
                    Definition for CONVERTER ON/OFF directive:

                    CONVERTER ON/OFF

                    syntax:
                    ''//CONVERTER [ON | OFF]

                    ''// special obnoxious string to cue vb2pb without interfering with compiler. Because of leading single quote compiler treats this line as a comment.

                    CONVERTER command string to vb2pb

                    ON vb2pb starts converting with the next line of code

                    OFF vb2pb stops converting until EOF or next CONVERTER ON, default setting at beginning of conversion process.

                    Comment: While it is recommended to remove this command from code you intend to compile in VB6, the leading single quote makes removing the command optional. Note that the default value is OFF. That means at least one CONVERTER ON command line should be placed into your code. If you wish to process the entire file place this command before all other code.
                    I'm reading the Scintilla doc now.
                    Do not go quiet into that good night,
                    ... Rage, rage against the dark.

                    Comment


                    • #11
                      Stan,

                      Definition for CONVERTER ON/OFF directive:
                      Works for me.

                      After having just taken a shower and letting my mind concentrate on the CONVERTER command, I was struck by the thought (not to mention getting soap in my eyes) that we could have our own converter command language to take care of all sorts of special conversion problems. Version 2.0 is looking better and stronger all the time.

                      I'm sure you and Rod have thought of this, but just for the record I will state it too, VB2PB should be as forgiving and nondestructive as we can possibly code it.

                      Looked through the VBTERMS file, there's alot there, will have to give the contents some additional thought. Will get back to you on this.

                      I can see right now my association with you good folks is going to cost me some money 'cause I'm off to buy PB 9.0 too.
                      Later...

                      JR

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

                      Comment


                      • #12
                        Bob Zale's thread "Be the first on your block..." was started at 2:21, my confirmation of order was received at 3:19. Not quick enough to be first, but I'm in line waiting for delivery via the mail(included manual) so I won't be running PB 9 for a wee while. I won't be ordering PBCC for a while, dollars being what they are.

                        I'm glad you guys liked the CONVERTER ON/OFF idea, there may be other codes we could use in similar fashion. Prepending the comment characters was a good idea although I would think that anyone converting code would be using a second copy of the code to convert, maintaining the original in original form for nostalgia's sake.

                        I have looked at the file, and I am wondering, have been for a while, if there isn't such a monster already in existence, perhaps in slightly different format, elsewhere in the PB universe. It might not hurt to inquire formally somehow.

                        I had been running into difficulty with the constants, finding the appropriate constant name/value/purpose and then checking against the SDK for clarification. The same is going to happen with the Methods/Properties/Events etc. terms I believe(no SDK for clarification though).

                        The layout of your file is good and easy to work with. You might want to give me some advice on how you want me to work with that, because it is half of the terms job in one place, and I assume you want the other half in the same place. Same format? term appended to VB term? What about other essential info?

                        On a different note, on Friday I've got to disappear for a few days again because of a death in the family. Should be back up Monday sometime.
                        Last edited by Rodney Hicks; 13 Aug 2008, 12:41 PM.
                        Rod
                        I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

                        Comment


                        • #13
                          Originally posted by John R. Heathcote View Post
                          ...
                          After having just taken a shower and letting my mind concentrate on the CONVERTER command, I was struck by the thought (not to mention getting soap in my eyes) that we could have our own converter command language to take care of all sorts of special conversion problems. Version 2.0 is looking better and stronger all the time.
                          Like I said, a Cadillac! Loaded.

                          ... VB2PB should be as forgiving and nondestructive as we can possibly code it.
                          Definately.

                          Looked through the VBTERMS file, there's alot there, will have to give the contents some additional thought. Will get back to you on this.
                          Rod noted that it's only half the dictionary. I'm thinking we could use it as is, just writing our code to use the plain text file. Text file is easier to update later if we need to.


                          Originally posted by Rodney Hicks View Post
                          Bob Zale's thread "Be the first on your block..." was started at 2:21, my confirmation of order was received at 3:19. Not quick enough to be first, but I'm in line waiting for delivery via the mail(included manual) so I won't be running PB 9 for a wee while. I won't be ordering PBCC for a while, dollars being what they are.
                          Yeah. Cash flow being what it is I had to wait til today to place my order. But I'm right behind you (well, maybe a few hundred spots back) in line.

                          ...
                          I'm glad you guys liked the CONVERTER ON/OFF idea, there may be other codes we could use in similar fashion. Prepending the comment characters was a good idea although I would think that anyone converting code would be using a second copy of the code to convert, maintaining the original in original form for nostalgia's sake.
                          I'm thinking this is the first command in our vb2pb conversion script language. (Me? Grandios? noooooo.....)


                          I have looked at the file, and I am wondering, have been for a while, if there isn't such a monster already in existence, perhaps in slightly different format, elsewhere in the PB universe. It might not hurt to inquire formally somehow.
                          Will do.

                          I had been running into difficulty with the constants, finding the appropriate constant name/value/purpose and then checking against the SDK for clarification. The same is going to happen with the Methods/Properties/Events etc. terms I believe(no SDK for clarification though).
                          Yeah, I noticed that too. Down lower in the file is a list of constants. Are those at all helpful?

                          The layout of your file is good and easy to work with. You might want to give me some advice on how you want me to work with that, because it is half of the terms job in one place, and I assume you want the other half in the same place. Same format? term appended to VB term? What about other essential info?
                          Just off the top of my head, include a double pipe (||) or an elipsis (~) to separate PB from VB on the same line and use the same format? Feel free to modify the format any way you see fit to accommodate essential info. The only thing is I think the text file will be easier to work with, modify, update, change, burn, spill coffee on, etc, etc.

                          On a different note, on Friday I've got to disappear for a few days again because of a death in the family. Should be back up Monday sometime.
                          Be well and safe on your trip. Sorry for your loss.

                          Stan
                          Do not go quiet into that good night,
                          ... Rage, rage against the dark.

                          Comment


                          • #14
                            Originally posted by John R. Heathcote View Post
                            ...
                            My Scintilla app fills some of Rod's suggestions that we convert line by line, by procedure, or entire file. This functionality is tied in with the "F5" and "F8" keys, the same ones used by VB and PB for the same purpose. The user can set predefined book marks to accomplish limited conversion as well. Be sure to read the README.doc file first as it explains some things.

                            Thanks.
                            John,

                            I like the concept. The Scintilla editor may be just what we need. My only trouble is that I don't use FireFly, so I have difficulty with some of the generated code.

                            OTOH, I AM impressed. Your app does exactly what I was trying to do with my little editor window. Will save quite a bit of work. Maybe we won't have to delay the release for too many days after all.

                            I've run the app on some of my VB code and it looks good (better than mine!). On my machine it hangs in a couple of places, but you said this is concept demo, so I'm not worried about that.

                            I've reviewed the Scintilla docs and the doc you wrote. I think you've found a solution to the editor issue. So....

                            Since I don't do FireFly, how should we proceed here? I'm not clear on how to use the SciLexer.DLL in a PB IDE environment. The API calls are clear enough, but I will be working with a slight learning curve.

                            Basically: I like it!

                            Stan
                            Do not go quiet into that good night,
                            ... Rage, rage against the dark.

                            Comment


                            • #15
                              Rod,

                              On a different note, on Friday I've got to disappear for a few days again because of a death in the family. Should be back up Monday sometime.
                              My sincere condolences to you and your family. I will keep a good thought while you are away. Please take all the time you need.
                              Later...

                              JR

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

                              Comment


                              • #16
                                Stan,

                                Glad you like the concept. I think one of my strengths is conceptual design, a trait shared by many left-handed individuals.

                                On my machine it hangs in a couple of places, but you said this is concept demo, so I'm not worried about that.
                                Just for my own edification when and where does my app hang up. Could be this is a Firefly problem, OTOH could also be a Scintilla problem. Might be one of those cumbersome aspects that I mentioned earlier. If this is the case we would need to trace this down it might be solved by using other Scintilla commands.

                                Since I don't do FireFly, how should we proceed here? I'm not clear on how to use the SciLexer.DLL in a PB IDE environment. The API calls are clear enough, but I will be working with a slight learning curve.
                                Actually it is not any more difficult to use in PB IDE environment than it was to implement in Firefly, one does not depend on the other. I used Firefly as it was what I was familiar with for dialog box design, but I could switch over to SDK or PBForms (I think I still have it) if need be.

                                I based much of my Scintilla application on Jose Roca's initial source code editor "PBSCITE" which is available on POFFS or the PB Source Code forum and is a SDK app. PBSCITE is Jose's first attempt (and a very good one I might add) at using the Scintill editor control and what eventually became his SED editor, so we could use this app as the basis for implementing our converter. So the real credit and kudos should go to Jose. I would like to get Jose's input on this issue just to cover all of our bases.

                                Personally I think I may have gone a little overboard with the animation on most of my commands, which can be fixed by using other Scintilla commands to read the file. If you don't want the animation effect while reading the file and making the conversions Scintilla can be quite quick. OTOH animation lets the user know something is happening which can be quite reassuring, one of those user issues.

                                Basically, all we have to do to make this work in PB IDE (or any other PB editor for that matter) is to read a line(s) in Scintilla, pass the line(s) to the Tokenizer for processing along with a flag to determine if the original line has been changed, pass the revised source code line(s) back to Scintilla and update the display, if necessary. BTW I deliberately chose to comment out VB changes so the user can see the differences between VB and PB, take every opportunity to educate the new PB user, however, this functionality could also be a user defined option, but I think it should be a default.

                                The Scintilla control has an UNDO/REDO feature, but it is based on available memory which can vary from system to system. That is why I chose to implement my own version of the UNDO feature by using incremental saves. Perhaps we can use both.

                                One other issue I was thinking about is to update (upgrade?) the original VB code to the recommendations made in the PB help file concerning coding, e.g., use the "OPTIONAL" key word for "[]" in the argument list, specify the data TYPE instead of using the type identifier, etc. Perhaps this functionality could be addressed as a series of (RE)FORMAT commands.

                                Just a thought.
                                Later...

                                JR

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

                                Comment


                                • #17
                                  Originally posted by John R. Heathcote View Post
                                  ...
                                  Just for my own edification when and where does my app hang up. Could be this is a Firefly problem, OTOH could also be a Scintilla problem....

                                  Let me run it again tonight and make notes this time as I go. Feedback in the morning.

                                  ...
                                  Actually it is not any more difficult to use in PB IDE environment than it was to implement in Firefly... but I could switch over to SDK or PBForms (I think I still have it) if need be.
                                  Okay, so it's just a matter of me learning the Scintilla API. I can do that. I think we decided to make PBForms a requirement to simplify the dialog creation tasks. I'm not sure if that is still a valid reason, but I tend to think so.

                                  I based much of my Scintilla application on Jose Roca's initial source code editor "PBSCITE" ...
                                  I would like to get Jose's input on this issue just to cover all of our bases.
                                  Why don't you ask him about it while I spend a day or so learning the API?

                                  ...
                                  OTOH animation lets the user know something is happening which can be quite reassuring, one of those user issues.
                                  All the feedback I've gotten says the user won't care if it takes 2 minutes, 2 hours, or even 2 days. Animation is good.

                                  ...
                                  all we have to do to make this work in PB IDE ...
                                  Works for me.

                                  ...
                                  BTW I deliberately chose to comment out VB changes so the user can see the differences between VB and PB, take every opportunity to educate the new PB user, however, this functionality could also be a user defined option, but I think it should be a default.
                                  Once I remembered that you had set it up that way, I found this feature useful in my test runs.

                                  No problems with your UNDO/REDO. We want it to play nice on most PCs.

                                  ...
                                  One other issue ...
                                  update (upgrade?) the original VB code to the recommendations made in the PB help file concerning coding ...
                                  Sounds like something for the vb2pb Command Language. I'm beginning to think the command line interface won't be too much trouble to make.

                                  All good ideas. We're making some serious progress now. Just in case I didn't say it before: Thanks for joining the project.

                                  Stan
                                  Do not go quiet into that good night,
                                  ... Rage, rage against the dark.

                                  Comment


                                  • #18
                                    Stan,

                                    I think we decided to make PBForms a requirement to simplify the dialog creation tasks. I'm not sure if that is still a valid reason, but I tend to think so.
                                    Well, this really depends on how we want to set up the converter. If we have the main dialog containing the Scintilla edit control, a dialog for the "Command Center" that would comprise about 75% of all the dialog functionality we may need, couldn't that be handled using SDK? OTOH the remaining 25% dialog functionality would have to be added and I suppose it wouldn't be a good idea to mix SDK and DDT would it?

                                    I do have PBForms, but it doesn't seem to handle MDI, at least I couldn't find it. If true, the MDI aspects of an editor will have to be coded by hand anyway. I will investigate the difficulty here and get back to you.

                                    Sounds like something for the vb2pb Command Language. I'm beginning to think the command line interface won't be too much trouble to make.
                                    Type identifier conversion functionality could also be handled with some sort of preprogrammed routine. The issue here is, do we really need to address type identifier conversion, or do we leave this alone and let the user determine if they want to remove type id's at their convenience? After all, type identifiers will not necessarily cause the resulting converted source code to fail the compile process, the only caveat at the present time being the warning Mr. Zale states in the help document about type identifiers being deprecated in the future. Having said that, it does make sense to offer the user the opportunity to get their old VB code up to current recommended PB coding standards. I think this is one of those issues where we should offer the user the capability of revising type identifiers if they want to.

                                    A possible command to do this would be:

                                    Code:
                                    ''//REPLACE ON ANY "!#$%&" WITH ""
                                    ''//REPLACE OFF
                                    To borrow from PB syntax.

                                    Just in case I didn't say it before: Thanks for joining the project.
                                    I'm enjoying myself, it is nice to work with you and Rod and everyone else that understands the true nature of the problem, are willing to look at all ideas with an open mind, but all the while keeping an eye on the fact (with gentle prodding once in a while) that we are all here to drain the swamp. Yup, it's fun.
                                    Later...

                                    JR

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

                                    Comment


                                    • #19
                                      Gentlemen,
                                      I think we decided to make PBForms a requirement to simplify the dialog creation tasks.
                                      We did, but with the caveat, perhaps unmentioned at the time in my delight at discovering(okay, being advised of) this aspect of PBForms, that the resulting code converted by PBForms is DDT style.

                                      In light of the recent development with PB 9, I suggest that we carry on with and concentrate more on using the DDT style. I'm anticipating less use of the SDK to some extent with the advent of PB 9. That most user's of our product will likely be using PB 9, while not a given, is a logical assumption on my part.

                                      By passing the *.frm files through PBForms first, a considerable amount of conversion is already done for us, though the converter will have to parse to pick up the things that were not supported in DDT at the time.

                                      While I know I shouldn't go out on a limb without a safety net, I am going to state that I suspect that a PBForms 2 may not be far away. Just in time for converter version 2??

                                      DDT and SDK can be mixed, there are plenty of examples of it in the fora, one just has to be judicious, and in our case, make the converter judicious.

                                      Remember too, that version 1 was going to have some gaping holes, and MDI might have to be one of them, there are a few others that I think might or might not be shunted aside until later versions. Hooks, Printing, Coordinate Spaces, Device Contexts etc come to mind. In fact somewhere in this forum there was a list of things that we were going to get into version 1 because they were likely to be the most common items the converter was going to encounter. I'll have to find that.

                                      While it took them years to make VB as bad as it got, we haven't years to solve all the problems they created. Some of the VB code, will be best rewritten by hand anyhow, simply because of the drastic improvement when done PB style, which of course teaches the ex VB programmer PB style programming.

                                      With regard to type identifier, while the PB manual(p143) may have errors in it, I don't think so in this regard and this should be able to be handled by the converter as part of the normal vbterm=pbterm conversion process, with VARIANTs and some CONSTs maybe needing some extra help. The #$% jargon wouldn't get placed in the converter output, because the converter would be converting to the suggested standards.(That looks like a censored sentence, doesn't it?)

                                      From what you've seen so far with regards to the PB 9, how do you feel about the Scope issue we were looking at a few weeks ago?

                                      I will be adding to the your file Stan over the weekend, time permitting, since everything needed should be in my laptop already.

                                      that we are all here to drain the swamp
                                      I like that.
                                      Rod
                                      I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

                                      Comment


                                      • #20
                                        PB 8 or PB 9 support?

                                        I go on vacation and upon my return things have changed.

                                        Do we continue to support PB 8? I'm not sure, I will be moving to version 9. I think the VB2PB converter will be written in PB 9.

                                        If we do support PB8, we may be able to use PB9 COM features to make the support easier. i.e A set of Objects, COM classes (created in PB9) that PB8 can use to implement VB classes easier in PB 8.

                                        So, do we support v8 or jump to supporting v9?


                                        Originally posted by StanHelton View Post
                                        Rod, John,

                                        I plan to order my copy of PB 9 & CC 5 first thing in the morning.

                                        How does this new release affect your perception of this project?

                                        I think we should continue.

                                        Stan

                                        Comment

                                        Working...
                                        X