Announcement

Collapse
No announcement yet.

VB to PB

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

  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Chris Boss
    replied
    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 !



    ------------------

    Leave a comment:


  • Andy Anderson
    replied

    Chris,

    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.

    Andy


    ------------------

    Leave a comment:


  • Mike Doty
    replied
    Chris,
    IMO, OCX support is required to compare to VB.



    ------------------

    Leave a comment:


  • Chris Boss
    replied
    Andy;

    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
    two.

    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.



    ------------------

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Andy

    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?

    Thanks,

    Jason

    ------------------

    Leave a comment:


  • Andy Anderson
    replied

    Chris,

    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
    resolutions.

    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.


    Andy

    ------------------

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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!

    ------------------
    Vikki

    Leave a comment:


  • Wayne Diamond
    replied
    Vikki, you want warm fuzzies? Compile this program in VB:
    Code:
    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:
    Code:
    #COMPILE EXE "hellopb.exe"
    FUNCTION PBMAIN() AS LONG
     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,
    Wayne



    ------------------

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Chris,

    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.

    Regards,

    Jason

    ------------------

    Leave a comment:


  • Chris Boss
    replied
    Andy;

    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):

    Code:
                                     (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
       Engine  
    
    SubClassing         No          Built In      Built In
       Engine
    
    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
    Control
    
    Drag Handles        No          No            12 KB DLL
    Control
    
    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).




    ------------------

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by Wayne Diamond:
    i still get those warm fuzzies
    Best of luck,
    Wayne


    Wayne,

    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*.


    ------------------
    Vikki

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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. )

    Thanks,



    ------------------
    Vikki

    Leave a comment:


  • Andy Anderson
    replied

    Wayne,

    I'm inclined (with qualifications) to agree with your analysis
    of PB vs VB. DDT is excellent for creating small dialogs but
    at this point, I don't consider it convenient for large scale
    GUI bound apps. Chris's stuff looks pretty good and is closer
    to being a good starting point if you are coming over from VB
    but I feel it needs a few more features to make it viable as
    a general GUI tool.

    There are other offerings such as Hutch's and Ed Turner's tools
    but they are SDK style and require a working API knowledge base.

    Despite its' bloat, lack of speed, bugginess and dependencies,
    VB is still the easiest way to create a robust GUI. It is this
    factor that is solely responsible for its' popularity.

    PB fits very well as the processing engine compliment to VB. You
    can code a general dll containing all the neat functions that VB
    doesn't have and use it with a VB user interface. For programs
    that crunch data, you SHELL/CALL from VB to straight PB for the
    processing. It's not a bad set up. (g)

    As far as VB7, we're definately not going there. We're still using
    VB5 and will do so till 64 bits becomes dominant. By that time, we
    figure DDT will be refined enough for general GUI work and we can
    drop VB entirely.

    As an aside, Eric Pearson has done some marvelous work intermingling the console with graphics. If future versions of Windows support a more consistant console, that route would be worth considering.


    Andy Anderson
    THREE Systems


    ------------------

    Leave a comment:


  • Chris Boss
    replied
    Vikki;

    I think you will be amazed at what EZGUI 1.0 can do in such a small
    package. Also I agree with some of Steves sentiments in that EZGUI
    is a good starting point, then you can progressively learn DDT and
    then later learn pure SDK style coding (API).

    EZGUI "encourages" this approach, since it allows easy "integration"
    of API functionality in an EZGUI app, so you can "experiment" with
    API concepts. The Freeware Visual Designer uses the same file format
    for Forms, so some of your smaller apps that don't require all the
    functionality can be coded in DDT. Simply use the Forms created
    in the EZGUI Visual Designer, load them into the Freeware Designer
    and then generate pure DDT code (with no need of a runtime).

    Both tools help you learn more about how Windows really works which
    prepares you for the last step, of writing pure SDK style apps.

    The fact that using PB DLL 6.0 allows "all three" techniques for
    writing an app is a real plus. VB doesn't offer a lower level
    of programming without runtimes.

    Also EZGUI 2.0 (Beta) is already in development and it will add functionality
    not even found in VB. Things like WinLift support, Improved Visual
    Design engine, autoscaling Forms/controls, Turtle Graphics control,
    Drag Handle control, Rich Edit control, Drag List boxes and more.

    EZGUI was written using PB DLL (5/6) and could never have
    been created without it !



    ------------------

    Leave a comment:


  • Wayne Diamond
    replied
    Steve,
    VB7, VC# (VC sharp), and VC++ will all share the same single common runtime library (as opposed to msvbvm60.dll for VB6, msvcrt for VC++ , etc), and yes it can compile exe's, so i don't think VB coders will at all be left in the dark as you put it. If anything, i think it moves VB coders closer to VC++ and C# coders, as there will be a lot of 'intertwining' between the languages, a lot more so than there is already. The .net **** means nothing to me, and it's release is no reason to get rid of VB6, so ... she'll be right
    By the way, im certain that I read that you can even create - wait for it - console applications with VB7. Cool huh? (Still needs the runtime though, ******!). Also, VB7 brings polymorphism and "true" object-orientism[tm], so things are looking up
    I look forward to adding VB7 to my compiler arsenal, but somehow I think I'll still be using VB6 more than VB7
    Either way, i dont think PB can ever replace VB, and I dont think VB can ever replace PB - they've both got big places in my heart! <grin>

    Best regards,
    Wayne


    ------------------
    *** Edited by Administrator

    Leave a comment:


  • Steve Hutchesson
    replied
    Vikki,

    I think in the longer term that shifting to PowerBASIC will work for you
    in that it gives you a number of ways of coding. Chris has a well accepted
    package in EZGUI that makes the shift a lot easier.

    You have the option later of using DDT style coding which will give you a
    lot of power and when you have been at it for a while, you will find
    writing pure API style code starts to become a lot easier.

    As I understand, the next version of VB will be .NET based so VB as it is
    known now will probably cease to exist which leaves programmers who want
    to write general purpose binary programs out in the cold. PowerBASIC are
    specialised high performance compilers which have a "sky is the limit"
    approach and you have a reasonably flexible range of how you write code.

    Shifting to procedural code is a bit of a change but with the tools and
    toys available, its not as hard as it used to be if you had to jump into
    windows in C like it was in 16 bit windows.

    You are welcome to have a play with the code generating tools on my site
    but they are pure API style code and may be a bit unfamiliar if you don't
    have a background in API code at the moment but its worth noting that
    working directly in Windows API calls is a lot easier in a true compiler
    than it was in VB as they are just system functions that you use naturally
    in PowerBASIC.
    http://www.pbq.com.au/home/hutch/pbdll50.htm

    Regards,

    [email protected]

    ------------------

    Leave a comment:


  • Wayne Diamond
    replied
    Vikki, PB/CC and PB/DLL have to be my two best purchases this year - i still get those warm fuzzies when I compile tiny, tight, strong standalone apps in PB - it has added a whole new dimension to my programming, and regardless of which you choose I know you will be satisfied!
    Best of luck,
    Wayne


    ------------------

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Hi Chris,

    Yep I went back and saw the differences. I started to order PB but it does not appear they use a secure server. I had my cc info was stolen online last year when purchasing software on a non-secure server so I'll call them tomorrow to order PB and I think I have pretty much decided to purchase EZGUI so I'll be doing that in just a few minutes.

    Looks like just the ticket for me right now.

    I'll learn DDT because I should but for now I'll go with EZGUI.

    ------------------
    Vikki

    Leave a comment:


  • Chris Boss
    replied
    Vikki;

    Just to make sure one point is clear :

    The Freeware DDT Visual Designer we offer is not the same thing
    as EZGUI. It is for those who can handle the API and who prefer
    DDT. (Yes, that is free).

    EZGUI on the other hand is a commercial (it costs something)
    GUI engine that allows you to build PB apps without using a
    single API function call. You do "not" have to understand a
    single API function to use EZGUI. EZGUI 1.0 is a 122 KB runtime
    DLL
    that you must ship with your PB app (royalty free).
    EZGUI 1.0 comes with its "own" Visual Designer !

    To appreciate how powerful EZGUI 1.0 is :

    Both the EZGUI Visual Designer and the Freeware DDT Visual
    Designer are themselves EZGUI apps !


    Both Visual Designers are 100% EZGUI apps which use absolutely
    "NO" API function calls at all. They only use EZGUI functions.



    ------------------

    Leave a comment:

Working...
X