Hi Jason,

Jason Wharton wrote:

>
> Frank,
>
> I would like to foster the use and integration of Open Source products like
> this. What I think we should do is make it so that you have a compiler
> directive indicating which open source products are installed. This way at
> compile time you can determine which things are added in.

i don't know if i understand "foster" right (don't have an english
dictionary at hands:) but if you mean something like "bring to life",
"keep alive" or "support" i'm with you :-)

> This way people can download separately the OS things they want, install
> them and flip a compiler directive and then recompile IBO packages.
>
> How does this sound?

the way i made this is that you install the *unit* with the TIB_SynEdit
source in an arbitrary package *after* you installed a) IBObjects and
b) SynEdit. Then you'll find a new icon on the iboControls tab with the
image of a TSynEdit.

If i get you right, you'd rather integrate it into the std package with
the ability to ifdef it out if not needed/wanted. This is imho a question
of "package philosphy": What i want as a developer using IBO is a
well-designed, well-performing pkg of Objects (not controls) that do the job
for accessing the gdb and working with it. The second part is the controls
that the user will interact with, esp. when they come from "3rd parties"
(like me in this case, or maybe Geoff's Enh* ctrls).

Therefore i would rather keep TIB_SynEdit in a separate package, so people
can easily install/deinstall it "on top of" an existing IBO-dev setup, with
no need to recompile the entire IBO package to test it.

This is (partly) because TIB_SynEdit is a "new born", less then 24 hrs old,
and i'm sure there are topics yet to solve. I'd rather have a really stable
IBO base pkg with some add-on control pkgs, than one big pkg which will
either compile or not *in total* (i don't need TIB_SynEdit everywhere,
but i need IBO "naked" ...well let's say, close to everywhere :-)

iow, (or to put it less politely ;-) i really hate excessive use of
$ifdefs and $includes because they make a flat .pas file unreadable (to me).
No offense, but without the help of Kay (who sent me the "de-includer" i
asked for in a previous post, THANK YOU Kay!) i would have never managed to
see through the dense web of ifdefs and includes in the IBO sources.
With Kay's tool i now have a directory with *only* .pas and .dfm,
no .imp, .pbl, .int etc. I just recompiled IBO_D5 w/o probs and now i can
finally dive deep into the ibo sources, navigating through them with
the functions D5 offers (Ctrl+Shift+Up/Down to toggle between interface
and implementation etc.)

So, all in all your proposal sounds alright to me, i just think
that the "details of implementation" may need some discussion ; )
For the time being, i made a little package IBSYNEDIT_D5 that only
contains the one unit with TIB_SynEdit, and it requires SYNEDIT_D5 and
IBO_D5. (as you may have noticed, i'm a real fan of "minimalistic
approaches" :-)

But my initial question remains open: may i or may i not publish source
code of add-on ctrls that are more or less copy-pasted from the original
IBO controls with only minor modifications ?? (note it doesn't touch
the "core code" of IB_Statement etc., it just *uses* them)

...man, i seem unable to write *short* replies <bg>...

tia for any comments,
fingerman