PowerBASIC - You Speak... PowerBASIC Listens!

[Steve Rossell]

How can we improve PowerBASIC? I'll bet you have a great hunch, so share it with us. A new feature suggestion? An entirely new killer product? We really want to know what have to say. Don't wait. Do it now! Click on over and talk to us at http://www.powerbasic.com/support/request.html.

[Jim Robinson]

incLean

I find incLean extremely useful, and it still works on 99% of my projects. I would like to have this become an official PB program so it would work 100%. Perhaps it could be incorporated into the IDE.

[Martin Draper]

I have been using the pbcc complier since it was released and I found very little that I can't do. But there are things that PBCC that are really annoying
that I still have to work around.

Number one on the list is dynamic strings in random access files. It has been
a part of the randon access files since the days of CB80 and CB86. Most basic languages support it and so does VB. It is major pain for me as I have to read these type of files on a regular basis as It is used very extensively in accounting/business data files.

Next I do a lot of work with Mysql and I have a standard library that allows a single connection to the server but I have not been able create a multi connection version because function can't return T_MYSQL Ptr and passing
T_MYSQL Ptr can only be passed to a function but you can't return it.

Last but not least Classes. After working with Classes in VB 2005, it is really a lot of hard work. Lose the jargon as Microsoft have done. in VB 2005
only difference between function in a class and a function in normal code
is that the block of code for the function in normal code is called a module
and the block of code for function in a class is called a class. That simple !

Also the documentation for Objects needs work it is written with so much jargon it is guff ! It needs real world examples, that work. The example in the documentation does not work properly. You also need to show what Classes
are all about this this.

#COMPILE EXE
#DIM ALL

CLASS MyClass
INSTANCE Counter AS LONG
INTERFACE MyInterface
INHERIT IUNKNOWN ' inherit the base class

METHOD BumpIt(Inc AS LONG) AS LONG

METHOD = Inc + 1

END METHOD

END INTERFACE
' more interfaces could be implemented here
END CLASS



FUNCTION PBMAIN () AS LONG

DIM Stuff AS MyInterface
DIM Stuffit AS MyInterface
DIM X AS LONG
DIM y AS LONG

LET Stuff = CLASS "MyClass"
LET Stuffit = CLASS "Myclass"

x = Stuff.BumpIt(77)
y = Stuffit.Bumpit(102)

PRINT x
PRINT y

END FUNCTION

[Bob Zale]

Frankly, I have no idea what you said, other than you seem to hate PowerBASIC. When you use a sentence like:

"You also need to show what Classes are all about this this."

It makes one wonder what in the world you mean...

Did one of our competitors engage your services?

Best regards,

Bob Zale

[Michael Mattias]

How can we improve PowerBASIC? ....talk to us at <LINK>

IMO your best bet to improve the product is to provide a venue where users can openly discuss new feature or product suggestions instead of only accepting suggestions privately. Your new link above is no substantive change from the current system of accepting individual suggestions by email.

Your small handful of personnel simply cannot provide the quantity and quality of input thousands of users could, were they officially encouraged to "kick around some ideas."

I daresay such discussions would also provide the kind of in-depth "gotcha checking" which you must perforce spend time on when considering new features or products. That is, it would not only prevent the kind of embarrassment like the "pass zero on stack when optional byref parameter has value zero" which had to be corrected (8.0.0 to 8.0.1), it would SAVE YOU TIME AND MONEY.

Time and time again we hear from PowerBASIC your customers are what matters to you most.

If you value us individually, think of how much more valuable we'd be as a team.

[Martin Draper]

Bob,
Hate Powerbasic "Over My Dead Body" but having said that sometimes I have to wonder what where you thinking. I have read documentation on classes and it is same guff you get from Microsoft and other people about OOP and classes. The simple fact of life is that in most cases OOP and classes are a wasting of time. Normal Structural basic is so much quicker and easier. In That regard Powerbasic rules !

The only real reason for using Classes is that classes are Mutil threaded and yet this not even mentioned. Using Classes to create Multithread functions should have been a key part of the documentation on classes !.

Under what were they think I have put Powerbasic classes. From the work I have done they work like a dream but honestly You could not made it any harder if your tried. Is the product Powerbasic or Power Oop's

