Announcement

Collapse
No announcement yet.

BIG QUESTION, need answer

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

  • #21
    I'm leaning towards using PB 9 entirely rather than some of each. I think the changes in PB 9 from PB 8 are worth the jump, not to mention that having the converter convert code to PB 9 standards will make the project a lot easier, once we all get our heads around it. A lot of stuff that has been figured out will be just as useful in either version. And it will help us all pick up the interesting nuances of PB 9 a lot quicker.

    Strangely enough, this issue is one of the reasons that I was reluctant to use any other products for creating the converter. Just like our converter has to be PB 9 compatible now, so do all the other products in order to get full value of PB 9, thus working with another product we may not be able to use full value of the new software.
    Rod
    I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

    Comment


    • #22
      Rod,

      Developing the converter in PB 9.0 is a two edged sword. While I agree that it would be nice to take advantage of all the new and really cool features of PB 9.0 when converting old VB code, what about the user that doesn't have 9.0 yet? If all they have is PB 8.04 then all of the nifty VB to PB 9.0 conversions won't do them a bit of good. Not trying to be negative here, but just playing devils advocate.

      IMHO if we develop in PB 9.0 we should probably convert to PB 8.04 standards, at least for the first version of the converter. Once PB 9.0 is more firmly established and used by the majority of PowerBASIC customers, then we can convert VB to PB 9.0. Does that make any sense?

      For the record I ordered my upgrade copies of PB 9.0 and PBCC 5.0 yesterday, yeah I splurged, felt good too.

      In light of the recent development with PB 9, I suggest that we carry on with and concentrate more on using the DDT style.
      OK.

      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.
      This does bring up a nagging question, what is the user supposed to do if they do NOT have PBForms? Obviously the converter would have to inform the user that, perhaps, a major portion of their VB project could not be converted without PBForms. Is there another way to convert VB forms without the use of PBForms? Personally, I think we should provide some rudimentary VB form conversions for the user as they will be expecting our converter to work, and be very put off by a warning message like:

      "WARNING - YOU NEED PBFORMS TO CONVERT YOUR VB FORMS TO PB!"

      Bad PR.

      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??
      I agree, can't imagine Mr. Zale releasing a major upgrade to the PB compilers without considering his supplemental development tools in the upgrade path too.

      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.
      I was thinking more along the lines of converter source code maintenance rather than if it is doable or not, that's all.

      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 think the problem is still there unless one were to convert a specific VB module to a PB object. While this may be possible, I certainly don't think it is desirable as it changes the intent of the source code and that is an issue I do not wish to tackle. So we may be stuck with using GLOBAL variables for VB module level code for the time being, with a suitable warning, of course, that the use of GLOBAL variables in this particular instance is a bad PB programming practice and why.

      With regard to type identifier...
      It would be nice if the converter took care of this issue, but if it comes down to getting the converter out the door and into the users hands, or delaying the release to implement the replacement of type identifiers, I say get the product out the door. Type identifiers will still compile even under PB 9.0. Again, we should concentrate on those aspects of VB that will not work in PB under any circumstances.
      Later...

      JR

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

      Comment


      • #23
        I would like to skip PB 8 and just support VB2PB9. But, we started with 8 and there are some that won't upgrade. On the other hand, will new users to PB be able to get PB8 and will they want to?

        I believe PB 9 helps with a lot of issues. I don't have it so I am not sure, but:
        • Each Form because it's own PB class
        • Each class becomes a PB class
        • Global module code becomes just PB code module
        • A PB 9 shell runs the application


        This isolates code in a similar way VB does. Someone coming from the VB environment might find PB 9 easier than PB 8.

        Since I don't have it, I can't confirm this and as stated it will take time to understand the PB 9 changes.

        I think the converter being written in PB 9 isn't a problem. Supporting output in PB 8 and/or 9 is the question.

        Originally posted by John R. Heathcote View Post
        Rod,

        Developing the converter in PB 9.0 is a two edged sword. While I agree that it would be nice to take advantage of all the new and really cool features of PB 9.0 when converting old VB code, what about the user that doesn't have 9.0 yet? If all they have is PB 8.04 then all of the nifty VB to PB 9.0 conversions won't do them a bit of good. Not trying to be negative here, but just playing devils advocate.

        Comment


        • #24
          what is the user supposed to do if they do NOT have PBForms?
          We had already decided that PBForms was going to be a necessary ingredient to the job and possession of was required, at the same time that we decided to start with the PBForms handling the .frm files, It makes no sense not to take advantage of the amount of code already converted by PB itself.

          "WARNING - YOU NEED PBFORMS TO CONVERT YOUR VB FORMS TO PB!"
          Considering what the converter is going to cost them, it is not unreasonable, IMO.


          I also think that those with a lot of code to convert will recognize the savings in time that will offset the purchase price, not to mention what it does to the learning curve. PBForms has got many a programmer more comfortable with PB, whether they came from other languages or were just beginning.

          I think the converter should be developed with PB9.
          With regards to the output file being PB 8 or PB 9, I guess a user option that defaults to PB 9? This would mean a "|PB9|" in the terms so the converter could distinguish, and is readily doable.

          with a suitable warning, of course, that the use of GLOBAL variables in this particular instance is a bad PB programming practice and why.
          I don't understand why use of globals in this instance is bad PB programming practice, have I forgotten something? If the use of globals is the most secure way of getting the job done, why not?

          I say get the product out the door
          My sentiments. We could worry ourselves to death about things that mean nothing to the ultimate users of the converter.

          Again, we should concentrate on those aspects of VB that will not work in PB under any circumstances.
          If I may add to that, "that are quick and easy to convert for the first release."

          Once we get the vehicle moving, we can start mowing down obstacles.
          Rod
          I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

          Comment


          • #25
            Rod,

            It makes no sense not to take advantage of the amount of code already converted by PB itself.
            I tend to agree with you here, it makes no sense to reinvent the wheel, but we at least should warn the user that conversion "requires" PBForms. Perhaps this could be done during installation and possibly a warning message to the user every month or so.

            Considering what the converter is going to cost them, it is not unreasonable, IMO.
            It's not the cost that bothers me, its the fact that the converter may eventually be distributed from who knows where because it's been copied over and over, and when that happens things usually get left out in the distro.

            When the user attempts to run the converter it bombs, doesn't quite get the job done, which IMO leaves the new PB user worse off than he was before, because he now has a bunch of garbaged VB code with no where to go. And this will happen, unfortunately. I'm just suggesting that we need to give the user a point of departure, even if it is only a warning message, that they need to do X, Y, and Z to complete the process and this functionality should be part of the converter itself.

            I don't understand why use of globals in this instance is bad PB programming practice, have I forgotten something? If the use of globals is the most secure way of getting the job done, why not?
            The (over) use of globals can cause insidious bugs to creep into your application if you are not careful, and sometimes these bugs can be hard to track down because, theoretically, any procedure in your application can change the value of any global variable. There's no question GLOBAL variables will get the job done here, but every programming book I've ever read says you should keep GLOBALS to a bare minimum. And according to these same texts the over use of GLOBAL variables is one of many signs you have a potential design flaw in your application.

            I'm not saying that the user should not use GLOBAL variables under any circumstances. I use GLOBALS in my apps all the time, but I tend to keep their intended use very restrictive, such as a handle to a dialog box or windows control. I just don't want new PB users to get into the lazy habit of overusing GLOBAL variables to handle what should be essentially performed by a well designed software procedure/module.

            Perhaps I overstated my opposition to GLOBALS, how about a message that "suggests" to the new user to use LOCAL variables scoped to the procedure, passed as parameters if necessary, if and wherever possible, and save GLOBALS for system wide control, like AutoCAD system variables if you know what they are.

            I think the converter should be developed with PB9.
            I have no problem with that, the question is when can we get our copies and begin coding? Ordered mine yesterday and the e-mail PowerBasic sent me stated there would be a delay of at least 14 days due to the heavy demand for this new toy. I think Mr. Zale and company are doing everything they can to help allieviate the situation, but for right now we will just have to wait.

            Brian,

            I would like to skip PB 8 and just support VB2PB9. But, we started with 8 and there are some that won't upgrade.
            I think if we stick to the Level 1 conversions like we have talked about it will work for PB 8 and 9. Although the new commands, statements and functions in PB 9 look very promising it will take a bit of time to fully comprehend their true functionality, particularly when attempting to convert one programming language to another. I would prefer we all gain some experience with our new toys before we jump into the PB 9.0 waters with both feet.

            On the other hand, will new users to PB be able to get PB8 and will they want to?
            I think most folks who have posted in these forums will upgrade, so will other customers once they find out PB does objects at PB speed, that fact alone is worth the very modest price of the compiler, IMO.
            Later...

            JR

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

            Comment


            • #26
              Welcome back Brian.

              My perception:

              I think we're talking about 2 main issues here. The easy one is whether to use PB 9 for vb2pb itself. I would be willing to vote for a slight delay in release date, say 2 weeks, maybe 3, in order to take advantage of the new compiler. The only question is, can we all get a copy of the new compiler in time? If the answer to that is really 'no', then vb2pb v1 will have to be done in PB 8 by default.

              The second main issue is: Does vb2pb v1 do PB 8 or PB 9 or try to do both? PB Inc says it may be 2 weeks to actual v9 delivery for this community. I can only guess at how long it will take to get into the user community at large. Although the new compiler looks beautiful to me, I wonder about trying to support it before we're up to speed on it ourselves. I can't help thinking we should drive on aimed at v8.04 for now. Almost everything we have so far will work in both compilers as vb2pb code, if I read the manual right. I just don't have a feel for how much of the output could be easily upgraded to work in v9 with v2 of VB2PB.

              That said, I agree with Brian on supporting PB9 over PB8 with the caveat that release 1 won't be robust enough to support the advanced features of either.

              Other points in the discussion:

              John is correct when he says the vb2pb.exe will get out into the wild without it's documentation. This happened more often than not with my own shareware back in the day. Some sort of built-in warning about v1 limitations should be included. Perhaps a disclaimer with an Invitation to Contact the Team? That's just off the top of my head. :coffee3: I've got some space on my site that could be used as a distribution point if we can't set something up with PB Inc., someplace where users can go to see VB2PB specific info.

              Regarding PBForms:

              I've been working under assumption that it would be required for v1. John brings up a valid point about end user frustration. OTOH, it may be too late to change that decision for v1. I'm undecided, but leaning toward keeping the requirement for the first release only.

              Regarding DDT:

              Well, what can I say. I like DDT, and v9 looks great to me. It's certainly right to talk about including our own forms conversion module for release 2, even if PB Inc updates PBForms. Same arguments apply here as applied for including our own edit control. Since we haven't been planning in this direction I'm not sure there's time to do it all for release 1.

              Regarding GLOBALS:

              I have no problem with using GLOBALS (Remember GW where everything was global?), but it is easier to break code using globals from anywhere in the code. If we're still supporting VB2PB 2 years from now, that could become an issue as more programmers work on the source. My opinion is only where necessary and well documented.
              Do not go quiet into that good night,
              ... Rage, rage against the dark.

              Comment


              • #27
                John,
                I don't really think that we're all that far apart on the issue of Globals.
                There's no question GLOBAL variables will get the job done here, but every programming book I've ever read says you should keep GLOBALS to a bare minimum. And according to these same texts the over use of GLOBAL variables is one of many signs you have a potential design flaw in your application.
                When you think about it, anything with Global scope can be misused, including %EQUATES. (ie. using the wrong equate at the inopportune time.) But these same books don't mention this particular item that can cause freaky hard to find errors in source code. (I been down that road, and let me tell you, it's not just a day trip.)

                IMO those authors that call the use of Globals a bad programming practice are either reciting rhetoric or bad programmers, hence they become authors. Globals are a tool, like all the tools, to be used when appropriate.

                That said, trying to keep as many variables Local in scope for this project is decidedly the wise way to go, since neither we as the builders, nor PB as the compiler can possibly know the original programmer's bent.

                I think if we stick to the Level 1 conversions like we have talked about it will work for PB 8 and 9.
                Good point. In fact the upcoming PB 9 shouldn't hold us back at all.
                Rod
                I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

                Comment


                • #28
                  Rod,

                  When you think about it, anything with Global scope can be misused, including %EQUATES. (ie. using the wrong equate at the inopportune time.) But these same books don't mention this particular item that can cause freaky hard to find errors in source code. (I been down that road, and let me tell you, it's not just a day trip.)
                  So true, so true, and just so you know, I've been down that road too. You're right, it's not a fun journey to take.

                  Globals are a tool, like all the tools, to be used when appropriate.
                  I agree. I guess what I was trying to say is we shouldn't give the end user the impression (or encourage, if you prefer?) that all problems can be solved with liberal use of GLOBAL variables when they use our converter. The new user must understand the use of GLOBAL variables within the conversion process is the only practical way to convert certain sections of VB to PB. Obviously this could be explained in the documentation, as well as online informational messages to the user.

                  The real issue here is what is the level of programming experience does the new PB user have? Since they are new to PB that experience level would be close to 25 on a scale of 1 to 100. OTOH I've met plenty of supposedly good VB programmers, just ask them, who were not all that great practicing their craft and this lack of talent transfers over to PB. While I think most VB programmers can quickly grasp PB concepts (Stan is a good example) you will always find those who will unfairly judge PB by what the converter does, or doesn't do. I would hate for Mr. Zale to lose customers and potential sales because of something I did.

                  Having said all of this, I would tend to agree with you Rod that we are probably pretty close to agreement on GLOBALs. I think I've beat this horse senseless, next topic please.

                  BTW, it's refreshing that you folks have thick skins, and because of that, it makes giving opinions (rants?) that much easier for me. I'm very appreciative that you don't take what I say personally. I found in my career at CDOT that most folks did not speak up, and if you spoke up management always took what you said personally, consequently a lot of bad decisions and policies were implemented because nobody said anything to the contrary. So that is why I speak my mind, get the idea on the table, generate the discussion, and if I get voted down, well that's ok with me too. You win some, you lose some.
                  Later...

                  JR

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

                  Comment


                  • #29
                    I don't know that I'm thick skinned, but I have been told I'm thick headed.

                    I echo Stan's comment a few posts ago. I'm glad you've joined the crew.

                    You're last paragraph shows that you possess a much deeper appreciation of working with others than some that have passed through. And some wit too. One of the handy tools for survival.

                    Incidentally, when I write my book, I want you to forget my earlier comments on authors.

                    On a slightly different note, just as an interesting test of the content(quantity) in this forum, one five page(forum) thread turned into a thread of 73 printed pages. This the result of expanded code boxes of course.

                    We have written a lot, and perusing the full forum yields some real gems, and I think we've forgotten things we had earlier established. Or accepted that what we established had to be set aside in the interest of progress. Globals were not the only thing that have been beaten.

                    With regard to the documentation of the converter, two things: Is the converter going to be released as source code/compiled code/documentation?
                    or as compiled code/documentation?
                    I think most users would transfer the original zip package containing whatever we put into it. We don't want to go the nag screen route, I'm sure.
                    I think feedback from version one will help by showing us what we need to change, add, or accommodate, and we will manage a more user friendly version 2 I'm sure.

                    Since this is likely my last post until Monday, good weekend all.
                    Rod
                    I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

                    Comment

                    Working...
                    X