Announcement

**Erwin van de Wiel** · 16 Jun 2000, 02:43 AM

My Wishlist:

* A Wishlist generator (very usefull for some people)

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

**Niraj Bhatt** · 16 Jun 2000, 02:54 AM

looks like someone just took out feature list of Delphi

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

[This message has been edited by Niraj Bhatt (edited June 16, 2000).]

**Lance Edmonds** · 16 Jun 2000, 05:56 AM

Are there plannes for devoleping a visual IDE for PowerBasic DLL Compiler with forms and controls and OOP Support?

Stephane, as you well know, we are not allowed to disclose information on products that are not shipping. We do appreciate your suggestion list, and it will be forwarded to R&D, minus the items that _you_ have suggested in the past - to be fair, we need to ensure that each item in the wish-list receives no more than one "vote" from the same customer.

However, I do have some personal views on some of your requests for PB/DLL, and I encourage others to comment and discuss these things too.

My first comment is that you are asking for a large number of controls to be added to DDT, and most of these controls automatically force a "significant" code overhead. In addition, they are not all available on all Win32 platforms, and some are limited in functionality dependent on the installed version of IE, Windows, plus Service Packs and patches, etc.

I do not believe that R&D would ever seriously consider implementing every possible control for these very reasons - it would make for a tech support nightmare for both us and *your* customers if you applications did not run on all platforms.

Even if they did consider this possibility, to make it viable the DDT runtime library would need to become very granular to reduce the amount of runtime library code included in apps that did not use all of the controls. If this was not done, I suspect the war on Bloatware could be influenced! This type of work adds a lot to the development process, and in turn, this would affect the frequency of updates and increases the price of the product.

Regardless, you can use these controls today, right now. Simply use the CONTROL ADD "customcontrolname" statement built right into PB/DLL 6.0, and the control is effevtively a DDT control that can be communicated with by using CONTROL SEND, etc. The advantage of this method is that *you* control the level of "bloat" in your application.

- No Runtime modules for Executing the program

I assume you mean EXTERNAL runtime modules? Every PowerBASIC program already includes a runtime library but because it is embedded into the app and it is very granular, it's presence is hardly noticed.

- Setup program for install the software (like Inno Setup or INFTool)

Writing a "clean room" instaler or even licencing one would add significant costs to the retail price of PowerBASIC, and considering that even today you can get excellent qualify tools to do this (for free), I don't believe this would be a viable option.

Personally, I would rather see R&D spend time on improving the compiler and upgrading the IDE rather than reinventing the wheel for an installer. It is worth noting that the Win2K product line will be dictating a change in the way app installers will work in the future too.

The following are *already* in DDT, which accounts for approximately 1/2 of the items you listed:
* Frames, MainMenu, PopUp Menu, Label (build-in PBDLL60 DDT-control), TextBox (build-in PBDLL60 DDT-control), Command Button (build-in PBDLL60 DDT-control), CheckBox (build-in PBDLL60 DDT-control), RadioButton (build-in PBDLL60 DDT-control), ListBox, ComboBox, ScrollBar, GroupBox, RadioGroup, BitMapCommandButton, Image, StaticText.

Each of the following can be implemented as a DDT custom control, and there is code for most of them on this BBS:
TabControl, PageControl, ImageList, RichEdit, TrackBar, ProgressBar, Updown, HotKey, Animate, DateTimePicker, MonthCalendar, TreeView, ListView, HeaderControl, StatusBar, ToolBar, CoolBar, PageScroller.

The following are either not GUI controls or "real" Win32 controls at all - they are simply a collection of API functions - despite what some "other" compilers lead you to believe:
* Timer
* MediaPlayer
* OLEContainer
* DDEClient
* DDEServer

WIN COMMON DIALOG DDT CONTROLS
* OpenDialog CommonControl
* SaveDialog CommonControl
<snip>

The common dialogs are basically self contained windows, so I cannot image how we could implement these as DDT controls...

- Build-in API Programming continue and 32-bit assembler

Ok! We'll be able to do this one, guaranteed!

Anyway, as I noted, the list will be passed along, regardless of my personal feelings on some of the items.

Thanks again for your list, and please post any additions into this thread to reduce the number of threads containing "wish" list items. Thanks!

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

**Steve Hutchesson** · 16 Jun 2000, 06:41 AM

