I just wanted to give everyone a summary of where things are with EWB right
now, given that things have been quiet for a while now.

I'm (finally) done with the port of ElevateDB to Linux, including the
ElevateDB Server and ElevateDB PHP Extension.  Both are available for 32-bit
Linux, and will also have 64-bit support within the next couple of months.
In addition, I have a generic dataset layer coded in PHP that uses the
ElevateDB PHP Extension that will be available with a new EWB build next
week.  If you already own the ElevateDB PHP Extension, or need it sooner
than next week, just let me know and I'll email it or post it here.  This
generic dataset layer will also be available for PDO database operations,
probably within the same timeframe as 64-bit.  However, if anyone wants to
try doing it themselves, they certainly are welcome to try.  The dataset
layer is pretty easy to understand and is implemented using PHP classes, so
it's a simple matter to implement for a new database engine, provided that
one knows the target database engine well.

If you already own EWB, you are eligible for a 50% cross-product discount on
any of the ElevateDB PHP Extension products, so please be sure to use this
discount when ordering.  You can select special offers when adding a product
to your shopping cart on the web site.

As stated above, the next build of EWB should be available next week.  It
will primarily include just bug fixes, along with some minor improvements.
The main goal of this build is just to get out some fixes that have been
sitting for a while and address some outstanding issues like the compiler
giving scope preference to built-in functions.   I'm also going to try and
squeeze in a command-line compiler.

After the next EWB build, the "big push" will be coming in the form of EWB
2.0, which I want to have released before Christmas (preferably
Thanksgiving, but Christmas is the pessimistic date).  EWB 2.0 will feature
new form designer capabilities (better transparency support, among other
things), a new theme format with more flexible styling, installable 3rd
party components, and installable database engines.  However, this *will*
mean that certain components like tabbed notebooks, etc. will be postponed
until EWB 2.0 is out.  The main issue with doing them first is both the time
involved and the fact that doing new major components will simply require
that they be re-written to handle the new theme format in EWB 2.0, and I'm
really against making myself re-write brand new code.

Thanks for your patience lately.  I know things have been "slow" in terms of
output, but our development/build system is now completely capable of doing
cross-platform with ease, and this will make things easier for deploying EWB
back-end support with PHP.

Feel free to comment or ask any questions at all.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

The command line compiler or somem kind of API would be nice to have in the next release.

Thanks for the update.

Leslie

I was going to say that, but didn't want to jinx it. 8-)

/Matthew Jones/

Hi Tim

One thing I need is the ability to handle IFDEFs. I need a way to share
OP code and I think the easiest way to do this would be to have my
shared code in EWB files and Include them in my Delphi units.

Looking forward to the new styling approach - definitely agree with
delaying new components until that's done.

Cheers, Bob

I agree it would be nice to have #IFDEFs, but with a command line compiler you can
achieve something equivalent just using variables. I had a web version and PhoneGap
version that behaved differently according to a variable set in the startup code.
The intention is to set those in a build script (modifying the file) and then run
the command line.

/Matthew Jones/

But I need to import EWB files and compile within Delphi - given that
EWB OP is a subset it seems the simplest approach. This way I also don't
need to have EWB handle .pas files.

Cheers, Bob


On 09/10/2013 14:20, (Matthew Jones) wrote:
> I agree it would be nice to have #IFDEFs, but with a command line compiler you can
> achieve something equivalent just using variables. I had a web version and PhoneGap
> version that behaved differently according to a variable set in the startup code.
> The intention is to set those in a build script (modifying the file) and then run
> the command line.
>
> /Matthew Jones/
>

Ok I see what you mean - that would work both ways. Never used a build
tool with Delphi but looks like I might be soon...

Thanks, Bob


On 09/10/2013 14:20, (Matthew Jones) wrote:
> I agree it would be nice to have #IFDEFs, but with a command line compiler you can
> achieve something equivalent just using variables. I had a web version and PhoneGap
> version that behaved differently according to a variable set in the startup code.
> The intention is to set those in a build script (modifying the file) and then run
> the command line.
>
> /Matthew Jones/
>

Sounds good Tim, thanks for the update.

> Never used a build
> tool with Delphi but looks like I might be soon...

Get yourself to http://www.finalbuilder.com/ instantly. Anyone not using a build
tool to get a consistent, reliable build is mad! Whether you are using it on a
project you build every day, or once a year, it has a lot of value. I have
customers who want some minor change made, say a single string modified, and I
*know* that the build will be a good one and I'll not have forgotten to take out
some debug DEFINE or didn't authenticode it, and that the result is uploaded to the
usual place and an email sent, and the lot checked into the version control. And
that will be the benefit of a command line for EWB.

/Matthew Jones/

Must agree - having been using Subversion/MSBuild in recent years for
..NET projects it's been on my to-do list as I ramp up Delphi development
again. The need to get some way to use common code across EWB and Delphi
has also been part of that.

Cheers, Bob


On 10/10/2013 09:07, (Matthew Jones) wrote:
>> Never used a build
>> tool with Delphi but looks like I might be soon...
>
> Get yourself to http://www.finalbuilder.com/ instantly. Anyone not using a build
> tool to get a consistent, reliable build is mad! Whether you are using it on a
> project you build every day, or once a year, it has a lot of value. I have
> customers who want some minor change made, say a single string modified, and I
> *know* that the build will be a good one and I'll not have forgotten to take out
> some debug DEFINE or didn't authenticode it, and that the result is uploaded to the
> usual place and an email sent, and the lot checked into the version control. And
> that will be the benefit of a command line for EWB.
>
> /Matthew Jones/
>