Methods, properties, Instance variables are not part of the basic langauge and more Jargon is not welcome. So why not call them what they are Local and Global functions, local and Global Varibles within Class defination the way Microsoft, Sun, so many others have done.

Working for your competition Definately Not. Having to use some of there product afraid so and If I could get Powerbasic to do certain things they would be gone tommorrow.

Classic Example is the Random access fields with dynamic data which has been raised many times in the forums. These types of files are in very wide spread use and almost standard in accounting. I know I deal with them every day. I have to use CB86 compilier to write code to work with them. Don't say it I know !

I know you can't do it with UDT structure you use for Random access files because fields are delimited by length. But there is another way and the functionality is already part of power basic. The second way is the records are not padded, in CSV format and written as fix length record to the files the same way random access files do. . The records are padded or truncated at the end to the record size.

In the languages the syntax is identical to write# and Input# except there is another parameter which is the record number. How easy is that !

[Bob Zale]

Martin--

You are very, very mistaken on almost every point.

1- PowerBASIC has offered the use of dynamic strings with random access files for approximately fourteen (14) years.

2- If you hate OOP, don't use it. Unlike other languages, it is optional in PowerBASIC. It is not forced upon you.

3- Classes have absolutely nothing to do with multiple threads. I cannot even imagine how you derived such a definition.

4- METHODS are not a part of the original BASIC specification. This is true. But neither are floating point variables. Following your logic, I guess we should remove all floating point support? And we should require line numbers? And we should disallow any variable names longer than one (1) letter? And we should disallow dynamic strings? And we should disallow SUB's? And we should disallow multi-line functions? And we should disallow macros?

5- You said, "... the block of code for the function in normal code is called a module". This is simply not true. Perhaps you should take a look at the documentation?

6- You said, "...the block of code for function in a class is called a class. That simple!". Once again, very far from accurate.

7- Calling our product Guff is insulting. If you wish to post here, please show normal business respect?

I'm afraid I just don't understand what you're trying to accomplish here. If you have questions about using PowerBASIC, we'll be happy to help. Just ask? You'll get answers.

Best regards,

Bob Zale
PowerBASIC Inc.

[Brice Manuel]

Last but not least Classes. After working with Classes in VB 2005, it is really a lot of hard work. Lose the jargon as Microsoft have done. in VB 2005 only difference between function in a class and a function in normal code

VB's implementation of "OOP" is half-assed at best. VB should not be used as a metric for comparison to anything.

The simple fact of life is that in most cases OOP and classes are a wasting of time. Normal Structural basic is so much quicker and easier.

For smaller projects, procedural can be easier. But with a larger project, OOP is much easier to work with and maintain.

Using Classes to create Multithread functions should have been a key part of the documentation on classes !.

PowerBASIC has been capable of multithreading long before OOP was implemented.

You could not made it any harder if your tried. Is the product Powerbasic or Power Oop's

This is the 21st century. You would have a very hard time in this day and age turning a profit if your language did not support OOP. OOP has been an industry standard for many years, including BASIC variants. OOP is something potential customers expect.

I have to use CB86 compilier to write code to work with them.

If you are, it is because you choose to, not because you have to. Believe it or not, the computing world has progressed quite a bit since Digital Research released CB86.

Perhaps instead of thinking you know how things "should" work, you could exercise a little bit of humility and ask for help with the aspects you are having issues with. Based on your posts, you do not understand much of what you are complaining about.

I have read documentation on classes and it is same guff you get from Microsoft and other people about OOP and classes.

I have been programming since 1979. In those 30 years, Bob's The Life and Times of an Object is one of the best OOP explanations I have ever read.

[Knuth Konrad]

Back when I started with objects in VB, I found Deborah Kurata's Doing Objects a real eye opener in terms of understanding what this OOP stuff is good for/at.

And no one says you can't happily mix OO and structural programing in one application. Insiting to do everything in OOP is as wrong as insisting doing everything procedural. Use the tool that best fits the exercise given.

[Martin Draper]

Brice

VB's implementation of "OOP" is half-assed at best.

. I will agree with that !

PowerBASIC has been capable of multithreading long before OOP was implemented.

But is has had limitations. In the object forum I have posted the code for a Mysql Threaded interface. The code except for a few minor changes is same code is a prototype written serverals years ago which has never worked. Reason was the T_Mysql Pointers used by Mysql Api get lost in the code. Reason was something to do with passing UDT Pointers to and from functions. I took that same code put in a class as inthe expample and it worked.