Where have I seen this "wishlist" before ? Why listen to members of this
forum when it seems that the wishlist is a computer generated repetition
of the same stuff we have heard over & over again. When will the next
wish list be posted ?

Is this an attempt from the Borland camp to sabotage a genuine performance
product ? Make it as slow, bloated and buggy as the rest ?

Come on Stephane, rewrite the autoposting software you have so it says
something original.

OOP(s)

[email protected]

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

**Troy King** · 16 Jun 2000, 06:55 AM

quote:

: Build-in API Programming continue and 32-bit assembler

Ok! We'll be able to do this one, guaranteed!

Lance, you crack me up! You must be over the "minor" surgery by now .

------------------
Troy King
[email protected]

**Borje Hagsten** · 16 Jun 2000, 08:58 AM

The only thing I really would like to see in the next version is
some sort of project manager. PB/DLL is not just for creating small
utilities anymore and when you start getting more than 4-5 dialogs
in an application, plus 20-30 functions or more, it becomes a bit
hard to maintain it all.

Visual designers - who needs them? I have spent a lot of time with
PB the last 5-6 months and now build dialogs easier by code, than
with VB's or Delphi's visual designers. The DDT code style is both
clean and gives enough control over things, IMHO.

Common dialogs - most of them are well documented by now and easy
to add to any application. When in doubt - search these forums..

Common controls - same there and they are actually much easier to
do something extra with in PB than in any other language. Try
creating an ownerdrawn ListView control in VB or Delphi and see
what I mean..

The name - now there's an issue worth considering. PB/DLL sure
doesn't say much to any "outsiders". Maybe time to change it to
"PB for Windows" instead..

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

**Cezary Zielinski** · 22 Jun 2000, 10:02 PM

My wish is small:
in editing not to highligh reserved words in DATA line, e.g.:

DATA even, odd, NONE

Regards

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

**Lance Edmonds** · 22 Jun 2000, 10:31 PM

Strictly speaking, that is an IDE issue rather than a compiler issue. The workaround is to enclose the data items in double quotes.

I'll ask R&D to add that one to the list (if it is not already on it!)

Thanks!

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

**Tom Zelenik** · 24 Jun 2000, 05:37 PM

I have been struggling with PB/DLL 6.0 for some time now trying to make some up to date professional looking applications without much success. I have tried using PowerGen to speed things up a bit but find I spend more time fighting it than I'd like. I can make some very small very fast apps providing I do not try to include features of any modern significance. The examples that I downloaded from PB's site more often than not will not compile without fixing them up. The examples I have that "demo" adding a custom control are more likely to cause carpal tunnel syndrome than impress anyone and NOT ONCE was CONTROL ADD used or demonstrated. The help page for it tells me nothing about how to get the info to effect a custom control.
What stikes me is that the code samples I've seen (and thats been a lot of them) look less like any basic language and more like a neverending stream of function calls and parameter lists. If this is the answer to visual form design then I guess I might as well go use shareware assembler which at least has excellant documentation available in the form of tutorials, and free code generators available which work and can get you up and coding faster.
I have read on the forum many insulting attacks against those wanting some automation, justifying snide remarks in the name of ending bloatware. Ya know car enthusiasts years ago were against automatic transmissions since stick shifts were more efficient, but then automatics started catching up and actually beat the manuals head to head. I suppose the racecar drivers today mainly use manual but guess what fellas? For every race car driver there are thousands of regular people who enjoy the level of performance they get with automatics. If Bob Zale is happy to be supported by a group of racecar programmers thats his business but there's a much larger group of customers out there that have a job to do and wanna do it rapidly as well as efficiently. Sooner or later Microsoft may well get VB to be efficient or else some other company will put the emphasis back on giving the users (read programmers) the tools they need to focus on THEIR logical problems and not the languages. I for one wanna see PB do that! Here's why.
Back in the 80's a Chief computer design engineer who was a friend of mine gave me a pirate copy of Turbo Basic and said they used it to brainstorm ideas in a RAD environment because it was intuitive to use (easy) and performed quite well. I was writing in assembler then and was impressed at how fast this (ugh) basic was. I figured out how to add my OBJ.s to it and was zooming. I went to BUY a copy and found out Bob Zale had taken off with it and that it was now Powerbasic. I bought it and was even happier! I have been an exponent of PB up until PBDK ver 1.5. I bought it but never used it as the Teleradiology app I was writing would have to give up all its speed so some clown could look at a pretty window. Another big thing was it would take too long for me to come up to speed with PBDK 1.5 so I stayed with DOS and we kicked butt on our competitors, speed and ease of use-wise. ALL with PB and Tasm.
When I finally did get the time to look at PBDK I though to myself oh my god I'm gonna spend all my time making the OS happy and I got disgusted and gave up programming. Being mainly in the hardware end of things I now am with an outfit that needs to get their control Software running under windows since anymore thats all there is. They asked me to help their Programmers and they were using VB 6. I got into it and decided it was swell but the delivery would be humongous so I logged into my old favorite site to see if PB was still around and got excited to see the new PB/DLL. I almost talked the VP into switching to it but I would have been in a bad light if I had. The owner wants to see fast progress and see stuff on the screen! (he's not real technical but HE has the $$$) I hope you see where I'm going...Fast code is swell but fast development in terms of putting on a dog and pony show for bean counters is more important in an R&D environment.
I bought it myself hoping I could port the code over but just getting to a confidence level has been a struggle. The VB code is using many of the hottest new controls and its a snap. But I know there will be problems with packaging the code. I want to use PB/DLL but the other programmers took a look at it and would rather go to C if they have to fight the code that hard.
I don't get paid for how smart I think I am , I get paid for programs that impress people and can be made QUICKLY!!! If I write 500 lines of code thats rippin and another guy does 100 mouse clicks to put together some bloatware in half the time... (that to the average user works the same)...then he's a hero and I'm a slacker.
Bottom line is this. The need is for both speed and ease.
I need to focus on MY task, not the languages demands. Bob I think you need to focus on our tasks too and if anyone can overcome the Windows mess its probably you, But your 6.0 needs some automation and some decent documentation! I don't have time to learn all the ins and outs of windows programming so I rely on you and thats why I been paying you for your products for 15 years.

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

