Power Basic Releases Version 10 of PB for Windows

[Martin Francom]

Paul,
    Have you been able to play with any early releases of PB-Win Version 10? 
     How will it effect FF3  ? 
     The PowerBasic Gazette I just received lists alot of new and powerful features. (Hopefully no conflicts with the current FF)

[Patrice Terrier]

Marty,

There is no PB's special policy for third party addon providers, i think Paul will discover it at the same time you will get it

...

[Douglas McDonald]

I haven't gotten PB 10 yet but I will as soon as I can. I also wondering how it will effect FF3. Seems to me it will make Paul's life simpler in the long run. I bet he will now be able to do a lot more cool things. There are many cool neat things listed in the PB gazette and I can't wait to dig in. Its another $200, $99 ea for PB 7 SQL tools but I know it will but I know it will be worth it.

Maybe Paul can fill us in on what effects it will have on FF3 if any.

Merry Christmas
Doug

[José Roca]

If you use the currently available headers (mine or the PB ones) and don't use the new features, it won't affect in anything.

If Paul wants to take advantage of the new features, such native unicode support, and I bet he will want it, then some small changes in the generated code will be needed. I will help Paul to do it if needed.

The problems will come if he wants to support both older compilers and the new features of the new ones. If I were Paul I will keep FireFly 3 as it is and write FireFly 4 with the needed changes. His life will be much easier, without having to move declares from this to that, writing each function in a separate file to avoid bloat (with dead code removal this is no longer needed), etc.

I'm ready. The new version of my Windows API Headers allows to work with ansi or unicode transparently just by defining %UNICODE = 1 or not, but as they use the new WSTRING and WSTRINGZ data types, can't be used with older compilers.

[Douglas McDonald]

If a FF4 is what it takes then I'm all for it.

Doug

[Rolf Brandt]

Also, could someone compare SQLITENING with their new "SQL Tools Version 3 that needs no DLLs"

I like the sound of "no DLLs"... but wonder how it compares to SQLITE???

No DLLs is no problem for SQLitening either since Fred gives us the source code. You can easily use the code as include file with a minimum of changes. Like this you have the SQLitening Client functionality in your exe file. (You still might need zLib.dll though. See SQLitening helpfile under Project Files.)

Attached is a little sample project for a NoDll client application using SQLitening. (You need the sample.db3 provided by Fred Meier in the SQLitening package.)

Note that I renamed the original .Bas files to .Inc. The only differences in these files are that I removed the compiler directives, some double equates, and the EXPORT statements. I had not made any changes to SQLiteningAuxRuts yet.

[Rolf Brandt]

The SQLitening Server needs Zlib.dll, on the client side it is only needed if you are using compression in local mode.

That cuts it down to sqlite3.dll which is already present on most systems.

What I like about SQLitening is the ease of use, the ease of setting up and configuring a client server system. Syimply said - as you might notice - I am a SQLitening fan!

I can't say anything about SQL Tools because I have never used them.

[Haakon Birkeland]

I can't say anything about SQL Tools because I have never used them.

It's fairly interesting if one have to deal with Access â€" and MS SQL when one grows past Access' limitations. Not everyone have the luxury of being able to choose the data source.

[Rolf Brandt]

Hi Haakon,

sure - depends of course on the type of databases you need to access. SQL Tools gives you more options here. But if you are in a closed environment without need to access other database types SQLitening is a wonderful tool.

[Paul Squires]

I am not involved in any PB10 testing. I have no idea how it will impact FF3 - we'll have to wait and see until I purchase the upgrade in a few weeks.

Some of the announced features sound interesting. I love how PB have now implemented static link libraries after shitting all over that idea for years. I guess enough people must have requested it and they relented to the demands finally. The Boss man will be happy to finally be able to link his EZEE engine.

I figured that they would have addressed the idea of having a container for visual ActiveX controls. Maybe they have but are holding that information back. Right now, we are using Joe's wonderful container control.

Maybe a new IDE and Debugger that brings us into line with 2010 standards would be nice too. Actually, I think that I will hold off and eventually use Jose's new editor that he is working on. Too bad that PB doesn't open up the Debugger file format so we can create a better debugger ourselves.

Oh, yes, and complete implementation of forward referencing would be beneficial for FF3 so I wouldn't have to collect all declarations, globals, types, classes, macros, etc... and assemble them in the _DECLARES file.

Merry Christmas everyone! Turkey dinner in less than two hours from now. 

[Paul Squires]

The problems will come if he wants to support both older compilers and the new features of the new ones. If I were Paul I will keep FireFly 3 as it is and write FireFly 4 with the needed changes.

Yes, that does sound like the best approach. Supporting legacy compilers is always a problem. Maybe FF4 is a good idea for PB10 only support.

[José Roca]

If you drop support for older compilers, adding unicode support is easy. Just define %UNICODE = 1 before any #INCLUDE and use WSTRING instead of STRING, and WSTRINGZ instead of ASCIIZ, and a couple of minor changes more. Otherwise, you will need to have paths for four sets of include files -two for mine, and two for PB-, since older compilers can't use the new ones.

It's time to take advantage of the new features and not be constrained by legacy compilers. Current uers can use FF3 for existing applications and FF4 for new ones.

IMO static libraries are mainly useful to people that have code to hide, and very cumbersome to make if you want to avoid bloat. Include files are more versatile, since dead code removal is automatic and you can also make use of conditional compilation.

My two most wanted features were native unicode support and dead code removal, and both have been implemented perfectly, and I have tested them very thoroughly. Unicode is very important to people that doesn't use English and can open new markets for the compiler. It is also very important to use COM: no more ACODE$/UCODE$ and no more workarounds to deal with methods that use null-terminated unicode strings (unicode ASCIIZ strings). Dead code removal has allowed me to get rid of the macro functions (no more %USEMACROS) previously used to avoid bloat. For example, I have written an include file with wrapper functions for each ane every one OpenGL extensions (1,720, no less), and only the ones called will be incorporated in your code. Now you can use OpenGL extensions with PB more easily than with C. I have also one for ODBC with hundreds of functions and I will write more and also classes.

[Haakon Birkeland]

The Boss man will be happy to finally be able to link his EZEE engine.

Another feature to drown in his long list with gibberish.

Maybe a new IDE and Debugger that brings us into line with 2010 standards would be  nice too.

Nah. when it comes to making applications with/for their compiler that incorporates a UI and sensible user logic, they just don't seem to get a grasp on reality, it's needs and desires. I bought their best attempt and shortly thereafter it was archived and never installed again.

[Douglas McDonald]

Paul, I would be very open to buy an upgrade. This seems to be a major change. Your work on it deserves a payment.  I know its a year out probably but it would be welcome. It sounds like there are some very cool things you could do.

Doug

[Martin Francom]

Yes, I too would purchase an upgrade.