If you are, it is because you choose to, not because you have to.

If only that is true. I have had a long quest to find a language without compromise that I can use for just about everything. Powerbasic is just about it. The only reason I use cb86 is the Basic Isam files widely used by some many of my clients. The records of there random access files are stored as comma seperated variables not fix length fields used by MS and Powerbasic random access files. This is the oldest from of random access files and they are still in use to today it also how many database servers store records.

From the number times that people have had similar problems and got the same answer "It can't be done" maybe some people should listen. But then that is what this forum is about so I pushing the case and a solution.

I have read a lot on OOP/class/object and basically the problem, I have got is that the powerbasic implementation so very different to that of anyone else. It has taken literally weeks to try and make head or tails of it. Now I work with objects in VB 2005 everyday and that experience was absolutely not help when I tried to create the example in the object forum and to tell the truth I still don't know if I have it right. !

Bob

dynamic strings with random access files

The string as defined in a UDT is a fixed length and string as defined in the Field statement are fixed length.That is not a dynamic string ! In order to use either them you have to know the size of the before you even run the program. This has been pointed on many occasions in the forums. When you save the udt for a randoms access file each field in the record is a set size. That is the Microsoft Implementation of random access files. But is not the only one, the other style I have already described was the first version and is currently the format used by many file/database systems.

I don't hate powerbasic classes. From the little I have been able to get to work is like everything else in powerbasic first class. That is the problem it so different to other implementation of classes. I spent the first week of trying to use it with the manual and the internet and I am still all at sea. Why because the the documentation has been written for someone who knows it rather than people like me who don't have a clue.

Classes have absolutely nothing to do with multiple threads.

Maybe in theory but in the real world I have spent the last two years creating application API for different system. Everyone is a set of classes and eveyone is multithreaded. So any number of versions of the class can be run simultaneous on any number of computers by any number of programs. If the program was single use, OOP was not even considered. If this not the case then why have instance variables as Instances are normally handled by a threads.

When you added code segments you called them Functions and Subs the same as everyone else you didn't call them widgets. So you should have called METHODS functions just the same as nearly everyone else.

I didn't call the product guff, I called the jargon used in classes Guff because to me it is a load guff . The documentation for Class needs to be written to normal user of powerbasic who don't understand Powerbasic OOP like me. There needs to be more real examples showing how to use classes. I have already put one example in the object forum to help and I going to put up more when I get them to work (Or when I think I get them to work)

[Paul D. Elliott]

Martin,

This is just off the top of my head so may not be exactly accurate.

For random access files, just open the file normally as random with
the length as the maximum of the fields. Then do a Seek to the
record # ( or maybe ( record # - 1 ) * length ). Then do an input
with individual variables corresponding to the fields. Wouldn't this
take care of the CSV conversions?

[Michael Mattias]

In order to use either them you have to know the size of the before you even run the program

As a rule-of-thumb, variable-length data are not suitable for random access.

If this rule is causing you to be all thumbs it's time for Plan B.

[Cory Marshall]

Thanks for the opportunity.

How can we improve PowerBASIC? I'll bet you have a great hunch, so share it with us. A new feature suggestion? An entirely new killer product? We really want to know what have to say. Don't wait. Do it now! Click on over and talk to us at http://www.powerbasic.com/support/request.html.

I love PB and have been using it for years, started with PBCC back in 1999/2000. Thank you for a good product at a good price. Having said that I have very little to complain about except.

The IDE is getting a bit dated. (Minor Issue but could use a major overhaul)

More importantly 64-Bit support. I'v been doing my best to keep under the 3gigs of memory needed to address some huge arrays. For best performance i have to keep them in memory however thats getting more and more tricky. Plus native 64-bit math and logic functions might help also, but its mostly a memory issue.

I have to ask if the IDE source code was ever considered to be released for open source development (gimp) or open source closed development (paint.net). It would be a fine addition to the "sample" directory.

[José Roca]

The only reason I use cb86 is the Basic Isam files widely used by some many of my clients. The records of there random access files are stored as comma seperated variables not fix length fields used by MS and Powerbasic random access files. This is the oldest from of random access files and they are still in use to today it also how many database servers store records.

