VB to PB

[Tom Hanlin]

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

[Chris Boss]

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 !



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

[Andy Anderson]

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


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

[Mike Doty]

Chris,
IMO, OCX support is required to compare to VB.



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

[Chris Boss]

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.



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

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

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

[Andy Anderson]

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

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

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

[Wayne Diamond]

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"
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



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

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

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

[Chris Boss]

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

                                 (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).




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

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

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

[Andy Anderson]

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


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

[Chris Boss]

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 !


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

[Wayne Diamond]

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

[Steve Hutchesson]

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]

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

[Wayne Diamond]

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


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

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

[Chris Boss]

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.



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