Status of Visual Designer for PB/DLL6

[Bruce Singleton]

Does anyone know the status of the project to develope a visual designer and DDT code generator for PB/DLL6?

Does anyone Know of any Visual Designer that will generate DDT code for PB/DLL6. I need the power of DDT but I also need to speed up the layout of screens.

Thanks In Advance

Bruce

[Lance Edmonds]

to my knowledge most, if not all, of the "public-source" projects are still fairly involved in writing the gui design section.

if you have access to visual studio's resource editor, then maybe mike mayerhoffer "makeddt" project may help you on your way. check out "makeddt.zip" at ftp://ftp.powerbasic.com/pub/pbdll32/ddt/

also, james c. fuller has a similar project... see

------------------
lance
powerbasic support
mailto:[email protected][email protected]</a>

[Borje Hagsten]

The interesting part with all these Visual projects for the current
version of PB is what will happen when the next version comes out?
I mean, will PB inc. finally release a visual inteface themselves
and it they do, what will happen to all these "private" alternatives?

PB inc. cannot let others dictate the way they want to develope or
improve what already theirs, so I guess it must come to a point where
someone maybe will be "hurt" by a future version of PB for Windows.


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

[Lance Edmonds]

I find it interesting how there are so many different "visual designer" projects going on. Imagine the results if everyone cooperated with a single project development instead of a handful of separate projects. Don't take this wrong, I'm certainly not trying to discourage these projects.

I once coordinated a "public" project on Compuserve, whoch lasted for about 6 months (anyone remember PBFax?) and was really hard work keeping everyone encouraged and able to find time to contribute. Creating an fuly-fledged visual designer as a group project is a huge task.

That said, I for one, can't wait to see them finished.

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

[Chris Boss]

Bruce;

The "concept" of a Visual Designer, while great, is difficult to impliment. One reason, is that there are many different "styles" of coding used by PB programmers.

You have the SDK style using just the API (which I prefer).

You have DDT which many PB users like a lot.

You have "engines" like my product (see Third party forum).

There are advantages of each and weaknesses in each.

To create an "Open source" project, first requires a "standard".

The next hurtle, is "who" will organize the project.

This is not easy, since it is a "labor of love" and the person has to be willing to spend lots of time working on the project, with little or no compensation.

The next hurtle, is "support" from others, which is probably the biggest problem. Jules made a very good start (which I strongly supported), but as everyone noticed, support for it slowly died out. Jules put a lot of effort into the project, but wasn't well supported by others.

I thought the addition of the Thread on the subject in the PB forum was great, but again, why should the guys at PB maintain the thread when support nearly died.

Commercial products by third party companies may be the best bet.

While, I know some DDT lovers and API experts aren't crazy about my concept of EZGUI (there are a lot who love it too), it will at least give me a start in building future tools. I think it would be relatively easy for me to convert my Visual Designer so it can generate both SDK style code and DDT and I have seriously considered building such a tool.

I think the concept of Visual Design for PB is here to stay. I was greatly impressed by Ed Turners latest version of a Visual Designer. While I think the code generation has a lot to be desired, the Visual Designer itself was "very impressive". Ed obviously has the programming skill to design a Visual Design tool.

Jules, efforts were very good too.

If there is one thing that "all" of the Visual Designer efforts has demonstrates (whether Freeware or commercial) is that it "can be done". It is NOT impossible.

Should Visual Design be encouraged more ?

The answer is yes !

When you compare the number of VB programmers, compared to PB programmers, it is obviously that the interest in Visual Design is here to stay. VB 1.0 was great, but by the time MS got to VB 6, I think they lost their way. VB is "slow" and just "bloatware" now. The only reason programmers still use it is because of Visual Design, fast development cycle and the vast array of third party support (using ActiveX). Yet, the more serious software developers who are not satisfied with slow and fat (VB style) will use C to create commercial products. You could never build a program like Macromedia Director or Corel Draw in VB.

Yet, if PB entered the Visual Design era too, it could compete against C. MS Visual C++ wouldn't hold a candle to a PB version that supported Visual Design (and ActiveX).

All I can say is, that "every" effort towards Visual Design, whether it be Freeware, Commercial or even a PowerBasic project, will just help "push the envelope" of PB and make it better.

If PB came into the Visual Design era, then "watch" out VB ! You would see thousands (if not millions) of VB programmers, flock to PB.

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

[Mark Newman]

As I step to the podium to defend VB...

When you compare the number of VB programmers, compared to PB programmers, it is obviously that the interest in Visual Design is here to stay. VB 1.0 was great, but by the time MS got to VB 6, I think they lost their way. VB is "slow" and just "bloatware" now.