ISAM files aren't random, but indexed. A random file needs fixed-length records. Period.

I have read a lot on OOP/class/object and basically the problem, I have got is that the powerbasic implementation so very different to that of anyone else. It has taken literally weeks to try and make head or tails of it. Now I work with objects in VB 2005 everyday and that experience was absolutely not help when I tried to create the example in the object forum and to tell the truth I still don't know if I have it right. !

PB classes are COM classes, not C classes or Java classes. Therefore, if you want to understand them, learn COM programming not OOP programming.

[Jeff Blakeney]

The only reason I use cb86 is the Basic Isam files widely used by some many of my clients. The records of there random access files are stored as comma seperated variables not fix length fields used by MS and Powerbasic random access files. This is the oldest from of random access files and they are still in use to today it also how many database servers store records.

From the number times that people have had similar problems and got the same answer "It can't be done" maybe some people should listen. But then that is what this forum is about so I pushing the case and a solution.

As Jose has already pointed out, the type of file you are describing in this thread is not a random access file but a sequential file that has an index associated with it that has starting positions and lengths for each record. These are very easy to handle with PB. The index file can be a random access file as the start position and length numbers can have fixed lengths (say 8 bytes by using a QUAD variable). I've used these types of files myself.

The solution is not to use a single random access file to store dynamic length data but to store the dynamic length data in a sequential file and create an index file that is a random access file that stores the starting position and length of each record of dynamic length data in the sequential file.

I have read a lot on OOP/class/object and basically the problem, I have got is that the powerbasic implementation so very different to that of anyone else. It has taken literally weeks to try and make head or tails of it. Now I work with objects in VB 2005 everyday and that experience was absolutely not help when I tried to create the example in the object forum and to tell the truth I still don't know if I have it right. !

I don't hate powerbasic classes. From the little I have been able to get to work is like everything else in powerbasic first class. That is the problem it so different to other implementation of classes. I spent the first week of trying to use it with the manual and the internet and I am still all at sea. Why because the the documentation has been written for someone who knows it rather than people like me who don't have a clue.

I've never done any OOP before in my life. I have read bits and pieces of how it is supposed to work as well as having (sometimes heated) discussions with my brother about the merits of OOP (I was pretty anti OOP back then). The first OOP I ever did was using PB and I used the PB documentation to figure out what I was doing. I agree, the documentation isn't great but it was enough to get me going.

Maybe in theory but in the real world I have spent the last two years creating application API for different system. Everyone is a set of classes and eveyone is multithreaded. So any number of versions of the class can be run simultaneous on any number of computers by any number of programs. If the program was single use, OOP was not even considered. If this not the case then why have instance variables as Instances are normally handled by a threads.

They are called INSTANCE variables because they are tied to each instance of the object that is created. You can have a single thread application create many instances of a single object with something like LOCAL oCust1, oCust2 AS CustomerInterface. oCust1 and oCust2 will use the same method code but they will each have their own instance of the INSTANCE variables.

When you added code segments you called them Functions and Subs the same as everyone else you didn't call them widgets. So you should have called METHODS functions just the same as nearly everyone else.

All the OOP discussions I've had and documentation I've read has always referred to objects as having methods and properties. PB is using the proper terminology even to the point of including the property method. Properties are just specialized methods and you don't even need to use them in PB but they are nice to make your code more readable. If they had used the words SUB and FUNCTION in an object, it would have caused confusion to people familiar with OOP.

Using the terms method and property also makes it very apparent that you can't simply call a method from, for example, your PBMAIN routine. Imagine the confusion to a new programmer who includes the source code for your object in their own code and then try to call a "function" in your object directly (Result = CalcTotal) instead of calling a "method" (Result = myObj.CalcTotal). New users wouldn't understand why they couldn't directly call the CalcTotal "function" but if it is called a "method" then they have something to look up in the documentation that will hopefully explain to them how to use it.

I didn't call the product guff, I called the jargon used in classes Guff because to me it is a load guff . The documentation for Class needs to be written to normal user of powerbasic who don't understand Powerbasic OOP like me. There needs to be more real examples showing how to use classes. I have already put one example in the object forum to help and I going to put up more when I get them to work (Or when I think I get them to work)

