Hello!
I think it would be very nice, if there would be #PB_Constants for every command.
For example, the MessageRequester()*,** has its own constants, even Round()* got new constants.
But what about commands like ReplaceString()*? It's a bit annoying to look up everytime what 1 and 2 stands for (regarding the Mode-Parameter).
By in troducing constants, the coder still has the choice wether he/she uses them or not. Coders, who use constants (I even use #PB_MessageRequester_YesNoCancel all the time, although it's much to type) can increase the readability of their code; also people, who read codes from other programers, benefit from this.
Please, go through all commands and add constants for commands that I currently cannot remember. The onliest commands I've got in my mind are Sprite3DQuality()*, FlipBuffers()* and CompareMemoryString()*,**
P.S.: Maybe it is really time to create a new page in the manual containing a table showing which constant has got which value.
* ) This command should have constants for its parameters
**) This command should have constants for its returning values
[Implemented] Introduce constants for every PB command!
[Implemented] Introduce constants for every PB command!
PB 4.30
Code: Select all
onErrorGoto(?Fred)
I will add constants for the commands you mentioned.
> P.S.: Maybe it is really time to create a new page in the manual containing a table showing which constant has got which value.
One reason for using constants is that they can have different values for each OS without any changes needed on the coder's part.
For example the #PB_Event_... or #PB_Shortcut_... constants have very different values depending on the OS.
Publishing a list would defeat this purpose, as it only encourages people to use the numeric values out of lazyness (less typing),
but kill the crossplatform compatibility along with it. This can already be seen on some code posted here in the forum and its not a good trend imho.
> P.S.: Maybe it is really time to create a new page in the manual containing a table showing which constant has got which value.
One reason for using constants is that they can have different values for each OS without any changes needed on the coder's part.
For example the #PB_Event_... or #PB_Shortcut_... constants have very different values depending on the OS.
Publishing a list would defeat this purpose, as it only encourages people to use the numeric values out of lazyness (less typing),
but kill the crossplatform compatibility along with it. This can already be seen on some code posted here in the forum and its not a good trend imho.
quidquid Latine dictum sit altum videtur
These are the onliest commands, I can currently remember... Maybe I forgot some, that's why I advised you to go through the command index.I will add constants for the commands you mentioned
Thank you!
In gerneral I would say, that it depends on the coder... He/She should have the choice.as it only encourages people to use the numeric values out of lazyness (less typing),
Of course your're right it would be nice, if you use constants, but the user bought PureBasic, so he can (should) decide.
Even if there would be a constant list, I will continue using constants: You cannot remmeber ALL the values. And personally, I'm interested in a readable code. No matter wether you publish a constant table or not, thos who use numbers can't be stopped.
But the idea of a table was only a suggestion.
PB 4.30
Code: Select all
onErrorGoto(?Fred)
Yes, I know the StructureViewer, but didn't remember it.
OK, then everything is done/planned.
OK, then everything is done/planned.

PB 4.30
Code: Select all
onErrorGoto(?Fred)
Yes, and I just found a "hidden" command: ChangeListIconGadgetDisplay().AND51 wrote:These are the onliest commands, I can currently remember... Maybe I forgot some, that's why I advised you to go through the command index.I will add constants for the commands you mentioned
I don't want to post every single command here that I find, I just want to show that there could be more commands which don't come to your mind easily.
So please, go through the command list, if you have got time.

PB 4.30
Code: Select all
onErrorGoto(?Fred)
Hello!
You might have a deeper look again, as long as commands like FileSize() and JoyStickAxisX()/JoyStickAxisY() are unprocessed, too.
You might have a deeper look again, as long as commands like FileSize() and JoyStickAxisX()/JoyStickAxisY() are unprocessed, too.
PB 4.30
Code: Select all
onErrorGoto(?Fred)
Constants for FileSize()
*BUMP*
In order to keep consistency, FileSize() should have it's own constants:Is this luck or done on purpose, can you guarantee that this also works in future versions or will there be extra constants? 
In order to keep consistency, FileSize() should have it's own constants:
Code: Select all
#PB_FileSize_File = -#PB_DirectoryEntry_File
#PB_FileSize_Directory = -#PB_DirectoryEntry_Directory

PB 4.30
Code: Select all
onErrorGoto(?Fred)