Frank,

I don't have a problem with doing it the way you are most inclined to do it.
It just makes it a little more difficult in other ways. There are tradeoffs
in everything it seems.

Go for it!

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Frank Ingermann" <frank.ingermann@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, April 12, 2001 4:03 AM
Subject: Re: [IBO] SynEdit for IBO - anyone interested?


> 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