Le 01/05/2012 13:27, Bruce Bruen a écrit :
> 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
>
I don't like any of those solution at the moment.
And if I define a compilation constant that will tell the compiler if we
are making an executable or not? That way, you will just have to add a
"#If Executable" (or something like that) to compile or not compile the
startup function ?
--
Benoît Minisini
------------------------------------------------------------------------------
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