VB 6 was a lame release to be sure, but I don't think that MS has lost their way. MS realized that the big money is in selling to the corporate/MIS market, so they aimed VB there; something like 80% of VB users are doing in-house DB, 3-tier, Web & related line-of-business apps. VB is an extremely capable platform in those areas. Large runtimes & DLL Hell are much less of an issue in-house than they are for a shrinkwrap app.

As for speed, VB will never win any straight benchmark tests (though VB5 improved execution speed quite a bit), but again, for the intended market, who cares? If a VB database app spends 80% of it's time hitting a remote DB, any speed differences between the VB program and a similar C/PB/Delphi app will be minimal.

...
If PB came into the Visual Design era, then "watch" out VB ! You would see thousands (if not millions) of VB programmers, flock to PB.

It's one thing to use a form designer with PB to quicken the visual design of an app, quite another to seriously compete with VB on VB's home turf. However, for commercial/non-corporate apps a "Visual PB" could steal some of the non-MIS VB users (like myself).

I think that a "Visual PB" would pose a much greater threat to C/C++ than to VB.

My dream would be to have the VB design & development platform with PB as the core language...not terribly likely though, unless the PB folks know something we don't

Stepping off the podium, the speaker acknowledged that he'd love to see a "Visual PB".

Mark


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

[Jeffrey R. Radue]

A visual designer for PB is the next logical step. As all of you may remember, PB was orginally promoted as a supplement to VB for handling intensive routines which VB performed poorly. Obviously, with the advent of DDT, the PB team is heading toward a direct replacement for VB, Dephi and C instead of a supplement.

Here are my thoughts:

1. Creating an open source visual designer is not a bad idea, however there is no guarantee that any work done now will follow the PB vision for the future.

2. I believe that the PB team should devote their attention to developing an integrated designer for PB/DLL. It is clearly in their interest.

3. Without a visual designer, PB can never compete with VB in terms of easy of coding and application development time. Don't get me wrong, PB is exactly what I have been looking for, but even with DDT it still takes hours to setup and code complicated dialogs. You can accomplish the same thing in VB in minutes.

4. The biggest downfall VB has is that you never really learn how to write windows applications with it. You only learn how to code VB. The same holds true for Delphi to an extent. Whatever designer application is developed for PB, I recommend that it not insulate the user from true API code. The MakeDDT program mentioned above is a perfect example of where the designer should be heading. In fact, by utilizing that engine I think alot of the hard work has already been done.



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

[Siamack Yousofi]

As Chris mentioned earlier there are many coding styles and creating a visual designer that is everything to everyone will inevitably bloat the end result. I agree with Jeffrey regarding MakeDDT. If we use DDT as the standard output for any visual designer then all visual designers would be compatible since they can read each other’s outputs.

If visual designers are developed as two-way tools, then they should even be able to read hand-coded DDT. In the same way we can use either resource editors or text editors to create resource scripts in say VC++, we could use a visual designers or text editors to create DDT “resource scripts” or “resource includes” which would compile seamlessly by the compiler.

This is sort of half way between VC++ and VB without the need for separate resource compilation and linking or bloated form engines and run-time DLLs.

We must never forget that anything, which ngatively affects the size, speed and independence of the .exe, will harm PB in the long run.

I have suggested in another forum that Bob Zale could define a DDT code generation standard so all those who wish to create commercial, shareware or freeware visual designers for PB (as well as the users) have the assurance of compatibility and interoperability among all visual designers.

In the long run the best product will win and as a result we shall all benefit.

Siamack

P.S. In fact those who develop visual designers could make them generate standard resource files (.rc) for the use by other compilers as well as ddt resources (.ddt ?). There is a cry for a simple, stand-alone and flexible resource editor in the market and very few are available (LCC?). A good resource editor will sell well. This will open the eyes of the public to PB also and is clever marketing by stealth.
------------------




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

[Michael Meeks]

I just purchase EZGUI which is a Visual Designer for Powerbasic. Want to save time with forms? It's a no brainer with EZGUI. Your forms and code are done within a few minutes. Testing is immediate. Why spend hours, when you can have it all in minutes!

Although version 1.0 is a start, some feature I wished that were included, I have started a wish list. I can truely see this Visual Designer in the future adding many inhanced coding modules that will stop us from re-inventing the wheel each time we begin a new project! The program is complete accept for own code, which allows us to focus on the main coding for the purpose of our program.

In fact, I just purchase the program less than 48 hours ago and if it's time you want to save, then this program is for you!








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

[Mark Newman]

A visual designer for PB is the next logical step. As all of you may remember, PB was orginally promoted as a supplement to VB for handling intensive routines which VB performed poorly. Obviously, with the advent of DDT, the PB team is heading toward a direct replacement for VB, Dephi and C instead of a supplement.

