Announcement

**Chris Boss** · 14 Feb 2000, 08:48 PM

Sticking to the "Visual Design" part of the previous thread, I think that PBs compiler is beginning to be noticed more and more by those who use Microsoft products now. The problem is the steep learning curve of the API and the lack of Visual Design tools (Dialog editors don't cut it for VB programmers).

By now, most everyone has heard of EZGUI and I don't want to turn this thread into an EZGUI sales pitch. But I have learned a few things during the last few weeks, since I released EZGUI.

My concept of Visual Design is based on the Visual Basic programmers perspective. Nobody can avoid the honest truth that VB is the best example of easy to use Visual Design. The questions are:

(1) Should VB be emulated in PB (or addons) ?

(2) Is the VB market important ?

My answer to question 1 is "partially", but not exactly.

My answer to question 2 is "absolutely" !

C programmers have had many of the benefits of PB (in their own language of course) for years, since C is one of the more optimized compilers. It is closer to the API than VB is as well.

It is Basic programmers, that have been overly shielded from the API and have been taught for years, "yes, your language is the easiest to use, but be satisfied with easy without power"

The PowerBasic compiler now allows Basic programmers to have power which rivals C. But the cost is the lack of ease VB programmers have been accustomed to.

Visual Design and simplifying using the API are crucial to getting a large number of VB programmers to seriously consider switching to PB. PB has been considered a VB addon for too long (implied by its name DLL compiler) and now should come forward and stand on its own as a "full blown" Windows compiler (VB not needed!).

The next question is, "is this really practical" ?

The answer is YES !

One of the things I did when Beta testing EZGUI, was to use Beta testers who had absolutely NO knowledge of the API (and didn't want to learn it) and I made sure I had my share of VB programmers in the bunch. A few of these VB programmers are not just "moonlighters", but they are programmers who develop serious realworld applications in VB. I also added one very good API (and assembler) programmer to the mix, just to cover all my bases.

Now that I have been selling EZGUI (and yes, we have sold quite a few), I am now getting feedback from our customers, some who are serious VB programmers.

While, initially the few quirks of my Visual Designer (remember it is only the first generation) were the first things noticed by those who use VB and they were quick to point these out, I noticed that as they use EZGUI more (and of course the PB compilers), they slowly began to enjoy it. What is noticed first is the Power of their apps in such a small footprint.

Think about it ! VB programmers actually seriously converting their VB apps to PB (using EZGUI in this case). The idea of VB programmers, not using PB as an addon, but actually converting their apps to PB code (remember, even EZGUI is a PB app itself).

I think to help VB programmers make the transition to PB, we need to meet them half way. No, we don't want to make PB a VB look alike. We don't need a Visual Designer that exactly emulates VB. What we do need though is "better" Visual Design that will allow VB programmers to actually build PB apps, almost as easily as they did with VB. RAD tools, especially Visual Design, are absolutely needed for VB programmers moving towards PB.

There are three groups of programmers in (and also coming into) the PB ranks (IMO).

(1) Multilanguage programmers who know either Assembler, C or Pascal, besides basic (and VB).

(2) DOS Basic programmers who don't know any other language very well.

(3) Visual Basic programmers, who know only Basic (DOS and now VB).

Group one tends to love SDK style coding.

Group two finds DDT much easier than SDK style code.

Group three needs more ! Much more !

They need Visual Design !

The concept of "Resource" editors is actually foreign to many VB programmers. They think in terms of Forms, controls, properties, methods. VB automatically embeds resources, so why would a VB programmer even need to understand what resources are and how to use a Resource editor. Multilanguage programmser on the other hand fully understand what Resources are and can't understand why they are so foreign to a VB programmer.

IMO, I think that there should be "many" different Visual Design models created, to satisfy the needs of specific groups of programmers. I think someone should build a real Visual Designer for DDT (that can also create SDK style code that a few us like). There is no need to put it in resource form (not with DDT now), unless you want to use the Dialog functions in the API.

But I also think that for other groups of programmers, there is a need for something "closer" to the ease of use found in VB. We have to meet them half way. The offer of Power alone is not enough for most VB programmers. They want RAD and good RAD. They want colors. They want fonts. They want to see their Bitmaps and icons. They want easier terms for control styles, than the API constants. They want events. They want a lot and we need to give them at least some of what they want.

Visual Design is much like Pizza. We all like Pizza, but want different toppings (I like Pepperoni). Visual Designers need to come in different flavors.

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

**Siamack Yousofi** · 15 Feb 2000, 01:11 AM

The real challenge for PB is survival in the market place. Powerbasic in its Turbo Basic form was the leader in its class. Bob Zale did the right thing to avoid competing head-on with Microsoft and VB. By creating PB/DLL he managed to exploit the VB shortcomings and sell his product into VB space without going into a commercial war that even IBM lost (OS/2).

We all know that no VB programmer must live without PB/DLL. A lot of VB programmers spend 10 times the cost of PB/DLL on VBX junk. With the right marketing pitch it should be easier to sell them PB/DLL as an add-on than persuading them to abandon VB.

So the question is wether it is more profitable to sell a copy of PB/DLL to each of the 5 million VB users by staying on the current course or persuading say 1 million of them to give up VB altogether by transforming PB into a VB look-alike?

After all this is not a charity. Bob is in it for the money too. And in my opinion he is among the few in this industry who deserves every penny he has made so far (present company excepted of course

).

IMHO, VB interface with PB power is a pipe dream. You cannot have both without compromising a bit here and bit there. Any middle ground solution is neither VB nor PB and will die a commercial death.

Delphi is the closest anyone has been to this dream and -guess what- Inprise and Corel have just merged and are going to concentrate on Linux, which means they have accepted defeat in the war with Microsoft.

Siamack

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

[This message has been edited by Siamack Yousofi (edited February 15, 2000).]

**Siamack Yousofi** · 15 Feb 2000, 01:18 AM

Sorry for duplicate posting please delete...

[This message has been edited by Siamack Yousofi (edited February 15, 2000).]

**Michael Meeks** · 15 Feb 2000, 12:49 PM

Okay......I'm gonna say it!

First - things - first.

I am a true fan of PowerBasic, ever since the beginning! And to this day, recommend it over all other programming tools for clients and peers. I almost never have a problem with PowerBasic, except for some unanswered questions with PTree.

PowerBasic has missed the boat! Everything we are wishing for and wanting from PBDLL, could have been done and more! The lack of motivation from managers of PowerBasic is why we are current at our present state of wishing and wanting more. The lights should have come on when Visual Basic went from VB5 to VB6.

PowerBasic never the saw the light!

PowerBasic could have had over a (1) Million Client base, if they had a vision for the future.

I don't know what PowerBasic would have looked like, but if I was the one making the choice, regardless of cost, it would have slammed head on with Visual Basic in full force, with a Visual Designer, add ons, ect., and as a complete package that would rival the Programming World.

We can dream all we want, but whose gonna take us to the promise land?

Sorry Dave,
No disrespect intended! I will always support PowerBasic.
Just felt like speaking my mind!

mwm

------------------
mwm

**Chris Boss** · 15 Feb 2000, 02:27 PM

IMO I think PowerBasic has done a good job , even if I may have to "wish" a lot for features.

I would say that few of us really understand "how much" is under the hood of the PB compilers. Also, while it is easy to wish for features, we should realize that their implimentation is never easy.

Microsoft has a slight advantage over PowerBasic (besides their deep pockets to spend money on R&D), such as "they wrote Windows" and better understand how it works than anybody else. They also have greater resources. They are a "Big Fish" compared to others.

Also, PowerBasic can't afford to put a lot of R&D into a concept and then have it go bust. They have to do it right the first time. Microsoft can afford to ship a bunch of "Service Packs" when they do it wrong. For some reason, programmers "tolerate" this (I don't know why).

Moving into Visual Design is not as easy as it looks (if you want to do it right). I ought to know, since I developed EZGUI which is the first commercial Visual Designer released specifically for PB. The hardest thing about creating EZGUI is how do you keep the overhead to the engine down while offering more features.

The truth is that only 100% SDK style code will get optimum speed. Every time you add a feature to make things easier, you add more overhead that uses more CPU cycles. While this is inevitable (there has to be a give and take), it requires a lot more optimization that you may think.

PB doesn't want to make the same mistakes as MS did with VB.

I think PB gets the picture that Visual Design is the next step. I don't think they would have put so much effort into DDT, if they didn't. Likely DDT is a foundation for future steps.

It is good to hear that PowerBasic is "Moving forward" in expansion. They even advertised for more programmers (and others) on this web site. This is good.

PB is more likely to seriously consider our wishes for new features, if we support them and say "Please".

So back to the reason for this thread:

What do we want in a Visual Designer for PB ?

Lets stick to the question.

Do we want a VB like environment ?

Do we want something more like Delphi (generates code for forms) ?

Do we want OOP added ?

Do we want to be able to add code to "Events" directly in a Visual Designer ?

Do we want DDT code generated ?

Do we want SDK style code generated ?

Do we want the Visual Designer integrated with the IDE ?

What kind of "components" do we want for custom controls ?

ActiveX ?

A component unique to PB (like Delph does - VCLs) ?

Do we want the Visual Designer to support properties ?

Lots of questions !

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

**Jeffrey R. Radue** · 15 Feb 2000, 03:52 PM

There has been alot of discussion on this topic, but I'm not sure if we are accomplishing anything. Here is what I would like to see in a PB editor:

1. Provide a good integrated dialog and form editor which allows easier placement of controls and will generate event functions. The editor could and should generate standard windows api code and/or DDT. James Fuller has already created an excellent little program RC2DDT which does this quite well using standard resource files.

2. The problem with using DDT is that it is not well documented. I would like a comprehensive reference of the message functions which can be called and controls that can be created. It is very frustrating trying to use a CONTROL SEND or SendMessage function when you have no idea what the functions are expecting for the Wparam and lparam values. I have search MSDN for a reference, but didn't find one.

3. VB is great at creating forms. However, if you had to create a window using API functions, and have only programmed in VB, then you would certainly be lost. I think any editor for PB should generate skeleton source code that the user can finish. If you look at VB, you can click on a control and the event function comes up in a window for editing. You can't tell me that it would be hard to make PB/DLL do this. This is not asking for a complete rewrite of the compiler, just a tool for generating and organizing painful code more easily.

4. There should be no add-on products if possible. I am sick to death of distributing OCX files by third party people. You may be able to create a program quickly using them, but if have problems with them, you are basically powerless to assist users of your program because you didn't write the code. You may end up generating 10 times more source code for a large program with all the forms and controls, but who cares! I think having total control of your software is more important.

A final comment, I also think that PB has missed the boat somewhat. They have a product that could grab a significant market share if they had a complete development environment. They even have the advantage of knowing what not to do by looking at VB.

Thanks for listening,

Jeff

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

**Francis Beaulieu** · 15 Feb 2000, 06:46 PM

Ho Steve,

Take care to say anything... about something that you dont know.

Again Steve I tell you today that I can make more than very fast code with the my "Visual Garbage", I can beleive that you compare OOP with the very very poor old basic technic programming of PB! It is like compare old film movie camera with the new hi-tech 8MM or VHS-C that we have today... Have you ever try to use Object Oriented programming??

I can compare VB/VC/IDE, Class, ActiveX, dim with events, collections, object instancing and implementing.

I haven't invent object orienting, but you can be sure that you cannot do the same thing with PB as you can do with VB!

For exemple, I have made an Agenda ActiveX (Outlook style) with VB last time... I past to whole days to make it first in PB but that was a nitemare! I have made it in 2 days in VB... Don't search the difference always in the speed, search what you can do with the tool too!!

Thats my opinion and I share it!

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

**Steve Hutchesson** · 15 Feb 2000, 08:38 PM

Francis,

Its always a pleasure to hear from you and as usual, I find what you have
to say interesting but I am willing to draw the distinction between good
and bad code on the basis of its speed and size.

There is no doubt that VB and PB are different animals that have overlapping
capacities but in terms of size and speed, the comparison is that between
a bullet and a balloon, you can hang a lot of fancy interface components
on a ballon but you can never make it perform like a bullet and this is
why Visual Basic programmers come to PowerBASIC looking for performance,
not the other way round.

Do PowerBASIC programmers come to Visual Basic looking for fast file IO,
very high speed data processing, Intel assembler built in, minimum size
API code, minimum size DLLs etc.... No, they already have it with
PowerBASIC. What Visual Basic does that PB does not normally do is
interface with the proprietry format high level objects that Microsoft
have designed as part of their operating system.

I will let you in on little secret, I have owned different versions of
Visual Basic since the 1st 16 bit version and I used to earn a living writing
those absolutely disgusting VBX ad-ons for VB. You are correct that writing
add-ons for Visual Basic is a nightmare and it is because of the proprietry
structure of Visual Basic.

I mean, let hit it here, no-one in their right mind would write a DLL in
Visual Basic for PowerBASIC, even if it could be done, its simpler to put
a timing loop in your code to make it look like it was written in Visual
Basic than to write it in Visual Basic.

I know young guys in the assembler area who have already decoded the COM
interface and are also doing DirectX programming with MASM. It is not
personally my area but if you have got the drift of my contributions to
this thread, I have pushed the idea of the compiler having the capacity to
use and build static libraries so that the multitude of things like COM
objects, complete high level components and the like can be either built
or used.

This will deliver PowerBASIC size and style of code, not Visual Basic
style code. Something that should NOT be misconstrued from my dislike of
Visual garbage is any shift to the programmers who are trapped writing
this garbage, it has been my experience that Basic programmers often
succeed in doing extremely difficult things in underpowered languages to
get around the limitations of its fundamental design. It is the design of
the language that I criticise.

As usual, my regards and I hope the world is treating you well.

[email protected]

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

**Lance Edmonds** · 15 Feb 2000, 09:09 PM

I've been reading this thread with interest (as have PowerBASIC R&D), and I have to comment on a few points raised here.

First, we have taken careful note of the suggestions that have been made so far, and R&D will give each one due consideration.

Second, any given compiler can not be all things to all people, nor can any given compiler be the key to solving all real-world problems nor be used to write every possible type of application. This is common-sense stuff.

The commentry by Francis (above) is a classic example of this: some things are easier in terms of development time in VB than PowerBASIC, but the reverse can also be true in other cases. Excluding the areas where VB and PB do not overlap (OOP, etc), PB wins in the performance and distributed code size stakes. While it may take longer to write some types of applications in PB, the extra time is often worth it for the results that can be obtained. That said, what can be achieved with any compiler is more-often-than-not determined by the skill of the programmer... "It's the artist, not the brush", but a good quality brush is absolutely necessary.

Finally, it must eb said that R&D are not asleep... because we (PowerBASIC) have a policy of not discussing projects before we are ready to do so, a few people seem to have developed some form of "misconception" about PowerBASIC and the future. What I *can* tell you that the future is going to be even brighter, but you'll have to stay tuned.... to PowerBASIC.

We have great things planned for the future... mark my words.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Siamack Yousofi** · 15 Feb 2000, 09:48 PM

Long time ago in a galaxy far far away I had the dubious honour to be the product manager for dBase, Interbase and SQL Server at a company called Ashton-Tate.

We excelled in every product category over Microsoft, Lotus and the upstart Borland led by “Khan the barbarian”. (This guy would take up half of Bob’s memoires.

).

Anyway, Ashton-Tate listened to its users and tried to build into its product everything anybody could ever wish for. To achieve this they stretched themselves beyond their capabilities and delivered a useless lemon that brought down the company.

Despite what everyone else says the real reason for the failure of the product was not the bugs and quality issues (we eventually fixed those). It was the performance and size of the executables. Trust me I was in the thick of it when it hit the fan and you are hearing it from the horse’s mouth.

A product named Clipper exploited the performance/size issue and adopted the same strategy as PB (or is it the other way round?

). Clipper thrived and was the compiler of choice with most programmers. Then Computer Associates acquired Clipper and made it “Visual” and “RAD” and as a result "FAT" and "SLOW". How many clipper programmers are there now?

Now with the benefit of 20/20 hindsight I recognise that our failure was due to not hearing the “IMPLIED” wishes when we listened to the “EXPRESSED” ones.

All of us have mile long lists of what we like to see in the next version of PB. However, fast small independent “exe” is our “IMPLIED” criteria, consciously or subconsciously.

The marketplace is a cruel, unforgiving and disloyal beast. Bob can bet the farm on what we want in PB but will we tolerate bloated slow code when its pay time? After seeing what happened to Clipper, I do not think we will and neither should Bob who worked hard to rescue his life’s work (Turbo-Basic) from the barbarians.

So here is the moral of the story:

If you cannot do the “IMPLIED” bits then do not do it at all. History has a habit of repeating itself.

Siamack

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

[This message has been edited by Siamack Yousofi (edited February 16, 2000).]

**Martin Francom** · 15 Feb 2000, 10:46 PM

..Wow, what a great discussion.
I think we all get rather impatient waiting for the advancements
that are thought to be indevelopment (or rather we hope are
being developed). I am am sure some of us will be very pleased
about what is eventually released and others disappointed. Not
because the release is not feature full but because their
expectations where not what PB though important at this time.
We have no choice but to go on with our business, obtain the
programming languages and utilities that do exist that be solve
our current programming problems. The when PB releases
something that is usefull for us, purchase it. You got to get
the job done with the tools you have at hand. It will not do
you any good to wait for some tool you hope someday PB will release. You may find yourself saying (six months after you finish a project) "Damn, I wish I knew they (PB) was going to
release that new feature..I would have done things
differently."
Oh, well... that just the way the cookie crumbles...
...
..I have heard talk about requiring all data types to be defined
prior to use. I for one hope that in all future releases PB
keeps the option of "on the fly" data types.
..I peronnally find it must easier to work with data types that
use an indicator. If you are reading thru a 3 or 4 page SUB
routine and come across "mydata" can you immediately tell me what data type that is? No! You have go searching arround the code to find the DIM statement. What a pain, in my opinion.
..There is no doubt what data type "mydata##" is, is there! And since I use a when I define a global I always use a "g" at the beginning of the variable name it is very easy to recognize
what variables are global and what varible type it is. Is there any doubt what variable type "gmydata&" is?
..Please what ever you do please keep "on the fly" defining of variable types. (I never could understand what advantage there
is for forcing the programmer to define (DIM) each variable
prior to using it.

------------------
Marty Francom
[email protected]

**Knuth Konrad** · 16 Feb 2000, 12:24 AM

Martin,

This is OT in a Visual Designer thread, but nevertheless..

..I peronnally find it must easier to work with data types that use an indicator. If you are reading thru a 3 or 4 page SUB routine and come across "mydata" can you immediately tell me what data type that is? No! You have go searching arround the code to find the DIM statement. What a pain, in my opinion.
..There is no doubt what data type "mydata##" is, is there! And since I use a when I define a global I always use a "g" at the beginning of the variable name it is very easy to recognize what variables are global and what varible type it is. Is there any doubt what variable type "gmydata&" is?

That is exactly the place where Hungarian notation fills the gap, wether you use the "true" Hungarian notation or customize it to your own needs. True, "mydata" is a useless name, but "exfMydata" (exf for Extended-precision Float) says it all. For a long time I used your coding style, too. But because VB doesn't provide a variable type identifier for each type (Variant, Date or all objects for that matter) I switch to the Hungarian notation. And I (and other) find my code nowerdays much more readable. And the "g" you add as a prefix to your global vars *IS* Hungarian notation.

..Please what ever you do please keep "on the fly" defining of variable types.

I agree with you here. Leave the #DIM ALL directive in the compiler as I, too, tend to be lazy when doing a simple "Test my algorithm" or "Convert data once and forget" programs...

Knuth

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

**Chris Boss** · 16 Feb 2000, 07:09 AM

Some very comments in this thread so far !

Lance made a good comment about it being the "artist and not the brush" that counts.

This may hit VB programmers the wrong way, but I think experience proves it true. I like VB because it is so easy, yet since I have always pushed my programming tools to the limit, I quickly found that VB "limited" me too much. I would ask myself, "hey C programmers can do it, so why can't I do it with VB". You just can't do certain things in VB that can be done in C. VB shields the programmer too much from windows.

VB allows "anyone" to create a GUI program, whether they are a good programmer of not.

This is part of the problem ! Initially that sounds good, but there is a catch. Since GUI development is so easy with VB, everyone who uses VB "thinks" they are a good programmer. VB tends to make us "lazy". Rather than say "how can I do this", we simply go out and buy an ActiveX control that does what we want and then afterwards complain that the ActiveX control is nice, "but" I wish it did things this way or that. We will "complain" about the ActiveX control and say "if I wrote it, I would do better", when in reality we couldn't write that ActiveX control if our life depended upon it.

You see, all the best ActiveX controls are not written in VB, but are written in C (by very good programmers).

This is not to say, that ActiveX (or any Library type) is bad. The point is that if we don't "put a little effort" into our programming, we will never develop top notch software.

I am the first to want Visual Design in PB. I know the importance of not reinventing the wheel (hey, I wrote EZGUI). The point is that ultimately, if we try to make things too easy, we will always "miss the boat".

Now, how does this apply to PB.

We can't expect the guys at PowerBasic to "invent" everything we could ever want. What we want are the necessary "tools" to create what we need ourselves. The tools needed by "Third Party" developers like myself actually are very important, because ultimately it will benefit all PB users.

It is unrealistic to think PowerBasic can create every Library or Tool that is wanted. What they can do is make PB more conducive to building those tools. I know that there is always going to be a better programmer than me somewhere. I should build things that are within the limits of my experience and capabilities and leave the things I can't do to someone who can do it. I would never think about writing a compiler (even though I did write one once for the Commodore 64).

Visual Design is not the "end of all things" that we may think it is. RAD is actually more important than Visual Design. Visual Design is an aspect of RAD, not the other way around.

The key to successful Visual Design, is building RAD into PB first. Visual Design will come in due time.

What is RAD then really ?

RAD (Rapid Application Development) simply means finding ways to build things faster. The key to RAD is "reusability". Another word is "components". In the DOS days, is was "Libraries".

Nobody can do everything !

Since my DOS days, I found it better to concentrate on building "inhouse" libraries for 75% of a project and then the last 25% I put the project together from peices. That is good coding. When I start my next project, then I can "reuse" much of what I designed before and also go back and improve it.

Before, Visual Design comes into its own for PB, I think a few other things must be tackled first.

Static Libraries for PB DLL. (it is a must)

COM support (to use and to create ActiveX controls)

OBJECTS
(objects need not be complicated. They can simply be a form of UDT which supports CodePointers for methods and for processing a property change)

These three things will not necessarily make PB "easier" to at first, but will offer the necessary tools for Addon developers to begin to create "bigger and better" things for PB. The more advanced PB programmers, with lots of API experience will begin to produce a bunch fo tools that will trickle down to the less experienced programmers, or those who are more concerned about productivity rather than reinventing the wheel.

I think that these advanced features must become part of PB, before Visual Design will really come into its own.

My concept of Visual Design is a system built upon extremely well designed components. Assembly language programmers can build "optimized" components for a variety of things that need optimum speed (assembler is always the optimum way to build things that need to be fast). PB is so optimized already, many components built just using Basic, will be lighting fast.

Take a lesson from automobile makers. The build cars, but not the components. The components are built by other companies who know what they are doing.

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

**jcfuller** · 16 Feb 2000, 09:43 AM

My turn:

I don't want anything from PB but an excellent compiler.
No RAD, NO Visual PB, no xtra nothin' except what they do best: compilers.

Creating static libs or obj's is on my wish list as is a Linux version.

Let the third parties develop the visual rad tools a number of the posters
are wanting. Myself I'll stick to the BC++ 5.2 resource editor and my code generator
thank you very much.

James

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

**Francis Beaulieu** · 16 Feb 2000, 10:10 AM

Blop! Oufff!

It is hard to swallow!

I'm not sure that you had understood me very well, I would like just to say that Object programming is the basic of GUI programming like a plan is the first part of a house.

If you do not like to programming in OOP then you have to programming in PBCC. A command button is a CLASS!

And all Windows is made from classes (Apple OS too).

OOP slow down the performances sure and add overhead! But it is the only good way to make GUI programming! Steve and Lance aren't totally in the false when they say that: "It's the artist, not the brush"! But you can trust me that there is no very big GUI applications who will get out of PBDLL programming . Why? GUI without OOP is just a nightmare (and I don't speak about the project and files management, debugging tools and ...).

Is anyones around here try to programming in JAVA to understand what is really OOP??!!

What is the bigest GUI software made in PBDLL (May be: Zap, who is not very big but take monts to be coded)??

Fine if you want to code everythings in low level, but I hope you are pay by hours worked not for all the job because you run to big problems if not bankcropsing...

)

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

**Chris Boss** · 16 Feb 2000, 01:02 PM

At least JC Fuller and I agree on one thing, PB needs to support Static Libraries. Thats number one on my wish list.

I can wait for COM and while I think OOP can be implimented efficiently (and I would like it), it can wait too.

Static Libraries is "crucial" to the future of PB (IMO).

Now to the question about, building large GUI apps with PB, posed by Francis. While, I agree that there aren't many (well known) large GUI apps created with PB, I don't believe PB is limited to only small apps.

I hate bringing up EZGUI again, but let me say that EZGUI will likely change this. Since I targeted VB programmers in designing EZGUI, I assumed that they would be building extremely large apps it. Since building complex GUIs with EZGUI is so easy, it opens the door for building huge PB apps.

Where EZGUI shines, is in creating multi Form (Dialog) apps. For example, the Visual Designer that comes with EZGUI , is an EZGUI app itself. Since I didn't have the Visual Designer when designing it, I had to write the code by hand for each every Dialog. It wasn't hard at all (even without the Visual Design tool).

The Visual Designer has Dialogs for each type of control (for Properties), Form Properties Dialog, the main Dialog, two Floating toolbars, a Dialog for Code generation and a Move control Dialog. It is a multi Dialog app. The entire app compiles to 165 KB (not counting the 122 Kb EZGUI DLL), which is quite large for a PB app.

My point is, that once you get beyond the GUI creation and processing of events, the rest of a program is generic Basic code. If a product like EZGUI can overcome the hurdle of GUI design now, imagine what the next generation of tools will do for PB apps.

I doubt PowerBasic is sitting on their laurels and they likely have a few tricks up their sleeves for future versions of PB.

I expect EZGUI to be a "door" to the next generation of Large PB apps. I am sure other Third party developers will also begin to create the next generation of PB tools, which will move PB forward as a complete development environment.

One of the things, I notice my customers and beta testers saying is that plan to use a "variety" of Third party tools for each aspect of their software development. One mentioned using SQL Tools with EZGUI apps for database stuff. Another mentioned using the latest Graphics Tools with EZGUI apps for graphics stuff.

The easier PB makes it for us to integrate all these Third Party tools into a single app, using PB at the Helm, the bigger and better our software will become.

As is commonly said, "You ain't seen nothing yet !"

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

**Jim Seekamp** · 16 Feb 2000, 01:55 PM

What do we want in a Visual Designer for PB ?

Do we want a VB like environment ?

NO WAY! VB is in a world all it's own. The logic of programming
without having callbacks is ridiculous and you can't even fully visualize
what you're doing. All you get is the fluff.

Do we want to be able to add code to "Events" directly in a Visual
Designer ?

NO WAY! Windows is a message-based operating system, and
working without callbacks is phony and illogical.

Do we want the Visual Designer integrated with the IDE ?

Yes; one less escape from the editor. It should create uncompiled
resources.

------------------
Jim Seekamp

**K Peel** · 16 Feb 2000, 03:14 PM

Excellent thread by the way!

Now lets get things into perspective, the possibility of conditional compiling static libraries allows for the much needed distribution of reusable code without the overhead.

If you code reusable functions, then you get where i'm coming from, I have written a small library (56k) with over 100 (one hundred) functions- such as date manipulation, window functions, file functions, registry/ini, graphix, check list boxes, encryption, and even 'about' and 'tip of the day' dialogs, and loads more!

The point is, if I could compile this into a conditional compiled static Lib and released it, it would be much more successful than a solid DLL, i should think.

Returning to the subject of COM/visual design, programmers could have all these functions and more WITHOUT the DLL 'overhead', with all the required precompiled functions, such as in C\VC !

Personally, I think that Visual Basic will die out over a gradual period, because the thing is, as has been pointed out, that a 'runtime library' imposes big risks - once you have modified the main runtime, the 'dead' code has to remain for compatibility with older code, and Micro$oft has made this clear with their 1.4mb+ VB6 runtime and eventually they will just dump it, probably in favour of JAVA and other propietry
internet-styled languages.

Please bear in mind that this My oppinion only, after some thinking and overview.

Thanks.

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

**K Peel** · 16 Feb 2000, 03:35 PM

Originally posted by Jim Seekamp:
Do we want a VB like environment ?

NO WAY! VB is in a world all it's own. The logic of programming
without having callbacks is ridiculous and you can't even fully visualize
what you're doing. All you get is the fluff.

Do we want to be able to add code to "Events" directly in a Visual
Designer ?

NO WAY! Windows is a message-based operating system, and
working without callbacks is phony and illogical.

Do we want the Visual Designer integrated with the IDE ?

Yes; one less escape from the editor. It should create uncompiled
resources.

Jim,

Of course we want a VB like environment, but realistically it just is not going to happen, guys like Chris Boss (for which I have a lot of respect and admiration for his forwardness) are very innovative in their products for PowerBasic, but a VB styled undertaking is so huge, even I cannot contemplate such a coordinative project/program/product!

But of course, if a Visual Designer was introduced then we would like pre-coded events, as such in VB (aargh!) where you could select the events you would need, and generate ddt/api code for that event, and add your own functions for the callbacks.

I agree on the last one, the current IDE is notorious (sorry , pb!) for its uncustomisability, an improvement in this area would be very much appreciated!

Well 1 outta 3 int bad!

Thanks.

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

Announcement

Visual Design Considerations (Part 2)

Visual Design Considerations (Part 2)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment