On Tue, 2012-05-01 at 12:22 +0200, Benoît Minisini wrote:
> A lot of answers to a lot of stuff, so I'm going to break it up into several
> posts.
> Le 29/04/2012 06:45, Bruce Bruen a écrit :
> >
> > SUGGESTION: Libraries should not need to have a startup class. At
> > the moment I "must" include a dummy module to prevent any
> > test-harness code leaking into the user environment (which could
> > cause damage if the library were to be run as a normal gambas
> > executable.) At the moment the IDE will not let a library be made
> > into an executable or packaged unless it has a startup class. It
> > would be preferable that projects defined as libraries would not
> > execute via the runtime, that way test harness code could be left in
> > place. Currently I have to check that the coders have left the
> > startup class pointing to the following:-
> >
> > ' Gambas module file
> >
> > ' Null module to provide a fake startup point
> >
> > Public Sub Main()
> >
> > Error "Please do not run this as a program. It is a gambas library."
> >
> > End
> >
>
> Mmm. You are right, for libraries the IDE should let you not defined a
> startup class. I will see what I can do.
>
I think that ("the IDE should let you not defined a startup class") is
an overkill. What I need is a way to use a startup class in a library
when I'm developing it but when it is packaged the startup class should
be "removeable".
To explain, during development/debug/support for a library, we need to
be able to run it as a normal project through the IDE. This is what I
meant about "test harnesses". In general, we have a MMain module in the
library that may, or in fact usually, contains code that lets us enter
method parameter values manually. This type of code if used by an
ill-advised user could cause great havoc on an underlying database or
the like.
What I would like is a way to manually disable or "turn off" the startup
class when the library project is made as an executable or is packaged.
I suppose that the alternative is to not allow startup classes in
libraries or components and keep changing the project type to "Normal"
when we are debugging/supporting but I can foresee a lot of mistakes if
that route is chosen.
The way I see it is this. (Hypothetically) I've just spent some time on
the phone to Mr Jones and it appears that there is, amazingly, a problem
in the xyzzzy library. I open the xyzzy project and using the test
harness code therein I find that we did in fact code a logic error when
some date parameter to a dual timezone function is exactly the date and
time that daylight savings changed in one of the timezones. ( I kid you
not, this happened recently!) So I give the problem to the wizkids, er
sorry, my brilliant development team, and they come up with a nicely
tested solution.
So now all I want to do is turn off the startup class, compile and make
the distributable version and send it out.
With a bit of thought... maybe what libraries/components need is a
startup class that only works within the IDE...
hmm!
Bruce
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
