On Sun, 04 Oct 2015, Beno??t Minisini wrote:
> Le 04/10/2015 18:29, Tobias Boege a ?crit :
> > On Sat, 03 Oct 2015, Beno??t Minisini wrote:
> >>> Is there a limitation, about raising events from constructors, I don't
> >>> know
> >>> of? Also note how, in the demonstration project, I can very well initiate
> >>> the validation procedure just after the constructor finished.
> >>>
> >>
> >> The logic behind that behaviour is that an object whose constructor is
> >> not finished should not be able to raise or catch events.
> >>
> >> Said differently, an object must be ready to deal with events.
> >>
> >
> > Uff, I didn't expect the answer to make this much sense...
> >
>
> It's not technically necessary to do that, but it avoids a lot of
> possible annoying bugs in your code.
>
I understand. And by the way, that Timer trick works even in the following
form:
--8<--[ ValidateBox.class]--------------------------------------------------
Private $frmControl As FValidateBox
Private $hTimer As Timer
Public Sub _new()
$frmControl = New FValidateBox(Me) As "Control"
$hTimer = New Timer As "FirstCheck"
$hTimer.Delay = 1
$hTimer.Start()
End
Public Sub FirstCheck_Timer()
$hTimer.Stop()
$frmControl.txtInput_Change() ' Trigger first validation
End
--8<------------------------------------------------------------------------
The 1 millisecond timer delay is provocative enough that everyone who reads
the code will get that this is a hack and why it's there for. It is not as
self-explanatory as the GB.Post() API which we have in C, though.
Regards,
Tobi
--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
------------------------------------------------------------------------------
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