**Troy King** · 24 Jun 2000, 05:59 PM

Originally posted by Tom Zelenik:
I don't have time to learn all the ins and outs of windows programming so I rely on you and thats why I been paying you for your products for 15 years.

It sounds to me like PB/DLL isn't what you want. But if you're trying to avoid the ins and outs of learning Windows programming, C won't help either unless you go with Borland C++ Builder with its nifty VCL controls. It sounds to me like you want VB-like RAD (and there are tools by third-party vendors to give you just that, like EZGUI) rather than small and fast. If that's what your employer demands, then I can see how PB/DLL would be a hard sell, especially if you're just learning Windows programming. However, you may also want to look into using DDT (thus the nature of the CONTROL ADD statement you mentioned) rather than SDK-style windowing.

But it also seems like you might misunderstand the nature of CONTROL ADD. It doesn't add OCX or VBX controls like VB does; it's for adding custom classes like from a DLL or defined in your own code (see Dave Navarro's URL control in the Source Code Forum, for example). However, Jazzage software's JA COM/PB will allow you to add OCXs and other COM objects.

To some extent, I can agree with you about "might as well use C"; I feel that way sometimes too when I'm buried in a really long block of code... but at least the memory management and string handling are much easier in PB than C. Good luck with your project, btw.

------------------
Troy King
[email protected]

**Chris Boss** · 24 Jun 2000, 07:15 PM

Tom;

Let me first say that your feelings are quite valid !

Yet, in defense of PowerBasic, I must say that the compiler they have created is one "mean machine". It was designed for programmers who wanted "Power" and it lives up to that challenge. Now Basic programmers can write "top notch" programs that once were only creatable using C. I can now write apps that are "better" than ones written in C.

The problem is of course that if your programming needs don't allow for the "steep" learning curve of PB and the API, you will obviously be turned off. This is quite understandable in this age of RAD tools. Especially VB programmers, want to be able to create great looking apps in the shortest possible time.

Third party tools like EZGUI and WinLift solve "most" of such complaints and they are just the first generation of RAD tools for PB. Just look at how many new features Patrice Terrier keeps adding to WinLift and you get an idea of the speed at which Third party tools are developing for PB. The next year will hold many exciting advances in PB addons and they will continue to get better. Just ask WinLift and EZGUI users what they think of this first generation of PB addons. There are few complaints and lots of excitement.

Lastly, I am glad to be able to say about my product (EZGUI) that it is was created using PowerBasic !
It never could have been done in VB, never !

So keep up the good work, PowerBasic !

[This message has been edited by Chris Boss (edited June 24, 2000).]

**Chris Boss** · 24 Jun 2000, 07:28 PM

Tom;

A discussion of EZGUI is best suited to the Third Party forum, so I will post a more detail discussion of it there , so check it out. I think you may be surprised.

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

**Steve Hutchesson** · 24 Jun 2000, 08:42 PM

Tom,

Most of us at some stage have had to wade through the internals of Windows
to learn how its done. I did it in the days of the SDK and Microsoft C 6 in
Windows 3.0 and it was a true joy to behold.

Now PowerBASIC is in fact a true low level compiler that delivers in terms
of performance and that says it competes very favourably with any other
low level compiler/assembler on the market.

The problem you have described is the common one of throughput and to some
extent, everyone is faced with that and there are different solutions to
different problem. If your $$$$$$ managment want speed of development, there
are a number of solutions available as PowerBASIC also has its strength in
building high performance DLL's.

1. Do the front ends in VB and use PB DLL's for the fast stuff.

2. Have a look at some of the specialised PB aftermarket products.

The other end of the $$$$$$ market is the cost of doing any of the fast
stuff. No matter how fast someone can do their 100 or so mouse clicks, they
cannot write fast low level code without having to get their hands dirty
somewhere.

RAD these days means slopping junk on a form and bundling a pile of OCX/DLL
files with it but it is not the only meaning of the term. PowerBASIC is
what you would call "BACK END FRIENDLY" which means when you MUST write
some code that has to perform, the capacity is there. This is not the case
with RAD front end generators which are toothless in comparison.

While PowerBASIC aftermarket products are not my specialty and most know
that I am not an aftermarket vendor, feel free to have a look at products
like Phillipe's Jazz Age range, Chris's EZGUI range, Eric's console Tools
and of course many other fine products that do what you need.

From the contact I have had with a number of these people, you are getting
the output from programmers who have a very good depth and from using their
products, you are also getting excellent BANG for your buck in terms of
capacity and throughput.

For old API grinders and mnemonic munchers of my generation, PowerBASIC is
a very powerful capacity which will do most of what you need but if the
pressures of $$$$$$ managment prevent you from writing high performance
code, join the rest and buy it from people who are specialised in writing
it.

Regards & good luck with it.

[email protected]

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

**Lance Edmonds** · 25 Jun 2000, 12:00 AM

Tom, while I can uderstand the reasons behind your criticism, I'll have to respond to some of your points, as I understand them.

The examples I have that "demo" adding a custom control are more likely to cause carpal tunnel syndrome than impress anyone and NOT ONCE was CONTROL ADD used or demonstrated. The help page for it tells me nothing about how to get the info to effect a custom control

CONTROL ADD itself is demonstrated in all of the DDT example file supplied with PB/DLL 6.0. A basic understanding of how controls (of all types including many custom controls) use messages to communicate with a dialog callback is all that is needed to understand how it all works. Because custom controls often use private/non-standard messages, style and notifications, providing an example is like writing psuedcode - any example we provide will bear no real resemblence to any other custom control... As long as this would not classify our demo code as 'misleading' or 'too simplistic', then it may be acceptable.

Unfortunately many visual-design-orientated programmers have only a minimum understanding of how Windows really works "under the hood" or have never ventured into API-level programming - something that VB is capable of doing to a moderate degree.

That said, I'll see about getting a custom control example added to the demo included with the compiler.

I almost talked the VP into switching to it but I would have been in a bad light if I had. The owner wants to see fast progress and see stuff on the screen!

Hmmm.. the problem here is that you admit that you cannot adapt fast enough (or do not want to invest the time to do so) to become proficient with our product in order to fit your employers [restrictive] vision of what is involved in writing applications. He pays your salary, so his word is what counts to you - that is fair enough. Given your situation, the only way you can move away from VB is to employ another language that offers a RAD approach. You could try C++, Delphi, Foxpro, but in the long run you will need to invest alot of time learning the in's and out's of the new language. If you chose C++, then you'll have to learn SDK-style programming too. When you think of it this way, PowerBASIC is actually a lot more attractive to you as the learning curve is much lower (for most people) than moving from VB to C++. Food for though.

I don't have time to learn all the ins and outs of windows programming so I rely on you and thats why I been paying you for your products for 15 years.

I find this particular comment very interesting, and the most insightful.

As others have pointed out above, if you don't have the interest or the time to learn Windows programming, then you should not try to become a "low-level" Windows programmer - stick with the product that fits your needs. When Bloatware becomes a big issue again in the future, you can always revisit PowerBASIC.

Your (or rather your employers) requirements are not to create compact and efficient code, but instead the requirements are for rapid application development.

PowerBASIC can not be all things to all people, any more than VB, C++, Cobol, Prolog, FoxPro, Forth, Assembler, or any of the hundreds of other programming languages can be. Our products provide tools that offer specific benefits to those willing to learn how to use them.

Finally, stating that you have been "paying for our products for 15 years" is highly inaccurate - we don't charge royalties ot annual license fees. A more accurate statement would have been "I have purchased 3 products from you in the last 15 years", or words to that effect. It would be interesting to figure out how much money and time you have spent on researching your current language of choice, plus all of the add-on's, books, and additional materials, etc.

The next thing you should ask yourself: how much time you have spent learning how to program with VB - time that has apparently locked you into a particular mind-set offering little chance of escape - at least not without "paying the price" of a learning curve requirement for another language.

Anyway, I wish you well in your future ventures... if you wish to stick it out and learn how to program with PB/DLL, then i'll try my best to help you along the route. No hard feelings.

Best regards,

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

**Francis Beaulieu** · 25 Jun 2000, 10:03 AM

When will you put yourselves in the head that the products of Power BASIC are made for specific programmers?

When you will put yourselves in the head why VB is so heavy, it is that that must be extremely difficult to implement all these functionalities in a language...!

Thus leave your frustrations on side, it does not have there better worlds in the language BASIC. Those which likes the speed of development and the programming object, go with VB. Those which likes the rough power and which have time to develop least the click with the hand, go with PB.

That took two years to me to understand that, for this reason it did not give anything for me to buy PBDLL 6, because for me, my RAD and my objects I do them with VB!

If one day PB becomes a tool in BASIC as Delphi can do it, then there that will become a serious option to be considered!!!

For now I use PBDLL to make[...] DLLs!

------------------
-------------------------------------------
Francis Beaulieu
FrabLaser Softwares

**Tim Wisseman** · 25 Jun 2000, 11:01 AM

There are things about VB that are great. Like the editor and the debugger. Editing code while the program is still running is very cool. The resource handling (BITMAPS) powers of VB are great.

I have had many problems will VBX and OCX controls written by 3rd parties, to solve the problem I have changed my programming style radically.

My VB programs now are made up of just the core VB controls with no extra OCX controls. My forms are just blank forms with one picture box the size of the form. All the "controls" are painted onto the picture boxes using pure basic source (VB and PBDLL).

I get the new parts of the program up, working, and debugged in VB and then drop the code into a PB DLL.

VB provides the forms engine, resource handling, and events handling. PB provides the inline ASM, pointers, unions, and general super high speed.

I have one program that consists of a lovely 138K VB front end GUI and massive 1046k PBDLL 6.0 backend.

I enjoy the best of both worlds. It did not happen all at once, over time I slowly started using more and more API calls and PB DLL's in my VB programs. The huge speed improvements encouraged me to do more and more, until I ended up with the 100% controls painted in a picture box solution.

You can write very fast VB programs, if you know what you are doing. At this point I do not want to give up VB or PBDLL, hybrid programming is just too much fun.

Tim

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

**Niraj Bhatt** · 26 Jun 2000, 04:06 AM

I dedicate this joke to all who critisise PB whithout knowing why and where to use PB.

2 men talking about the wife of there dream, the first one said, I want a wife who is a good cook and can look after my childrens, who is very good to my parents and who can go out to pubs and parties with me. The second fellow replied and how do you think you will manage all the 3 girls in 1 house.

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

**Matthew Berg** · 26 Jun 2000, 01:55 PM

If this has not already been added to the official wishlist: It would be nice if the compiler could support a #DEFINE metastatement to declare numeric and string constants (in addition to the syntax already supported for doing this), for compatibility with the Resource Compiler. It can be annoying to have to maintain two constant declaration include files containing essentially the same information.

**Walt Decker** · 27 Jun 2000, 06:46 AM

I'd like to see FIELD and MAP included in the next release. Granted, folks consider FIELD and MAP as an "outmoded" form of data I/O; however, those statements are highly useful for creating end-user defined relational data-bases.

Respectfully,
Walt Decker

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

Announcement

Wishlist for the next PBDLL70

Wishlist for the next PBDLL70

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment