Concern and suggestion regarding new PB releases

[ozzie]

I've been working on converting a large VB6 project to PB but have had to put that project on hold due to an outstanding bug in PB, reported here: Trying to sort out memory crash. Due to the widespread use of complex structures in my project, this bug is a show-stopper for me - there's no easy work-around.

My concern is that there's no sign of this bug being fixed, and we haven't seen even a Release Candidate of a new version of PB since 4.51 was released in September last year. Not many reported Windows bugs are being marked as [Done].

Which makes me wonder if enthusiasm for the project is wearing off in PB HQ? If so, maybe Fantaisie Software should consider charging an annual maintenance fee as well as the initial purchase price. I would be happy to pay a reasonable annual fee if it results in faster responses to bug fixes.

[c4s]

Just a few days ago Freak said that the new version will come soon. Normally there will also come a rush of Done's right before/during the beta phase.

You are right, there really should be more bug fixing releases. I'm waiting for several fixes that are already marked as Done.
But I have to be honest: When I bought PureBasic I already knew how things work here and that it's a very small "hobby" developing team, so I just relax. I mean it's still a great investment and PureBasic keeps on rocking.

[Trond]

Due to the widespread use of complex structures in my project, this bug is a show-stopper for me - there's no easy work-around.

Setting empty string structure fields to "" instead of leaving them uninitialized would prevent the problem, wouldn't it? Or alternatively avoid structure assignment (or write your own function to do it).

Although I can see why it would be a lot of extra work.

[ozzie]

Due to the widespread use of complex structures in my project, this bug is a show-stopper for me - there's no easy work-around.

Setting empty string structure fields to "" instead of leaving them uninitialized would prevent the problem, wouldn't it?

Looks like you might be correct there, Trond. I've just updated the memprob3 test program I used for the 'memory crash' bug report, setting the string variables to "" in the 'default' global structure variables grProdDef, grCueDef and grSubDef, and the program now runs through to completion without error. Comment out the string "" initialisations and the memory error returns.

It will be a lot of work to implement this in my project, but it does look like a promising work-around - many thanks.