Re: Include decision
Pete Lomax wrote:
>
> On Mon, 06 Nov 2006 13:48:40 -0800, ZNorQ <guest at RapidEuphoria.com>
> wrote:
>
> >I'm using a third party include file - TCP4U - but I want to be able to
> >turn it off using a global constant ACTIVATE_TCP = FALSE. (This is if
> >I'm gonna distribute a version of my program without the TCP4U module
> >included. Don't worry, any recognitions are made to the appropriate
> >owners.)
> I don't and never have had tcp4u loaded, btw
> >
> >The way it works is that the DLL is 'sequenced' into my application,
> >and if the ACTIVATE_TCP = TRUE, it will save the DLL to file - and then
> >execute the TCP4U module.
> Are you really saying:
> }}}
<eucode>
> constant gunk={blah}
> if ACTIVATE_TCP then
> fn = open("zz.dll","w")
> puts(fn,decipher(gunk))
> close(fn)
> end if
> </eucode>
{{{
> >
Well, if {blah} = the DLL code in a byte structure - yes - this is how I
do it. I used a program that is called "Sequencer" by Andrea Cini to create
a sequenced version of the DLL that is incorporated into my program. This
way the user of the program don't have to worry about having the DLL laying
around. So, if ACTIVATE_TCP = true, the above program you describe exports
the DLL. (Not sure what that 'decipher' function you're referring to is
supposed to be..)
The problem however, is that I don't want it to start the wrappers
initialization process of it if ACTIVATE_TCP = false, like the DLL loading
which is taken care of by the wrapper itself.
What I had to do for now, is to include an 'if ACTIAVE_TCP = FALSE then
<skip all TCP4U initializations>' in the TCP4U wrapper itself. I really don't
want to make changes in other peoples applications. Ofcourse, without the
change, I'll end up with a bunch of errors since the wrapper cannot find the
DLL file.
Then you might ask, why not just remove the include file? Well, I use a
system where I have alot of 'switches' (constants) that I turn on / off. By
using these I can 'fine tune' the application according to the users need.
Think of them as some backward attempt of compiler directives...
Example;
ACTIVATE_TCP = FALSE
AUTHENTIFICATION = TRUE
EXPIRY_DATE = "11.07.2006"
...
My problem would have been solved if there was a way to include the wrapper
only if the ACTIVATE_TCP = true, and if it isn't - skip the include.
So in short - since the wrapper takes care of all initializations, and I don't
want that to start if ACTIVATE_TCP = true, and I don't want to make changes
in the wrapper itself... What then?
It's been proposed to use some sort of pre-processor, so I'll have a look into
that. Not very driven in the world of pre-processors, though, so it might take
some time :) And it seems to me that either the pre-processor is too old -
dating back to 97/98, or it doesn't exist - OR it doesn't contain what I
need.. Doh...
> >The challenge (or - problem) is that when I deactivate the TCP4U
> >(ACTIVATE_TCP = FALSE) the program shall NOT save the DLL to disk, and
> >NOT run the TCP4U wrapper. Only problem is that as soon as I include the
> >wrapper - certain initialization routines are already executed, and since
> >it wont find the DLL file - errors will emerge.
> then eg:
> }}}
<eucode>
> constant zz=open_dll("zz.dll")
> if zz=-1 then ?9/0 end if -- or other use of zz
> </eucode>
{{{
> IE: the second half (in tcp4u) does NOT test ACTIVATE_TCP?
>
> Well (assuming the above assumption is correct) the only thing I can
> suggest is that you repackage [SEE BELOW!], eg replace:
>
> }}}
<eucode>
> constant zz=open_dll("zz.dll")
> ..etc
> </eucode>
{{{
> with
> integer zinit zinit=0
> atom zz, ..
>
> procedure initZ()
> zz=open_dll("zz.dll")
> ..
> zinit=1
> end procedure
>
> global routine a(...)
> if not zinit then initZ() end if
> end routine
>
> global routine b(...)
> if not zinit then initZ() end if
> end routine
> </eucode>
{{{
>
> And... Re-Submit This Code to the Archives
> (that was the [SEE BELOW!] point above, btw.)
> You may feel reluctant, but it is prolly the right thing to do...
> >
> >What I've done up till now, is modify the wrapper itself with an
> >'IF ACTIVATE_TCP = TRUE...' etc, but I don't want to have to edit third
> >party snippets..
> >
> The problem with a [new] constant ACTIVATE_TCP is that it cannot be
> defined inside the wrapper, and it will break all legacy use, which
> the above ought not to - and if /your/ (ACTIVATE_TCP-wrapped) code
> does not call routine a/b/etc, no prob with missing zz.dll, yes?
>
> >Anyone know what walkaround I can use?
> HTH,
> Regards,
> Pete
>
>
|
Not Categorized, Please Help
|
|
