PowerBasic requests...

[mark smit]

Hello all...

I was thinking about what sort of things I would like to see in the next release of PBDLL and I came up with the following...

1. make MKWRD$/MKDWD$ and all other variants act more like CHR$. Here is an example: CHR$(23,65,2), MKWRD$(32767,2048,257). This makes for cleaner looking code.

2. make CVWRD and all other variants act more like ASC. Here is another example: n = ASC(buffer$, 3), n = CVWRD(buffer$, 8). This would also make cleaner looking code and more flexability.

3. Allow for user defined variable type like #USERVAR MYBYTE = BYTE. This will allow us to change a variable type for the whole scope of the program with one line. This also allows variable types like HWND, WPARAM, LPARAM, LPSTR.

4. I suppose that having functions inside a TYPE would be out of the question right now, but still, I think it would be cool. It would provide better organization of functions and variables.

5. Floating point constants would really be handy. %PI = 3.14159

6. I understand that this next request might be the rope that hangs me but what the heck. Being able to turn off DDT and TCP/UDP/IP functions with compiler switches so that we can once again make use of the reserved words. Or...

7. Maybe make the variable and function naming more flexable so that we can still make a function called "SEND" or DIM a variable with a reserved word. Nothing bugs me more than wanting to use a name for a function or variable and not being able to use it. DATA being the one I run into the most...

8. Possibly could we swap "CALLBACK FUNCTION" with "FUNCTION CALLBACK". I just think it would make things a bit cleaner to look at.


9. I dont know how to explain this one so I'll just make an example of what I mean. DIM VARIABLE = 256 AS WORD, DIM VARIABLE = "PowerBasic" AS STRING...

TYPE MYVAR
A AS WORD
B AS WORD
END TYPE

DIM VARIABLE = (25,32) as MYVAR

I hope I haven't made anybody at PowerBasic angry with this message. These are just little ideas that keep poping up with the compiler that I would love to see. I would go as far as saying "I would sign a lifetime contract stating that If the above changes were implimented, I would most definitly commit to purchasing every new compiler that PowerBasic would make!". I probably will anyway but I thought saying that would give me some leverage (smile)...

Cheers! to a wonderfull product and staff...

[Tom Hanlin]

Thanks Mark! We're always glad to hear new ideas. Your suggestions have been added to The List of prospective new features for PowerBASIC.

------------------
Tom Hanlin
PowerBASIC Staff

[Thierry Vanmarcke]

Mark, since no-one from powerbasic seems to be angry with your message I'll add my own small wish.
It bothers me that if I type endif in the IDE instead of "end if" (with a space), this isn't recognized. If something can be done about it I'll be glad.

Just asking ....

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

[Cecil Williams]

While we're at it, it would be nice to have the following:

Asin(x)
Acos(x)

These would be nice built in library functions rather than
having to use a modified homegrown fn using ATN to suit.

Cheers,
Cecil

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

[mark smit]

I couldn't agree more.

I was begining to think that I was the only one with these requests. I wouldn't mind being able to comple .RC files right from the IDE!

There are a number of syntax highlighting quirks that I would like to see fixed but thats just minor. example: "accept" doesn't seem to be highlighted but it is a reserved word.

Being that the text print function is no longer supported in PBDLL, why not remove the need for the "#" symbol for file numbers/handles. If you try and use "print hfile, buffer$;" then compiler responds that you should put a number sign in front of the handle "print #hfile, buffer$;" but this seems to be the only place it does this.

Heres just a question I would like to know. Why do all the built in string functions require the "$" symbol. Is it because that is how the compiler parses the text or is it for compatability with older basic's?

Cheers!

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

[K Peel]

Three from me!

Matrix functions on string arrays, variable length UDT strings and 'real' arrays within types.

Thanks,


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

[Tom Hanlin]

Thanks, guys! All your fine suggestions have all been noted down for future reference.

Mark, on the subject of being able to compile .RC files right from the IDE-- you can do this already! About string functions using the "$" symbol-- it's traditional and still seems like a useful design.


------------------
Tom Hanlin
PowerBASIC Staff

[mark smit]

Hello Tom!

I stand corrected on the resource compiling, but only %50!
when I try and compile a .RC file the ONLY file that get created is the .RES file, NO .PBR to be found! I have checked all my setting and they point to RC.EXE and PBRES.EXE. I even went as far as to check the Registry...

Cheers!

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

[K Peel]

