PureBasic Forums - English

Firstly let me say, I think PureBasic is great!

I'd like to propose the following list of enhancements which, in my humble opinion, would make it even better.
I'm new to PB, so some of these might already be in the product and I just missed it, there might be valid reasons for them being the way they are, etc. Some of these suggestions I've already made a post before on or were suggestions made by others, this is just my current "hot" list. Each new suggestion is denoted by a "***".

*** Modal windows - Allow windows to be shown in a Modal mode: only 1 window in this specific application can accept user input. No impact on other applications currently running.

*** Structure field references: Allow structure fields to be referenced using a '.' instead of '/'.
e.g. MyStructure(10).myfield = 100, instead of MyStructure(10)\myfield = 100.

*** New PB Constant How about a standard PB constant of #PB_PATHDELIM ?
I try to only write code that is cross-platform. If I ever need to build a file path string, then I could use this PB constant and not have to worry about which platform I'm compiling on.

For example,
On Linux -
#PB_PATHDELIM = "/"

On Windows -
#PB_PATHDELIM = "\"

On OS X -
#PB_PATHDELIM = "/" (MacOS 8 & 9 used ":", OS X allows both)

On Amiga -
#PB_PATHDELIM = "/" (is this correct?)

But in code we just use #PB_PATHDELIM, and so it would be correct for whichever platform we're compiling on:

MyPathString = "HOME" + #PB_PATHDELIM + "BACKUP" + #PB_PATHDELIM + MyFileName

