No announcement yet.

VB to PB

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Hi Steve,

    I'll be checking those out. I've just purchased PB/DLL and EZGUI.

    I visited your site and and I'll definitely be downloading some of your offerings to help me to learn.

    My first computer programs were built with Clarion for DOS(BW - before windows) and I loved it. Then Windows came along and scared me enough that I put programming aside for awhile.

    Clarion for DOS was in a way similar to VB in that you could draw your GUI add a couple of functions and have a running app in no time. You built code in modules that connected to each other. It was great and the apps would run on Windows 3.1 but really weren't meant to.

    At any rate I finally decided to try again and VB seemed like the choice. I did get VS Enterprise with the intention of learning C++ and I still intend to do that ... a little at a time.

    I'm not afraid to learn(and love learning) as much as I am afraid to muck up an end users system by adding a bunch of stuff to their system folder. Hence, working all that time on the app I currently have only to realize I just don't feel good about distributing all the garbage that has to go with it. I didn't walk into VB not knowing about dependencies. I did however walk into VB thinking the dependencies would be a *non consequence*. Not something that would be prohibitive. The problem is that you really have to build a full app before you can really appreciate the consequences of dependencies.

    I think I've found a home with PB and I'll know more about that after I've received my copy and started working with it and EZGUI. Today is going to be an exciting day! After that it's on to learning how to do it all by hand. I'll probably most always use a tool like EZGUI if it's practical but just as with anything else, you can't really be proficient unless you know what goes on behind the scenes and know what to fix when it gets broken. )




    • #22
      Originally posted by Wayne Diamond:
      i still get those warm fuzzies
      Best of luck,


      I am seriously looking forward to getting rid of the deep sinking feeling in the pit of my stomach when I compile the dependencies in my VB apps, and instead getting that *warm fuzzy feeling*.



      • #23

        While, EZGUI 1.0 has a way to go to compete with VB, EZGUI 2.0
        (in Beta) (and PB of course) will give VB a "run for its money" !

        EZGUI 1.0 has the following advantages over VB ( I have VB 5.0):

                                         (with PowerBasic of course)
                           VB 5.0       EZGUI 1.0     EZGUI 2.0 (Beta)
        Runtime            1.3 Meg      122 KB        <170 KB
        Common Dialogs     137 KB OCX   Built In      Built In
        Some Common Ctrls  598 KB OCX   Built In      Built In
        UpDown, Tab Ctrl)
        (Toolbar, Prg. Bar)
        Visual Design       No          Built In      Built In
        SubClassing         No          Built In      Built In
        Registry Access     Use API(?)  Built In      Built In
        Layers Feature      No          Built In      Built In
        Rich Text Ctrl.     200 KB OCX   Use API      Built In
        Turtle Graphics     No          No            35 KB DLL
        Drag Handles        No          No            12 KB DLL
        Single User        Jet Runtime  No            32 KB DLL (Btree/Flat File)
        Database            1 Meg.                    Handles Huge databases
                            (Better but               (High Speed Flat File
                             bigger)                   search or Btree search)
        Now of course VB has a lot of advantages, but slowly EZGUI is
        becoming a "real" alternative to VB. I am developing EZGUI so
        VB won't be needed anymore (I don't need it).

        Chris Boss
        Computer Workshop
        Developer of "EZGUI"


        • #24

          I am developing EZGUI so VB won't be needed anymore (I don't need it).
          Where is COM+ support? I know you've mentioned that in the NGs here before, but w/o that I think it'll still be missing something that most VBers will want.

          Also, a couple of clarifications. VB 5.0 doesn't have a subclassing engine, but you can easily subclass in VB5 and VB6 with the AddressOf operator. Also, you don't have to use the common dialog control in VB. I always use the APIs - they're easier and you don't have to include an OCX.





          • #25
            Vikki, you want warm fuzzies? Compile this program in VB:
            Private Sub Form_Load()
            MsgBox "Hello VB world and all your runtimes!"
            End Sub
            That compiles to 16,384 bytes, and requires the 1+mb worth of VB runtimes

            Now, compile this program in PB\DLL:
            #COMPILE EXE "hellopb.exe"
             MSGBOX "Hello tiny small compact powerful compiled world!"
            END FUNCTION
            That compiles to 5,120 bytes, and requires _no_ other files. Now that is a beautiful thing!!!
            But the most impressive thing - it can even make simpleton BASIC programmers like me people like me produce very-well-compiled programs basically as if we were professionals! <grin> Ive had PB\DLL and PB\CC for about 4 months now, and I still get warm fuzzies all over when I compile. I only know BASIC - I sometimes feel that I have NO RIGHT to compile such small executables, but thanks to Bob Zale and the PowerBASIC team, there's a whole new dimension of fresh air in my programming
            Anyway that's enough warm fuzziness, im starting to melt

            Anyway Vikki welcome to 'the family' and Merry Christmas to you

            Best regards,



            • #26
              The famous "Hello World".

              I just received PB/DLL and am reading through the docs. All the worry is gone. This is not going to be hard at all considering I'm understanding everything the docs are telling me so far. *G*

              I have *warm fuzzy feelings* already and I haven't even opened PB/DLL yet.

              This is going to be terrific! As a matter of fact, from reading the docs it looks like I'm not going to have much trouble porting my VB app over to PB in a fairly short period of time. I'll only know that for sure of course once I start to work on it.

              Gotta read the docs first, gotta read the docs first, gotta read the docs first. Have to keep telling myself that.

              Ok as you know, I've gotta finish reading the docs now.

              Thanks for the welcome and Merry Christmas to you too!



              • #27


                Now that I have your attention........(G)

                The popularity of VB is a testimony to the fact that
                CONVENIENCE is a primary consideration to developers. There
                are trade offs, of course, and VB's are excessive which
                is why we went to PB in the first place. Indeed, even the
                popularity of PB is, in part, due to the convenience of the
                many functions it has that VB doesn't.

                As far as EZGUI goes, a parsimonious (<= 1/2 meg) and fast
                runtime is just fine with me since it keeps my code from
                being obscured with a slew of API calls which inevitably
                leads to redundancy and errors that are hard to find.
                SDKers would argue this last observation. (G)

                But based on the information supplied at your site:

                1. I would like to see more event trapping, particularly:
                Load, Unload, KeyDown. Yes, it can be done now, but not in
                a straight forward fashion.

                2. The text states that your graphics unit is based upon a
                fixed 8 by 16 pixels. This makes it inconvenient to adjust
                for large or custom font settings and different monitor

                3. The text lists Font as a property for controls but doesn't
                mention font size. There should also be a function to retrieve
                font size as a method for adjusting controls.

                I will admit that I am speaking out of turn since I haven't
                test driven your product but these are a few things that
                occurred to me when I read your write up.

                All the same, I really think you're on the right track to get
                a lot of business, particularly, with the horror stories I've
                heard about VB7.




                • #28

                  All the same, I really think you're on the right track to get
                  a lot of business, particularly, with the horror stories I've
                  heard about VB7.
                  What horror stories have you heard?





                  • #29

                    EZGUI 2.0 (Beta) does "Autoscaling" of the Forms/Controls/Fonts
                    based on the end users system wide Font setting (small fonts/large fonts).

                    If the font setting is small fonts, then a character size will be
                    8 x 16 (like EZGUI 1.0) which the size of the System font. If the
                    font setting is large fonts the character size will automatically
                    be bigger.

                    EZGUI 1.0 (and 2.0) allows you to "set" the Font and its Size and
                    attributes (bold, italics). EZGUI doesn't support properties, so
                    it can't read back those values, but those values can easily be stored
                    in global variables.

                    EZGUI "is" Event oriented, but it is "not" Property oriented.

                    I am hoping COM support will be added by PowerBasic in its next
                    release and since their is already some Third Party COM support
                    (JazzAge I believe), there is no reason why it couldn't be used
                    with EZGUI.

                    EZGUI provides low level hooks into itself, so all sorts of stuff
                    can be done, that may not have been anticipated when I developed it.

                    You can hook into the Main Message Loop, the Main Dialog Procedure
                    and can subclass most controls.

                    EZGUI encourages the "integration" of API code with itself. You
                    don't need it normally, but it necessary it is easy to combine the

                    A perfect example of Integration features, is the new WinLift support
                    in EZGUI 2.0 (Beta). EZGUI 1.0 couldn't handle WinLift.

                    Yes, I think some low level keyboard events are important and likely
                    that will be added. Remember, EZGUI 1.0 is only a first generation
                    product. EZGUI 2.0 is taking big leaps forward.

                    Chris Boss
                    Computer Workshop
                    Developer of "EZGUI"


                    • #30
                      IMO, OCX support is required to compare to VB.



                      • #31


                        Have you not noticed that whenever you post, people
                        comment on what you need to do ?

                        Maybe it's because a lot of us think that you are doing
                        something that we will ultimately want.

                        Contrary to esoteric purists, screw dependencies. Windows is
                        a system of mutual dependencies. Have you ever put a program
                        like DEPENDS on a PBDLL prog ? Plenty of dependencies !

                        The real question is whether the dependency accomplishes for
                        the user more than it extracts. A good and fast DLL that does
                        what you want is worth its' weight in platinum.

                        Keep at it.




                        • #32
                          While, I do agree that OCX support is "important", I think it is
                          prudent to "wait" and see what PowerBasic does. COM support is
                          really something that should be handled at the compiler level.
                          The code would be much cleaner if COM was part of the Basic language.

                          Likely, COM support in EZGUI will wait for PB 7.0. PowerBasic must have
                          a few "tricks" up their sleeves to show us with PB 7. I am just
                          anxious to see what they give us.

                          COM is not easy to impliment. I "have" taken a serious look at COM
                          and I still can't grasp it fully yet. I could add a hundred new features
                          to EZGUI 2.0, in the time it would take me to master COM.

                          While, COM "may" be necessary, it is not necessarily the best way
                          to add new functionality to a compiler. IMO, MS depends too much on
                          COM and COM is just a bunch of extra overhead between your app and
                          components. There is a component model that is greatly overlooked,
                          and yet is at the core of windows (even COM) and that is DLL's.

                          Modern compilers have deviated from the use of DLL's in favor of
                          COM, while DLL's are still the fastest, easiest, smallest component
                          model. Yes, DLLs are not property oriented, but neither is windows
                          at its core. While Windows supports properties, properties add
                          extra overhead, since they require lookup tables to find them. Windows
                          as far back as 3.1, had a cleaner model for storing window specific
                          data, which is the extra bytes for a window class and window
                          instance specific data. The GetWindowLong/SetWindowLong functions
                          are used to deal with that data. Each window has its own message set
                          (%WM_USER+ something) where you simply send a window a message and it
                          returns data (or sets data). The SendMessage function is at the "core"
                          of how windows works.

                          COM is just a wrapper, that uses slow properties which either
                          accesses data in Windows properties or makes a SendMessage call to
                          the window to get the data.

                          COM is "bloated" and requires Registry access (which Microsoft
                          now regrets, since the registry is getting bloated and now they
                          are encouraging us to store data in INI files again).

                          As an example :

                          The Common Dialog code in EZGUI calls directly into the Common Dialog DLL.
                          It probably comes out to about 5 to 10 KB of compiled code .

                          In Windows 3.1 the Common Dialog VBX, which called the Common Dialog
                          DLL is only about 19 KB.

                          In 32 bit windows, the Common Dialog OCX, which calls the Common Dialog
                          DLL is 137 KB !

                          Whats all the extra code for ?

                          It sure doesn't make the Common Dialogs better !

                          The EZGUI Common Dialog commands are single functions that "anybody"
                          can use (easy), so what am I getting for the extra 120 KB in
                          Microsofts OCX ?

                          It sure isn't ease of use, since even their properties Dialogs for
                          the Common Dialogs in VB aren't more user friendly than my
                          EZGUI function counterparts.

                          Simply, put, we aren't needing COM because it is better, but we
                          are needing COM because thats what everyone else is using and we
                          are "stuck" with COM.

                          VB programmers must use COM, because if they didn't have all those COM
                          components they would be lost.

                          As the number of alternative PB tools (DLLs) increase we will have
                          less and less need for COM. What PB programers will benefit most from
                          is better tools for building better tools for PB.

                          In the time it would take me to add COM support to EZGUI, I could
                          build dozens of useful components in DLL form (as controls).

                          Since, there already is a Third Party tool for using COM with PB
                          , why reinvent the wheel. If you must use COM, you can !

                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"


                          • #33
                            This thread is getting a bit long, and it appears to have diverged into three or four different topics. Please feel free to start new threads which address the issues you're interested in. This thread is now closed.

                            Tom Hanlin
                            PowerBASIC Staff