This maybe a very long shot (and may be impossible - I haven't any idea about how a compiler 'compiles'), but what about somehow checking subs and functions in your code and if they aren't called anywhere, don't add them to the full compile (sort of 'intelligent' compiling)

As I said, it may be *impossible* but imagine the possiblities for faster + smaller code (if that is possible )

Regards,


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

[mark smit]

Hello K Peel!

To the best of my knowlage, PowerBasic already does this. Give this a try...

1. Write program with a couple of big sub routines.
2. only make a call to one of them and compile.
3. write down the file size.
4. edit the code to call the other subs that you left out.
5. recompile and check the file size again.

I bet the file size will be much bigger...

Cheers!

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

[Eric Pearson]

Mark --

> To the best of my knowlage, PowerBasic already does this.

The PB/DOS compiler does "weed out" unused subs and functions, but the Windows compilers do not. PB/DLL was originally designed to produce DLLs (hence the name) and the whole idea of a DLL is to create subs and functions that can be called by external programs. It is very common to have subs and functions that are not called within the same executable module. (In fact subs and functions in PB/DLL and PB/CC EXEs can also be called by external programs.) So there is no way for the compiler to know which ones are not really "necessary" at compile-time.

True, subs and functions that are declared as PRIVATE, not used with CODEPTR, and a few other restrictions could theoretically be stripped out. So "stripping" does belong on the current wish-list.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[John Petty]

Another small wish list
First for the compiler
1. String arrays in UDT's, this shouldn't be difficult as the UDT only keeps a pointer anyway
2. a reverse VARPTR instruction, i.e. set a variable to have its contents at the location defined by a pointer, particularly for strings. This is actually done when calling a sub or function, however can't be done within a sub or function. The major problem would seem to be the memory leak with strings but this is obviously taken care of when passing a string to a sub.

Second for the editor
1. fix the bug which causes the last typed line of code to be lost if you move to a prior line and edit without first having used the enter key.
2. repeated capitalistion of dimmed variables (as in VB 6 editor). this means you don't have to wait for the compile with option explicit to tell you that the variable has not been dimmed as using some upper case letters in your dimmension statement and all lower case when typing code gives an instant indication that you have misspelled the variable name.


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

[Eric Pearson]

By the way, I've been visiting various PowerBASIC BBSs for a very long time, and I've never known anybody at PowerBASIC to get "angry" when somebody suggested a feature. Not even once!

Some people have made a habit of suggesting the same features over and over and over, often without explaining the benefits of their idea, and that does get a bit tiring, so sometimes the responses from PowerBASIC have been a little terse. And if somebody phrases a suggestion like "PowerBASIC is a worthless piece of junk unless you add..." or "The way (x) currently works is really stupid" then yes, they can probably expect a negative reaction.

But in my experience the great, great majority of user suggestions are greeted with the same type of reponse that Tom Hanlin gave to this thread. Many different PB features over the years have added "by public demand".

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Bob Houle]

Suggestion For PB Editor:

I use the Windows Options to set the Editor Font to Courier New and a font size of 12.

Sometimes a printed copy is desired. With this setting, I get too much wordwrapping, and it doesn't look good visually. I prefer to print at Courier New with a font size of 9.

It would be nice if they added another option just below the present "Editor Font" for "Printer Font".

--Bob

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

[Chris Boss]

Don't forget Static Libraries !

I think Static Libraries are one of the most important needed features in PB. This will open a slew of Third party products. Also it allows "embeding" Libraries in a single EXE, rather than use DLLs. Also the feature mentioned about "weeding" out unneeded subs/functions could be implimented for Static Libraries, with little affect on other considerations.


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

[Florent Heyworth]

There we go again

I also want to underline Static libraries support as well as SEH (Structured Exception Handling) instead of our traditional ON ERROR stuff. I'd also love a pre-processor for INLINE MACROS, define types as well as variable declaration and initialisation in one step, switchable COM support if needed as well as switchable support for OOP porgramming when desired.

Cheers

Florent



[This message has been edited by Florent Heyworth (edited May 13, 2000).]

[K Peel]

Chris & Florent,
I should think static libraries must be topmost of the 'wish' list by now!

If it makes any difference, add my vote!

Cheers,


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

[Chris Boss]

Static Libraries are most crucial, since they can become the building blocks to more advanced features, like COM support. If Powerbasic were to add Static Libraries, then other Third party companies can add features to PB, that PB themselves can't do themselves.

Imagine the Jazzage COM products as a Static Library ?

Imagine someone building a DirectX engine as a Static Library ?

Imagine WinLift as a Static Library ?

Imagine Exxxx (dreaded E word) as a Static Library ?

The concept of components opens the door to many other things. Rather than have the guys at PB invent it all, they should add the necessary tools to PB so Third party companies can expand PBs features.

I can live without all other features, but Static Libraries would be the "Cat's Meow" !

Imagine much of the posted code on this forum, ending up as Static Libraries ?

The only other thing I can say about Static Libraries is:

Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please !


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

[Jim Seekamp]

I would like to re-iterate the need for the user to select
the default extensions for the pbedit.exe.
It doesn't come up with .rc as a default, so you always have to
go to the pulldown, and when you're editing 20-30 or more resource
files one at a time, it can be a pain.
But I still love PBDLL v6.0

Best Regards

Jim


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

[Eric Pearson]

> Being that the text print function is no longer
> supported in PBDLL, why not remove the need for
> the "#" symbol for file numbers/handles

PRINT (without the #) is supported by the PB/CC compiler so the # serves a purpose. If the suggested change was made, PB/DLL and PB/CC would use different syntax for printing to a file, and IMO that would be confusing. I suppose the # could be made optional in PB/DLL programs, but that would result in source code that produced different results when compiled with PB/DLL vs. PB/CC.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>