PureBasic 5.10 - Granted wishes release - is out !

[X]

Congrats! My eyes kind of blurred over the list as there were so many great things in it.

A quick question in case I have missed it, is it now possible to color 2d surfaces?

[ebs]

Hi Fred,

Thank you for all the work put in on this 5.10 beta release.

I'm doing some testing and I noticed something odd:
I'm running Windows XP SP3 and if I have the Windows Media Player running,
the PureBasic IDE will lock up on the initial splash screen and never gets to the IDE screen.
When I shut down WMP, the IDE loads successfully, but will lock up at random times if I restart WMP after loading.

I most often use jaPBe, so I don't know if this behavior is new, or if it is specific to my PC,
but I don't remember having this problem with the version 4.XX releases.

Regards,
Eric

[kenmo]

Finally I can play with the 5.10 beta.... I was thinking about it all week These are my personal favorites:

Code: Select all

- Added: CocoaMessage() for OS X
- Added: 'Check syntax' to only compile the code without build/running an executable (/CHECK switch or in the IDE compîler menu)
- Added: Multicharacter comparison in StringField()
- Added: Timeout, LocalIP$ and LocalPort parameter to OpenNetworkConnection()
- Added: GetSoundPosition(), SetSoundPosition(), SoundLength(), PauseSound(), ResumeSound(), SoundStatus()
- Added: #PB_All support for SoundVolume()
- Added: InputRequester() added #PB_InputRequester_Password flag
- Added: Support for FreeXXX(#PB_All) for all free commands
- Added: Compiler Constant: #PB_Compiler_IsIncludeFile, #PB_Compiler_IsMainFile, #PB_Compiler_Filename (filename without path)
- Added: Bool() compiler operator. Boolean operations are now forbidden without Bool().
- Added: CompilerElseIf
- Added: UpdateMesh(), EnableManualEntityBoneControl(), MoveEntityBone(), RotateEntityBone()
- Changed: disallow native type for pointers

Also:

Code: Select all

- Added: Line continuation feature, with the following operands: ',' '|' '+' And Or Xor

Any reason it's not enabled for '&' '*' '/' '-' etc?

[Poshu]

°_°; Somehow, I feel like this 5.10 is a greater milestone than than the 5.00 was.

Well, if some ironing on the linux version of the IDE could be made, PB would be like... Perfect?

[dige]

I'm confused a bit. The Pointer issue does not affects me, because structured pointer still possible.
But an important note. New features initially had no constants but numbers as parameters. For example StrU ().
This should now be converted into the corresponding PB necessarily constants, since the assignments have changed.

Code: Select all

                  ; PB 5.10   ; PB 4.61
Debug #PB_Byte    ; 1         ; 0
Debug #PB_Ascii   ; 24        ; 8
Debug #PB_Word    ; 3         ; 1
Debug #PB_Unicode ; 25        ; 9
Debug #PB_Long    ; 5         ; 2
Debug #PB_Quad    ; 13        ; 4

[sartic]

"Removed: SendNetworkFile(), RecieveNetworkFile(), #PB_NetworkEvent_File to avoid possible security hole"

do not like it i have one old program that use this 2 commands.
maybe it is time to rewrite it

[Psychophanta]

Many many many... THANKS Fred and ALL PB staff

[grabiller]

Thanks for the new release Fred.

And thanks for the UndefineMacro :-]

Great release Thanks Fred and the Team!
but .. "disallow native type for pointers" .. brings me a lot of work

Yes, this was a pain for me too, but I changed my C header converter from *pointer.nativetype to *pointer_nativetype. So really, not as bad as I initially thought.

I'm a bit puzzled though about the benefit to forbid *pointer.nativetype. I understand on your side it's useless, but on our side it is very useful when we create prototypes or procedure declarations when importing libraries. It's an elegant and simple way for us to keep track of what kind of data a pointer points to.

Now we have to embed the type in the name of the variable or write comments, which is far less efficient. With previous versions, it does not hurt to have *pointer.nativetype right ? Plus now it breaks consistency as we can use structure types on pointers but not atomic types anymore. Just.. why ?

This kind of sudden limitation makes us feel treated like children by a professor who decide rules to make him more comfortable, but forgot about the comfort of his students.

In short, what's the real benefit of this ? I see none. Only drawbacks (revisiting hundreds or even thousands of lines of code/interfaces/prototypes/procedures, time better spent to actually do coding).

Can you not put this as a compiler toggle/option or something ?

[itto]

mother of god *_*

[Fred]

Thanks for the new release Fred.

And thanks for the UndefineMacro :-]

Great release Thanks Fred and the Team!
but .. "disallow native type for pointers" .. brings me a lot of work

Yes, this was a pain for me too, but I changed my C header converter from *pointer.nativetype to *pointer_nativetype. So really, not as bad as I initially thought.

I'm a bit puzzled though about the benefit to forbid *pointer.nativetype. I understand on your side it's useless, but on our side it is very useful when we create prototypes or procedure declarations when importing libraries. It's an elegant and simple way for us to keep track of what kind of data a pointer points to.

Now we have to embed the type in the name of the variable or write comments, which is far less efficient. With previous versions, it does not hurt to have *pointer.nativetype right ? Plus now it breaks consistency as we can use structure types on pointers but not atomic types anymore. Just.. why ?

This kind of sudden limitation makes us feel treated like children by a professor who decide rules to make him more comfortable, but forgot about the comfort of his students.

In short, what's the real benefit of this ? I see none. Only drawbacks (revisiting hundreds or even thousands of lines of code/interfaces/prototypes/procedures, time better spent to actually do coding).

Can you not put this as a compiler toggle/option or something ?

We don't change things if it's not necessary, or only to annoy you. The problem was than it was confusing for beginners, as they didn't understand the difference between *Pointer.l and *Pointer.f. And for a good reason: there is none. Now, you will have to use the long syntax if you want to keep track of pointed thing, and while it's a bit longer to type, it also makes sens, which is the main goal for us: be consistent. You can write: *Pointer.Long and *Pointer.Float.

[IceSoft]

We don't change things if it's not necessary, or only to annoy you. The problem was than it was confusing for beginners, as they didn't understand the difference between *Pointer.l and *Pointer.f. And for a good reason: there is none. Now, you will have to use the long syntax if you want to keep track of pointed thing, and while it's a bit longer to type, it also makes sens, which is the main goal for us: be consistent. You can write: *Pointer.Long and *Pointer.Float.

But It is not consistent for ProcedureReturn pointers.

[Little John]

But It is not consistent for ProcedureReturn pointers.

What do you mean with "ProcedureReturn pointers"?
Could you please provide some small code that illustrates your point?

Thanks, Little John

[IceSoft]

But It is not consistent for ProcedureReturn pointers.

What do you mean with "ProcedureReturn pointers"?
Could you please provide some small code that illustrates your point?

Thanks, Little John

I can not define the pointer type as return value.

Here a pseudo code example:

Code: Select all

Declare.<pointer of structure> myProcedure()

This example raising an syntax check error (of course, it is a structure as return value not a <structure pointer>)

Code: Select all

Declare.Long test()

[niijel]

thank-you Fred

[STARGÅTE]

thx for #PB_Compiler_IsIncludeFile and #PB_Compiler_IsMainFile!
Now I can add a sample code in the include, and it will not compile if it is included, only if the include run alone.