Hello Artur / Phil / Costas,

first, a short update for those here that don't follow the ibobjects
ng - i wrote there:

>If you include the frmGDS32 unit (source code below) as the very first
>unit in your program, you'll have a FB client all-ready-to-go, adding
>only about 200kb to the size of your exe. (the dll is ~352kb, but my
>TffPersistentFile component uses TNanoZip to store it in zipped form
>inside the dfm; the 200kb include the TNanoZip code and the form with
>the zipped dll). When you launch such an app, it will unzip the dll
>and tell IBO to use it.

here's a really minimalistic example of how it works:

http://www.fingerbird.de/downloads/IBONanoBrowser_src.zip
(sources only, ~140kb; you'll also need nanozip v1.45 and IBO)

http://www.fingerbird.de/downloads/IBONanoBrowser_exe.zip
(exe only, ~660kb)

Phil Shrimpton wrote:

>> do we really need the messages file (interbase.msg) or not?
>
> No. If it is not there, the error message you get will be less than
> descriptive, but if your app is handling exceptions properly the user should
> never see 'pure' Firebird exceptions, just (hopefully) 'User friendly' ones
> produced by your app.

imho it is good practice to never show an error msg to the user the way
it comes from the engine, but "reformulate" it to sthg. useful and
understandable - and most of our (german) users wouldn't understand ISC
error msgs. anyway :-) so lack of interbase.msg is not an issue to me.

Phil wrote:

> For client apps all we do is include gds32.dll and put it in the application
> directory, that way we can have multiple apps using different versions of
> FB/IB on the same machine.

...and Costas wrote (in IBObjects-ng):

> The problem as I see it, is not whether it works or not, it is just good
> practice not to arbitrarily fill the disk of a client pc with
> gds32.dll's. What happens if the client pc has already an IB/FB client
> installed? It will probably work but isn't it confusing if you ever want
> to troubleshoot?

there's two sides to this (putting gds32 into the exe dir w/o "official
installation"):

con:
- other IB/FB apps on the same machine all have their "private copy" of the
dll, wasting disk space and memory (when they run simultaneously)
- otoh, who cares about disk space nowadays, and memory usage,
when XP alone eats 100 mb or so?

pro:
- other IB/FB apps on the same machine all have their "private copy" of the
dll<g>, thus ensuring that you can have an old IB5.6 app (which uses
gds32 from the system32 dir) along with a FB1 app and an FB1.5 if you like
- though i'm not shure if this will really work, but my tests so far
haven't shown any showstoppers.

unless someone comes up with a case where it wouldn't work (or it violates
IPL or so...), i'm tempted to adopt the method with the zipped dll inside
the exe as a standard for all my forthcoming projects...

One thing i'm really uncertain about is: what happens when two client apps
use this method with the same gds32.dll, but stored under different
filenames? i recall issues with Named Pipes for the FB *server*, are there
similar probs for the client??

regards,
fingerman

--
-------------------------------------------------------------------------
when parsers parse, and compilers compile, then why don't objects object?

fingerbirdy - fingerman's door to Firebird
http://www.fingerbird.de