I can't decide if I want a form designer first or a decent editor/debugger. DDT is a workable solution for basic apps but doesn't scale well. The PB editor/debugger is, well, we all know the answer to that. Anyway, PB needs both tools if they want to challenge VB/Delphi.

Without a visual designer, PB can never compete with VB in terms of easy of coding and application development time. Don't get me wrong, PB is exactly what I have been looking for, but even with DDT it still takes hours to setup and code complicated dialogs. You can accomplish the same thing in VB in minutes.

I quite agree, but remember that the visual designer is only part of the solution; attaching code to the visual design and managing the code is just as important.

The biggest downfall VB has is that you never really learn how to write windows applications with it. You only learn how to code VB. The same holds true for Delphi to an extent. Whatever designer application is developed for PB, I recommend that it not insulate the user from true API code...

When I write a VB program, yes, I am in fact writing a Windows program. Just because VB operates at a higher level than straight C/PB code doesn't mean it's not "real Windows". One of the main reasons that VB and other RAD tools are so popular is precisely because they operate at a higher level.

This is not to say that a developer shouldn't understand how the target OS works. I do, but I see little benefit to writing 3 pages of API calls to accomplish what 1 line of VB can do. By the same token I don't use VB to handle math-intensive tasks; that's why I bought PB!

Mark


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

[Chris Boss]

Before, I discuss VB, let me say that I have never used anything as easy to use as VB. VB is productive, because it lets you concentrate on "what" your program will do, rather than "how" to make it do it. A VB programmer can "prototype" a new program in a quarter of the time than can be done in any other language. VB is a fantastic product in its own right, but ........

VB lacks POWER !

There is a price to pay for "ease of use" and that is power. PowerBasics own Name , "PowerBasic" obviously implies their "concept" of programming. Powerful software !

When it comes to an "optimizing" compiler, which offers maximum Power, then PB can't be beat !

This is the main reason I switched to PB. Serious software developers who create software that must "compete" with others many times opt for C rather than VB. Why ? While VB may be great for many vertical market apps that may not be speed critical, VB is rarely used for apps that require mazimum speed and power.

You would never see a program like Macromedia Director or Corel Draw written in Visual Basic !

Now, I can imagine such programs being written in PowerBasic !

The problem is that there is only so much time to develop a product. The concept of RAD tools has been around for a long time and is critical to fast software development.

RAD (Rapid Application Development) is crucial to staying competitive in todays software market. There is no question about this. If it takes me twice as long to develop a product as my competitor, he could easily capture the market before I even ship. Even if my product is better, it is hard to recapture the market as a latecomer. Also, RAD is important, because it keeps software development costs down. If it costs me 200,000 dollars to create a program compared to 1 million, it will be easier to recover development costs with less sales.

Some computer games literally cost millions of dollars to develop. Some business apps can easily run into 100s of thousands of dollars to develop.

Programmers, use VB because they can develop apps for just tens of thousands of dollars in a very short development cycle. Corportaions use VB because they want an inhouse project done today, not a year from now.

PowerBasic obviously has the Power. As more and more RAD tools become available for faster code generation for PB, PB can catch up to products like Delphi, VB and Visual C++.

As each new RAD tool for PB becomes available, it pushes the envelope for PB and the next tool will go farther. As people get use to one RAD, they will naturely ask for more powerful tools.

Its amazing, when you think about it. Here I just spent eight months working very hard in developing EZGUI and notice what my customers are already saying :

"I am already writing my wish list" !

This is good !

This means that while each RAD tool "helps" programmers do more, it also requires that the next "iteration" of RAD tools push the envelope even more and so on ....



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

[K Peel]

I have to disagree somewhat on the VB issues, can anyone remember VB3 ?, it was probably the smallest RAD tool available at the time, you could write a full app, concentrate on the code and not the UI, and the result was fairly good in speed terms (try running a VB3 app on a decent P2), with only a 300k runtime.

But times have changed,

Just look at VB now, its totally bloated, with all the features you don't need, whilst a time time ago I could write a VB application and fit it all on a 3.5" disk, now it has doubled and\or tripled in size, depending on your application, the point is, instead of Micro$oft concentrating on speed\size it has decided to pack the runtime with useless code and added rather large OCX modules into the bloat bargain.

On principle, I do not program in Visual Basic, in my oppinion, prospective programmers can be "brainwashed" by "programming" in VB, when I look in the local jobs section all I see is...

Skilled Visual Basic programmers required.

...and I laugh.

Just my two pence worth...


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

[Chris Boss]

Kev;

I really liked VB 1.0 and VB 2.0. I liked VBXs (OCXs are not as nice).

Then I jumped straight to VB 5.0. Now, I have to deal with "Service Packs" and the later versions of VB are not as stable as the early versions. I upgraded to Service pack 3 and now VB 5 GPFs when it compiles to native code. The original VB 5 didn't GPF. I thought Service Packs were suppose to fix bugs, not add more.