*** Enhance all Window... functions to accept the WindowID as a parameter (optionally?). Several Window functions use the UseWindow() function, then you can call other functions such as WindowWidth(), WindowHeight(), WindowOutput(), etc. It would be nice if I could pass the WindowID to all those functions, instead of having to call UseWindow() first.
e.g. WindowHeight(#myWindow)
Please also apply this to all other PB functions that have similar type requirement, this will make code cleared. Passing in parameters to these type of functions could be made optional to ease transition and no break old code.

*** NOT keyword. Add the NOT keyword for use in boolean expressions.
e.g. If NOT (A > B)

*** Dynamic-length strings - with no 64K limit, only limited by system memory.

*** Dynamic arrays - REDIM or DIM without destroying an existing array's data would be VERY nice! Along with UBOUND.

*** Packer library to allow the use ZIP algorithm / new SetPackAlgorithm function -
I know the current packer algorithm is superior to the zip algorithm but it would be handier to be able to pack data in the zip format AND it would also be easier for you to support the zip packer lib on all platforms since it's so widely available. I'd like to propose to change the packer algorithm to also allow the use of the ZIP algorithm and make the Packer library cross-platform.
zLib is free! http://www.gzip.org/zlib/
Plus, the produced files can then be unpacked by non-PB based apps.
Perhaps just a new SetPackAlgorithm(x) function with the default being the existing JCalG1 algorithm. But SetPackAlgorithm(x) could be used to set to use other algorithms, like ZIP. Since JCalG1 is only on windows, then Linux could use the Packer library using ZIP.

SetPackAlgorithm(0) = JCalG1 (the default anyways to as not to break existing code.
SetPackAlgorithm(1) = ZIP (then all Packer library functions would use the ZIP algorithm)

*** Cross-platform Grid/Table Gadget, Date and Time pickers, all supported by Visual Designer.

*** IDE: When exiting the IDE and if there were changes to the source code, the confirmation box should say "Save before continuing?" or the whole message could be simplified to just say "Save changes to (filename) ?" "Save before continue?" is not quite proper English.

*** SmartUpdate: In a couple message boxes, the word "available" is mis-spelled as "avaiable".

*** Continued emphasis on cross-platform development and limit the number of platform-specific features. Cross-platform is the rage these days and will make PureBasic even more popular (especially with the addition of OS X!). No limits on API access, however.

Overall, You've done some terrific work on PureBasic Fred, et al, please keep up the great work! I'm very excited about the OS X version of PB!
Thanks!

what about keeping the current notation, and use ":" for OOP syntax instead?!?!

LarsG wrote:what about keeping the current notation, and use ":" for OOP syntax instead?!?!

Both are very bad ideas. : is used as Label-Indikator and as seperator between two commands (when you want more than one commands in a line).


And why should we ALL (!) change our code?

*** New PB Constant How about a standard PB constant of #PB_PATHDELIM ?
I try to only write code that is cross-platform. If I ever need to build a file path string, then I could use this PB constant and not have to worry about which platform I'm compiling on.

For example,
On Linux -
#PB_PATHDELIM = "/"

On Windows -
#PB_PATHDELIM = "\"

On OS X -
#PB_PATHDELIM = "/" (MacOS 8 & 9 used ":", OS X allows both)

On Amiga -
#PB_PATHDELIM = "/" (is this correct?)

Windows allows both "/" and "\", so when you write multiplatform, use simple "/" and you should not have any problems.

btw.: Forget Amiga. This time is over.

>* Enhance all Window... functions to accept the WindowID as a
>arameter (optionally?).

Same for files and all Libraries other libraries.

>*** Packer to use ZIP algorithm instead

Is Zip free to use? I think, that you must pay a licence...

>*** What happened to the Timer PureLibrary? Was this cross-platform?

No, a userlibrary and Danilo writes a new Library and then is the possibilty of double names.

>*** Continued emphasis on cross-platform development and limit the
>number of platform-specific features.

When you want, that API and so one is disabled: NO NEVER! Or i want my money back!

GPI wrote:

LarsG wrote:what about keeping the current notation, and use ":" for OOP syntax instead?!?!

Both are very bad ideas. : is used as Label-Indikator and as seperator between two commands (when you want more than one commands in a line).


And why should we ALL (!) change our code?

Perhaps you're right.. maybe "->"

The : should only be used for labels. It : in basic, it : in assembler and in a lot more languages! the . is quite a nice idea!

Variable declarations -

Both are very bad ideas. : is used as Label-Indikator and as seperator between two commands (when you want more than one commands in a line).

I agree, ':' would be a bad choice to use in PB variable declarations. I'd still like to be able to use '.' instead of '\' in structure field references and hopefully we can also use '.' notation when Fred enhances PB to allow OOP.

Path delimiter -

Windows allows both "/" and "\", so when you write multiplatform, use simple "/" and you should not have any problems.

I did not know that! As "/" is now valid on OS X I think we're covered!

zip -

Is Zip free to use? I think, that you must pay a licence...

Nope, Zlib is now free, even for use in commercial applications! Source available. http://www.gzip.org/zlib/

Cross-platform -

When you want, that API and so one is disabled: NO NEVER! Or i want my money back!

I never suggested the API be disabled, just that most functionality be also available on Linux (and soon OS X). Many features are Windows-only.

Thanks for the feedback! I'll EDIT my original post accordingly.

then, go download the dll.

Maybe someone should make an userlib. Should be simple using

Tailbite(pb source to lib):
http://pureproject.reelmedia.org/module ... rch&query=

and the dll http://www.zlib.net/zlib121-dll.zip


Then both zip and normal packer can be used. Zip will then be optional.!

There is allready a ZIP userlibrary.

Timo

i'd love to be able to use the dot . for fields of structs and objects

i guess codewise it should be possible although it might cause a lot of work for poor fred (still got a lot on my wishlist )

Windows allows both "/" and "\", so when you write multiplatform, use simple "/" and you should not have any problems.

This does not hold true when using network paths.
\\Server\MyFiles ...works
//Server/MyFiles ...will not work.

This does not hold true when using network paths.
\\Server\MyFiles ...works
//Server/MyFiles ...will not work.

Uh oh, I guess I better add this request back in. It would probably be among the easiest to implement anyways, just a simple constant change for each platform.

< ..3 years later >
another thing about "/" under windows is, that for example if you start other progs from PB, with any kind of path informations, you must be sure that prog can handle it too. the same for (third-party-)procedures that operate on path strings.
< ..to be continued in 2010(?)>

Egads! I didn't realize until I hit the comment about UseWindow() that I realized this post is three years old!

#NULL wrote:Another thing about "/" under windows is, that for example if you start other progs from PB, with any kind of path informations, you must be sure that prog can handle it too. the same for (third-party-)procedures that operate on path strings.

If you're concerned about "" and "/" being OS-specific you can make your own global variables or constants either at runtime or at compile time by using either Compiler Directives or OSVersion().

The help entry for Compiler Directives gives an excellent example of this.

sure, thats how you do it right now. still a constant would be nice.