I'm not sure where you are seeing objects being defined with SUBs and FUNCTIONs instead of METHODs and being taught using different terminology. Perhaps Jose is right and you are using some form of programming model in another language that is similar to but not really an OOP implementation.

[Michael Mattias]

Basic Isam files widely used by some many of my clients. The records of there random access files are stored as comma seperated variables

FWIW it's probably not a good idea to bypass the ISAM engine and try to read these data directly.

If you need indexed access, see PowerTree on PB products page. Works good. Not expensive. Skinny documentation, but if you've ever worked with any index-manager type product you'll get the hang of it quickly.

MCM

[José Roca]

Perhaps Jose is right and you are using some form of programming model in another language that is similar to but not really an OOP implementation.

PB has not implemented OOP, but COM. COM classes allow OOP to some extent, but don't expect things such multiple inheritance, constructors with parameters, etc.

What is the name of the topic in the help file? "Objects and COM Programming", not "Objects and OOP".

[Chris Holbrook]

learn COM programming not OOP programming

Succinctly put by José Roca.

Basic Isam files widely used by some many of my clients. The records of there random access files are stored as comma seperated variables

Is there is a dll out there to handle these files?

In these days of SQLIte, MySQL, etc etc who needs ISAM other than in a legacy context?

[Michael Mattias]

>Is there is a dll out there to handle these files?

If you mean CSV (or TSV) files....yes: MSDAO15.DLL, aka "ADO"

[ADDED]

By the way..... You can also access CSV/TSV files as an ODBC datasource if you use the "microsoft text driver". This would allow you to get your data using standard SQL Statements.

I tried this a couple of times. I found the performance quite acceptable for SELECT, but UPDATE, INSERT and DELETE were absolute pigs.

But if your file is a 'read only reference' and you can live without indexed access, it may be a nice option for you.

MCM

[Paul Purvis]

Martin,

I still use CB86 too and why.
For one reason, i have purchased programs that get around cb86s problem areas and give me a heap of routines that run fast, just as fast as pb.

One of my major concerns in conversion from cb86 to pb is the way real numbers are stored. Integers are no problem, but i do not like dealing with real numbers in pb. I know that cb86 will give me the correct results when rounding, mutlipling, and adding real numbers. I am not a fan of the currency types either. But i do understand why and what happens now after that long thread of rounding that we did about one year ago. PB is no different than Microsoft products as far as i have been able to understand.

Rounding badly in my business can mean bad things for you. We are a regulated industry and we get audited yearly plus there are federal laws that can be used to kick your butt in court if you are off just a little.

So for accounting software and if you code runs fine, i say stick to it.
Use Pb where you cannot use cb86.

The only way i know of keeping from having these rounding issues, is to convert reals to integers. That will seem to be a lot of work for something already working.

No, i do not want to start a discussion on rounding either please.

reading to random records
i have not done this but this is how i figure it is to be done.
with cb86, you can write to a random record within a file.
the record can be csv or one variable.
the one variable i use often is one long string the length of the record minus2 characters for CRLF. Fields are positions in the string. CSV in cb86 random records are simply a line of variables, separated by a comma, with strings in double quotes and numbers without quotes. The CSV record will be padded with spaces to any room left over between the length of the record minus CRLF minus the characters that make up the CSV.

One workaround to writing to a cb86 CSV random type record in pb, would be to write the csv to a temporary file, a one liner so to say, then read up the whole line as single string of characters then use that string to write to a random access file's record and you have to pad the string on the right with spaces and add CRLF to the string then write the string to the file.

You would open the file in PB as binary. seek to the position you want to write or get the file data and go from there.

For reading you could get the data as one long string, write that data to a temporary file, close the file then open the temporary file as input mode and read the csv file as usual.

If you keep your records in a single string then define fields within the string at certain positions, converting to pb should be much easier.

I perfer the method of using the binary method of dealing with files using fixed length records with fixed length fiields. I can always see and edit my files with a good text editor such as SPFPC or use any other program to work with the files. I never could stand to use the random file method MSBASIC used or any program using that method. Why, because of computer error and failure, users, and bad electrical source and i could not see the data to edit it if it need to be.

So, if your computer program is complicated and routines already written, it is a big chore to make the change and then you will probably have problems with the real numbers.

CB86 only has two types of number variables, integer and double precision.
I believe it rounds to 13 decimals, not sure i forgot.