VB 1.0 and VB 2.0 as runtimes in the 350 KB range. This was very acceptable. I could create a single app that was about 400 KB, add the runtime and maybe 1 or 2 small VBXs and it still would fit on a floppy.

A lesson can be learned from Microsofts mistakes. Any Visual Design RAD tools for PB, must always follow the core goals of PB, (1) Be small, (2) be fast and (3) be solid as a Rock.

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

[Knuth Konrad]

While I agree with most of the points mentioned about VB I wonder why we dicuss about VB when we talk about a PB Visual Designer/RAD tool. My mother allways told me: Don't compare yourself to people who do things worser than you, compare yourself with those who do them better. So I would rather have a look at how Delphi implements the Visual design as Delphi (or the compiler behind Delphi) is in my opinion much more comparable to PB than VB is. It's concept of Libraries (VCL) is something to keep in mind when discussing a PB RAD tool. We all want/need libraries to work with. The VCL-stuff seems to be a nice concept.

Knuth

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

[John Rayfield]

>So I would rather have a look at how Delphi implements the
>Visual design as Delphi (or the compiler behind Delphi) is
>in my opinion much more comparable to PB than VB is.

While I haven't really 'used' Delphi, I have played with it a bit. From what I've seen of Delphi, it appears to be more of a 'code generator', not really much like VB at all, in the way that it works. So, I also think that any kind of RAD tool for PB is better compared to Delphi, since any RAD tool for PB is likely to be more of a 'code generator' like Delphi.

I'm curious - how many others around here have seen how Delphi works?

John Rayfield, Jr.


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

[Niraj Bhatt]

Maybe so many of them is laughing at VB.... But can I know all the guys who is not using VB at all for there profesional jobs.

The comaprision of PB and VB is totaly useless just like Linux and NT, because what one can deliver other cannot. The best thing is to use both and get the maximum benifit out of your skills.

They are just tools. What really matters is the proggramers...



------------------
Niraj Bhatt


[This message has been edited by Niraj Bhatt (edited February 10, 2000).]

[Michael Meeks]

Comparing Delphi with PB is like comparing c with c++. VB and PB is far more a comparison, because like it or not, PB is basic and VB is basic.

Delphi has many of the same problems that VB has. Bloatware! Create a simple database in Delphi and then ship the final project and you'll see what I mean. Visual C++ has the same problem.

PB has no bloatware. What you see, is what you get. Sure you can add .dll's and other addons as you wish, but these are choices you make as you write your program. There are no runtimes or required modules that are clued to the final product.

A Visual Designer for PB could look like VB or Delphi or any other program, but the bottom line is, what will it cost as far as baggage ?

Will it require runtime files ?
Will it produce complete source code ?
Will it allow for addon modules ?

These are questions that make or break a Visual Designer when it comes to market!




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

[John Rayfield]

Michael, you make some good points and give some good 'food for thought'.

John Rayfield, Jr.


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

[Mark Newman]

We need to remember that adding a form designer to PB will not make it the equal of VB in terms of RAD power. If PB wants to go head-to-head against VB and Delphi, the PB development platform will have to be something like or better than what VB offers. That level of sophistication will not come without cost, be it runtime DLLs, execution speed or code size. The key question is, can PB (or a 3rd-party tool) make that tradeoff work?

I've often wondered why PB doesn't follow MS's lead and marry the powerful PB language to a Windows shell and create "Visual PB", as MS did with QuickBasic and Ruby. A key issue is that PB isn't an interpreted language, but current C compilers support interactive debugging so it shouldn't be an insurmountable problem (did I just hear Lance burst out laughing ?)

Mark

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


[This message has been edited by Mark Newman (edited February 10, 2000).]

[Matthew Berg]

Will it require runtime files?
Will it produce complete source code?
Will it allow for addon modules?

If you are talking about a collaborative, "open source" project or some freeware job then goals like having it produce "complete source code" are quite reasonable.

However, if the product is made available on a commercial basis, then it is quite unreasonable to expect "complete source code" to be available to the end user (although the commercial developer may decide to have their product do this anyway). They may develop proprietary routines or formats, methods of accompishing difficult tasks, or even enhanced custom controls, intellectual property which they would quite reasonably want to protect by not making the source code of this available in the output of the Visual Designer. In this instance (and with PB/DLL's current inability to use static libraries - PB hint hint ), you are going to have to use run-time DLLs, like it or not. Obviously the developer of such a tool should make every effort to minimise the problems associated with the likes of Visual Basic.

I certainly agree that your third point is an important one for Visual Designers. Heck, Micro$oft made an industry out of that with Visual Basic VBX controls!

[This message has been edited by Matthew Berg (edited February 10, 2000).]