gambas-user

[Gambas-user] Events not firing in dynamically instantiated forms.

[Stephen <sb...@sm...>]

   GAMBAS: 3.5.4
   Fedora 20 in a VM under 64 bit CentOS 6.5
   MATE Desktop

   I'm a bit confused (some would say it's my normal state:) as to why, 
when a form is dynamically instantiated within a tabstrip (or other 
container) the Open and Show events for the instantiated form don't 
fire. This can be worked around by making a Show subroutine that can be 
manually called from the parent form.

   Have a look at the source demonstration project attached to this email.

   Should these events fire? If not then why?

-- 
Kindest Regards
Stephen A. Bungay, Prop.
Smarts On Site Information Systems

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Benoît M. <ga...@us...>]

Le 27/11/2014 14:08, Stephen a écrit :
>    GAMBAS: 3.5.4
>    Fedora 20 in a VM under 64 bit CentOS 6.5
>    MATE Desktop
>
>    I'm a bit confused (some would say it's my normal state:) as to why,
> when a form is dynamically instantiated within a tabstrip (or other
> container) the Open and Show events for the instantiated form don't
> fire. This can be worked around by making a Show subroutine that can be
> manually called from the parent form.
>
>    Have a look at the source demonstration project attached to this email.
>
>    Should these events fire? If not then why?
>

Because you override the event observer when instanciating Form1, which 
is by default itself. Don't override it, and it will work.

-- 
Benoît Minisini

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Stephen <sb...@sm...>]

I'm not consciously overriding the event observer so I'm not clear how 
to not do it.
Obviously I still have much to learn.

On 11/27/2014 08:20 AM, Benoît Minisini wrote:
> Le 27/11/2014 14:08, Stephen a écrit :
>>     GAMBAS: 3.5.4
>>     Fedora 20 in a VM under 64 bit CentOS 6.5
>>     MATE Desktop
>>
>>     I'm a bit confused (some would say it's my normal state:) as to why,
>> when a form is dynamically instantiated within a tabstrip (or other
>> container) the Open and Show events for the instantiated form don't
>> fire. This can be worked around by making a Show subroutine that can be
>> manually called from the parent form.
>>
>>     Have a look at the source demonstration project attached to this email.
>>
>>     Should these events fire? If not then why?
>>
> Because you override the event observer when instanciating Form1, which
> is by default itself. Don't override it, and it will work.
>


-- 
Kindest Regards
Stephen A. Bungay, Prop.
Smarts On Site Information Systems

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Benoît M. <ga...@us...>]

Le 27/11/2014 14:29, Stephen a écrit :
> I'm not consciously overriding the event observer so I'm not clear how
> to not do it.
> Obviously I still have much to learn.
>

mhForm1 = New Form1(TabStrip1) As "Form1"
                                \________/
                                    .
                                   /|\
                                    |
                                    '
There.

-- 
Benoît Minisini

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Stephen <sb...@sm...>]

On 11/27/2014 08:39 AM, Benoît Minisini wrote:
> Le 27/11/2014 14:29, Stephen a écrit :
>> I'm not consciously overriding the event observer so I'm not clear how
>> to not do it.
>> Obviously I still have much to learn.
>>
> mhForm1 = New Form1(TabStrip1) As "Form1"
>                                  \________/
>                                      .
>                                     /|\
>                                      |
>                                      '
> There.
>
   Ah NOW I see what's happening and why. Merci Benoit!

-- 
Kindest Regards
Stephen A. Bungay, Prop.
Smarts On Site Information Systems

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 08:39 AM, Benoît Minisini wrote:
> Le 27/11/2014 14:29, Stephen a écrit :
>> I'm not consciously overriding the event observer so I'm not clear how
>> to not do it.
>> Obviously I still have much to learn.
>>
>
> mhForm1 = New Form1(TabStrip1) As "Form1"
>                                  \________/

Now *I'm* confused. The documentation for "New" 
(http://gambaswiki.org/wiki/lang/new) gives its syntax as:
Object = NEW Class [ ( Constructor parameters... ) ] [ AS Name ]


And, there is a warning box that says, "If you forget to specify the 
Name part, your object will never raise events!"

But after stripping "As Form1" off the end of that line, the form 
obviously *does* raise events.

Is the documentation in need of correction? If so, what should that 
warning actually say?


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Tobias B. <ta...@gm...>]

On Thu, 27 Nov 2014, T Lee Davidson wrote:
> On 11/27/2014 08:39 AM, Beno?t Minisini wrote:
> > Le 27/11/2014 14:29, Stephen a ?crit :
> >> I'm not consciously overriding the event observer so I'm not clear how
> >> to not do it.
> >> Obviously I still have much to learn.
> >>
> >
> > mhForm1 = New Form1(TabStrip1) As "Form1"
> >                                  \________/
> 
> Now *I'm* confused. The documentation for "New" 
> (http://gambaswiki.org/wiki/lang/new) gives its syntax as:
> Object = NEW Class [ ( Constructor parameters... ) ] [ AS Name ]
> 
> 
> And, there is a warning box that says, "If you forget to specify the 
> Name part, your object will never raise events!"
> 
> But after stripping "As Form1" off the end of that line, the form 
> obviously *does* raise events.
> 
> Is the documentation in need of correction? If so, what should that 
> warning actually say?
> 

What the documentation says is generally true. But Form is a special class:
it attaches to itself as event observer by default when instantiated.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 12:55 PM, Tobias Boege wrote:
> On Thu, 27 Nov 2014, T Lee Davidson wrote:
>> On 11/27/2014 08:39 AM, Beno?t Minisini wrote:
>>> Le 27/11/2014 14:29, Stephen a ?crit :
>>>> I'm not consciously overriding the event observer so I'm not clear how
>>>> to not do it.
>>>> Obviously I still have much to learn.
>>>>
>>>
>>> mhForm1 = New Form1(TabStrip1) As "Form1"
>>>                                   \________/
>>
>> Now *I'm* confused. The documentation for "New"
>> (http://gambaswiki.org/wiki/lang/new) gives its syntax as:
>> Object = NEW Class [ ( Constructor parameters... ) ] [ AS Name ]
>>
>>
>> And, there is a warning box that says, "If you forget to specify the
>> Name part, your object will never raise events!"
>>
>> But after stripping "As Form1" off the end of that line, the form
>> obviously *does* raise events.
>>
>> Is the documentation in need of correction? If so, what should that
>> warning actually say?
>>
>
> What the documentation says is generally true. But Form is a special class:
> it attaches to itself as event observer by default when instantiated.
>
> Regards,
> Tobi
>

Thanks Tobi. I understand that a form is by default its own event observer.

What confuses me is that the warning seems to indicate that the "As 
Name" part is required for the object to be able to raise events.

Thinking that the warning should say, "*If you specify As* but forget to 
specify the Name part ...", I took off just the Name part leaving "As" 
at the end of the line. I then got, "Unexpected end of line".

So, I guess I'm just confused as to what that warning is actually saying.


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Tobias B. <ta...@gm...>]

On Thu, 27 Nov 2014, T Lee Davidson wrote:
> On 11/27/2014 12:55 PM, Tobias Boege wrote:
> > On Thu, 27 Nov 2014, T Lee Davidson wrote:
> >> On 11/27/2014 08:39 AM, Beno?t Minisini wrote:
> >>> Le 27/11/2014 14:29, Stephen a ?crit :
> >>>> I'm not consciously overriding the event observer so I'm not clear how
> >>>> to not do it.
> >>>> Obviously I still have much to learn.
> >>>>
> >>>
> >>> mhForm1 = New Form1(TabStrip1) As "Form1"
> >>>                                   \________/
> >>
> >> Now *I'm* confused. The documentation for "New"
> >> (http://gambaswiki.org/wiki/lang/new) gives its syntax as:
> >> Object = NEW Class [ ( Constructor parameters... ) ] [ AS Name ]
> >>
> >>
> >> And, there is a warning box that says, "If you forget to specify the
> >> Name part, your object will never raise events!"
> >>
> >> But after stripping "As Form1" off the end of that line, the form
> >> obviously *does* raise events.
> >>
> >> Is the documentation in need of correction? If so, what should that
> >> warning actually say?
> >>
> >
> > What the documentation says is generally true. But Form is a special class:
> > it attaches to itself as event observer by default when instantiated.
> >
> > Regards,
> > Tobi
> >
> 
> Thanks Tobi. I understand that a form is by default its own event observer.
> 
> What confuses me is that the warning seems to indicate that the "As 
> Name" part is required for the object to be able to raise events.
> 
> Thinking that the warning should say, "*If you specify As* but forget to 
> specify the Name part ...", I took off just the Name part leaving "As" 
> at the end of the line. I then got, "Unexpected end of line".
> 
> So, I guess I'm just confused as to what that warning is actually saying.
> 

OK, "As name" comes as a bundle. It makes your newly created object raise
events under the given name and makes the current class its event observer.
This is called "attaching" the object to its observer. "As" without a name
is a syntax error.

This means that in a class Bob the lines

  Private h As Alice

  Public Sub _new()
    h = New Alice As "Beth"
  End

create a new Alice in the variable "h" and assigns her the event name "Beth"
(just to show that the event name is totally free to choose).

The current Bob where you create that Alice is now her event observer, that
is you can intercept the events of "h" in the code of Bob. Say, Alice raises
an event called "Send", you can write

  Public Sub Beth_Send()
    ' This is called when the h object raises the Send event.
  End

in your Bob.class. Take your time to experiment if you're still insecure
here. (Or ask for a concrete example!)

If you don't give "As name", the object will not be attached to any observer
and this will prevent it from raising events (actually it _can_ raise events
but nobody will hear it).

But Form plays a special role. It will attach itself to itself automatically,
using the event name "Form". You have very likely already seen code like

  Public Sub Form_Open()
    ' ...
  End

without worrying about it. Well, you don't need to worry about it because of
the automatic attaching logic that is built into the Form class.

However, if you create a new form and explicitely give it an event name, the
procedure I described above kicks in. That is, the form is not attached to
itself as "Form" but to the object which creates the form, with the given
name (an object can have at most have one primary observer). Consequently,
Form_Open within the form code will no longer fire. That's what the thread
was originally about.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Tobias B. <ta...@gm...>]

On Thu, 27 Nov 2014, Tobias Boege wrote:
> OK, "As name" comes as a bundle. It makes your newly created object raise
> events under the given name and makes the current class its event observer.

Read: ... current *object* its event observer.

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

Wow. That is a very good explanation. Thank you, Tobi!

I did understand that "a form is by default its own event observer". But 
I guess I did not fully understand exactly what that meant.

(And, yes, I have seen code like, "Public Sub Form_Open()", and always 
wondered why it did not say "Form1_Open()".)

I thought, when I first asked, that it would be a simple answer. (I 
apologize to you, Stephen, for unintentionally hi-jacking your thread. I 
did think you were done with it.)

Okay, so:
1. Should that warning actually say, "Unless ~Class~ is a 
[Form](/comp/gb.qt4/form), if you forget to specify the ~Name~ part, 
your object will never raise events!"

2. And, should this explanation be put on the Wiki somewhere? If so, where?


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."


On 11/27/2014 01:47 PM, Tobias Boege wrote:
>> Thanks Tobi. I understand that a form is by default its own event observer.
>> >
>> >What confuses me is that the warning seems to indicate that the "As
>> >Name" part is required for the object to be able to raise events.
>> >
>> >Thinking that the warning should say, "*If you specify As*  but forget to
>> >specify the Name part ...", I took off just the Name part leaving "As"
>> >at the end of the line. I then got, "Unexpected end of line".
>> >
>> >So, I guess I'm just confused as to what that warning is actually saying.
>> >
> OK, "As name" comes as a bundle. It makes your newly created object raise
> events under the given name and makes the current class its event observer.
> This is called "attaching" the object to its observer. "As" without a name
> is a syntax error.
>
> This means that in a class Bob the lines
>
>    Private h As Alice
>
>    Public Sub _new()
>      h = New Alice As "Beth"
>    End
>
> create a new Alice in the variable "h" and assigns her the event name "Beth"
> (just to show that the event name is totally free to choose).
>
> The current Bob where you create that Alice is now her event observer, that
> is you can intercept the events of "h" in the code of Bob. Say, Alice raises
> an event called "Send", you can write
>
>    Public Sub Beth_Send()
>      ' This is called when the h object raises the Send event.
>    End
>
> in your Bob.class. Take your time to experiment if you're still insecure
> here. (Or ask for a concrete example!)
>
> If you don't give "As name", the object will not be attached to any observer
> and this will prevent it from raising events (actually it_can_  raise events
> but nobody will hear it).
>
> But Form plays a special role. It will attach itself to itself automatically,
> using the event name "Form". You have very likely already seen code like
>
>    Public Sub Form_Open()
>      ' ...
>    End
>
> without worrying about it. Well, you don't need to worry about it because of
> the automatic attaching logic that is built into the Form class.
>
> However, if you create a new form and explicitely give it an event name, the
> procedure I described above kicks in. That is, the form is not attached to
> itself as "Form" but to the object which creates the form, with the given
> name (an object can have at most have one primary observer). Consequently,
> Form_Open within the form code will no longer fire. That's what the thread
> was originally about.
>
> Regards,
> Tobi

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 02:36 PM, T Lee Davidson wrote:
> Wow. That is a very good explanation. Thank you, Tobi!
>
> I did understand that "a form is by default its own event observer". But
> I guess I did not fully understand exactly what that meant.
>
> (And, yes, I have seen code like, "Public Sub Form_Open()", and always
> wondered why it did not say "Form1_Open()".)
>
> I thought, when I first asked, that it would be a simple answer. (I
> apologize to you, Stephen, for unintentionally hi-jacking your thread. I
> did think you were done with it.)
>
> Okay, so:
> 1. Should that warning actually say, "Unless ~Class~ is a
> [Form](/comp/gb.qt4/form), if you forget to specify the ~Name~ part,
> your object will never raise events!"
>
> 2. And, should this explanation be put on the Wiki somewhere? If so, where?

Nevermind the second question in #2. Apparently I can't create pages.


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."

Re: [Gambas-user] Events not firing in dynamically instantiated forms.

[Tobias B. <ta...@gm...>]

On Thu, 27 Nov 2014, T Lee Davidson wrote:
> Wow. That is a very good explanation. Thank you, Tobi!
> 
> I did understand that "a form is by default its own event observer". But 
> I guess I did not fully understand exactly what that meant.
> 
> (And, yes, I have seen code like, "Public Sub Form_Open()", and always 
> wondered why it did not say "Form1_Open()".)
> 
> I thought, when I first asked, that it would be a simple answer. (I 
> apologize to you, Stephen, for unintentionally hi-jacking your thread. I 
> did think you were done with it.)
> 
> Okay, so:
> 1. Should that warning actually say, "Unless ~Class~ is a 
> [Form](/comp/gb.qt4/form), if you forget to specify the ~Name~ part, 
> your object will never raise events!"
> 

Well, I'm not going to adjoin that extra information about the internals of
some class in gb.qt4 seemlessly to a sentence that makes a warning about a
very general case -- in the mostly component-agnostic part of the documen-
tation, that is the Gambas language documentation.

Granted, Form is a prominent special case, so I'll add another section
talking about what happens when you use the "As name" syntax when creating
forms. If someone has a problem with that, please tell me.

> 2. And, should this explanation be put on the Wiki somewhere? If so, where?
> 

Hmm, comp/gb.qt4/form already says the entire truth -- if you know what all
the words mean. But doc/object-model or even def/eventhandler may be places
where more detailed information may be put but still far from good...

[ I drift off a little from here on: ]

I must admit that I don't really care: I think I understand what happens to
a good extent and if someone asks the question again, I can pull of the
explanation again (or more likely I'll link to this thread).

If everything was in the docs, what fun would there be in learning [ being
able to discover things on your own over time ] ? ;-) It's at least what I
enjoy most. But don't listen to me because I know quite exactly already
what's where in the docs. And people who got somewhere tend to forget how
hard the way may have been or want others to go the same way...

I feel like articles like the Gambas Magazine tries to publish are a *way*
better platform for this kind of information -- backgrounds that are not of
a purely technical manner (which would be the domain of a documentation)
but are grown from experience and a good overview of Gambas.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 04:02 PM, Tobias Boege wrote:
> Hmm, comp/gb.qt4/form already says the entire truth -- if you know what all
> the words mean.

All comp/gb.qt4/form says about events is:
===
Event management

By default, a form is its own event observer.

It means that all the events raised by the Form object are caught by 
event handlers defined in the form source code.
===

It does not say anything about the change in event observer when 
instantiating a form AS FormWhatever. So, to me, not the entire truth.


> I must admit that I don't really care: I think I understand what happens to
> a good extent and if someone asks the question again, I can pull of the
> explanation again (or more likely I'll link to this thread).

Rhetorically, wouldn't it be nice, though, if someone didn't *have* to ask?


> If everything was in the docs, what fun would there be in learning [ being
> able to discover things on your own over time ] ?;-)  It's at least what I
> enjoy most.

Lol. Yes, discovering and learning can be fun.

But, I think it is more fun to learn how to do something with the tools 
at hand than having to learn the special nuances of any particular tool.

As a farmer, I sometimes have to make a tool to get the job done. Do I 
enjoy that? Well, I enjoy making things. But I do not enjoy feeling 
robbed of my productive time.

Not knowing that instantiating a form As FormWhatever overrides the 
default event handler could be a "gotcha" for someone who is not as 
knowledgeable as you, as Stephen found out.

And, "As Name" is a feature of the Gambas language implementation. So, 
in my opinion, the appropriate venue for documenting this behavior would 
not be in a GambasMag article.

But, whatever. I was just looking to try to make things better for others.


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[Benoît M. <ga...@us...>]

Le 28/11/2014 00:27, T Lee Davidson a écrit :
> On 11/27/2014 04:02 PM, Tobias Boege wrote:
>> Hmm, comp/gb.qt4/form already says the entire truth -- if you know what all
>> the words mean.
>
> All comp/gb.qt4/form says about events is:
> ===
> Event management
>
> By default, a form is its own event observer.
>
> It means that all the events raised by the Form object are caught by
> event handlers defined in the form source code.
> ===
>
> It does not say anything about the change in event observer when
> instantiating a form AS FormWhatever. So, to me, not the entire truth.
>
>
>> I must admit that I don't really care: I think I understand what happens to
>> a good extent and if someone asks the question again, I can pull of the
>> explanation again (or more likely I'll link to this thread).
>
> Rhetorically, wouldn't it be nice, though, if someone didn't *have* to ask?
>
>
>> If everything was in the docs, what fun would there be in learning [ being
>> able to discover things on your own over time ] ?;-)  It's at least what I
>> enjoy most.
>
> Lol. Yes, discovering and learning can be fun.
>
> But, I think it is more fun to learn how to do something with the tools
> at hand than having to learn the special nuances of any particular tool.
>
> As a farmer, I sometimes have to make a tool to get the job done. Do I
> enjoy that? Well, I enjoy making things. But I do not enjoy feeling
> robbed of my productive time.
>
> Not knowing that instantiating a form As FormWhatever overrides the
> default event handler could be a "gotcha" for someone who is not as
> knowledgeable as you, as Stephen found out.
>
> And, "As Name" is a feature of the Gambas language implementation. So,
> in my opinion, the appropriate venue for documenting this behavior would
> not be in a GambasMag article.
>
> But, whatever. I was just looking to try to make things better for others.
>
>

I have updated the 'Gambas object model' description on the wiki to 
clarify the special behaviour of the Form objects.

http://gambaswiki.org/wiki/doc/object-model

If you haven't read that document yet, I strongly suggest that you read 
it and tell me if the explanations are clear enough for you.

Regards,

-- 
Benoît Minisini

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[Tobias B. <ta...@gm...>]

On Thu, 27 Nov 2014, T Lee Davidson wrote:
> > I must admit that I don't really care: I think I understand what happens to
> > a good extent and if someone asks the question again, I can pull of the
> > explanation again (or more likely I'll link to this thread).
> 
> Rhetorically, wouldn't it be nice, though, if someone didn't *have* to ask?
> 
> 
> > If everything was in the docs, what fun would there be in learning [ being
> > able to discover things on your own over time ] ?;-)  It's at least what I
> > enjoy most.
> 
> Lol. Yes, discovering and learning can be fun.
> 
> But, I think it is more fun to learn how to do something with the tools 
> at hand than having to learn the special nuances of any particular tool.
> 
> As a farmer, I sometimes have to make a tool to get the job done. Do I 
> enjoy that? Well, I enjoy making things. But I do not enjoy feeling 
> robbed of my productive time.
> 

Right, I'm unaware of productivity. Until now I gratefully came away with
just learning for learning's sake.

> Not knowing that instantiating a form As FormWhatever overrides the 
> default event handler could be a "gotcha" for someone who is not as 
> knowledgeable as you, as Stephen found out.
> 
> And, "As Name" is a feature of the Gambas language implementation. So, 
> in my opinion, the appropriate venue for documenting this behavior would 
> not be in a GambasMag article.
> 
> But, whatever. I was just looking to try to make things better for others.
> 

I see your point. Are you content with what I wrote[0] into the docs?

Regards,
Tobi

[0] http://gambaswiki.org/wiki/lang/new

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 06:40 PM, Tobias Boege wrote:
> I see your point. Are you content with what I wrote[0] into the docs?
>
> Regards,
> Tobi
>
> [0]http://gambaswiki.org/wiki/lang/new

Yes, Tobi, that is clear enough without writing a book about it ;-) 
Thank you.


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[Jorge C. <sh...@gm...>]

I must say that this has been a very, very enlightening discussion.

Thank you all, folks. This simplify a lot some workarounds in my code.

Regards

2014-11-28 2:06 GMT+01:00 T Lee Davidson <t.l...@gm...>:

> On 11/27/2014 06:52 PM, Benoît Minisini wrote:
> > I have updated the 'Gambas object model' description on the wiki to
> > clarify the special behaviour of the Form objects.
> >
> > http://gambaswiki.org/wiki/doc/object-model
> >
> > If you haven't read that document yet, I strongly suggest that you read
> > it and tell me if the explanations are clear enough for you.
> >
> > Regards,
> >
> > -- Benoît Minisini
>
> Thank you for updating that page, Benoît. I think it is quite clear
> regarding the behavior of "As Name".
>
>
> I had given it a cursory read it previously, and have just now read it
> more thoroughly.
>
> I did spot some typos, but I can take the time to fix those.
>
> There are some things that I do find confusing:
>
> A. "2.2. Default parent object (or default default observer)". Should
> that be simply, "or default observer"?
>
> B. 3.1. What is inherited: "You must use the ME keyword to access the
> inherited elements from the class inside." I think I understand what
> that ultimately means but am not exactly sure what the "class inside"
> would be.
>
> C. 3.4. Inheritance and constructor: Regarding the order of arguments,
> it is stated that the arguments of elder classes are specified first.
>
> However, 'hMyListBox = NEW MyListBox("Name", hContainer)' appears to
> contradict this and the other examples. It, as far as I can tell, gives
> the argument of the younger class first.
>
> Should the syntax be, 'hMyListBox = NEW MyListBox(hContainer, "Name")'?
>
>
> That's it. That's all I found confusing. (A truly rare occasion!)
>
>
> --
> Lee
> __________
>
> "Artificial Intelligence is no match for natural stupidity."
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-user mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[Gian <ba...@li...>]

Il 28/11/2014 10:03, Jorge Carrión ha scritto:
> I must say that this has been a very, very enlightening discussion.
>
> Thank you all, folks. This simplify a lot some workarounds in my code.
>
> Regards
>
> 2014-11-28 2:06 GMT+01:00 T Lee Davidson <t.l...@gm...>:
>
>> On 11/27/2014 06:52 PM, Benoît Minisini wrote:
>>> I have updated the 'Gambas object model' description on the wiki to
>>> clarify the special behaviour of the Form objects.
>>>
>>> http://gambaswiki.org/wiki/doc/object-model
>>>
>>> If you haven't read that document yet, I strongly suggest that you read
>>> it and tell me if the explanations are clear enough for you.
>>>
>>> Regards,
>>>
>>> -- Benoît Minisini
>>
>> Thank you for updating that page, Benoît. I think it is quite clear
>> regarding the behavior of "As Name".
>>
>>
>> I had given it a cursory read it previously, and have just now read it
>> more thoroughly.
>>
>> I did spot some typos, but I can take the time to fix those.
>>
>> There are some things that I do find confusing:
>>
>> A. "2.2. Default parent object (or default default observer)". Should
>> that be simply, "or default observer"?
>>
>> B. 3.1. What is inherited: "You must use the ME keyword to access the
>> inherited elements from the class inside." I think I understand what
>> that ultimately means but am not exactly sure what the "class inside"
>> would be.
>>
>> C. 3.4. Inheritance and constructor: Regarding the order of arguments,
>> it is stated that the arguments of elder classes are specified first.
>>
>> However, 'hMyListBox = NEW MyListBox("Name", hContainer)' appears to
>> contradict this and the other examples. It, as far as I can tell, gives
>> the argument of the younger class first.
>>
>> Should the syntax be, 'hMyListBox = NEW MyListBox(hContainer, "Name")'?
>>
>>
>> That's it. That's all I found confusing. (A truly rare occasion!)
>>
>>
>> --
>> Lee
>> __________
>>
>> "Artificial Intelligence is no match for natural stupidity."
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gambas-user mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gambas-user
>>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-user mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>

I also agree and thank
Gianluigi

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 06:52 PM, Benoît Minisini wrote:
> I have updated the 'Gambas object model' description on the wiki to
> clarify the special behaviour of the Form objects.
>
> http://gambaswiki.org/wiki/doc/object-model
>
> If you haven't read that document yet, I strongly suggest that you read
> it and tell me if the explanations are clear enough for you.
>
> Regards,
>
> -- Benoît Minisini

Thank you for updating that page, Benoît. I think it is quite clear 
regarding the behavior of "As Name".


I had given it a cursory read it previously, and have just now read it 
more thoroughly.

I did spot some typos, but I can take the time to fix those.

There are some things that I do find confusing:

A. "2.2. Default parent object (or default default observer)". Should 
that be simply, "or default observer"?

B. 3.1. What is inherited: "You must use the ME keyword to access the 
inherited elements from the class inside." I think I understand what 
that ultimately means but am not exactly sure what the "class inside" 
would be.

C. 3.4. Inheritance and constructor: Regarding the order of arguments, 
it is stated that the arguments of elder classes are specified first.

However, 'hMyListBox = NEW MyListBox("Name", hContainer)' appears to 
contradict this and the other examples. It, as far as I can tell, gives 
the argument of the younger class first.

Should the syntax be, 'hMyListBox = NEW MyListBox(hContainer, "Name")'?


That's it. That's all I found confusing. (A truly rare occasion!)


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[Benoît M. <ga...@us...>]

Le 28/11/2014 02:06, T Lee Davidson a écrit :
> On 11/27/2014 06:52 PM, Benoît Minisini wrote:
>> I have updated the 'Gambas object model' description on the wiki to
>> clarify the special behaviour of the Form objects.
>>
>> http://gambaswiki.org/wiki/doc/object-model
>>
>> If you haven't read that document yet, I strongly suggest that you read
>> it and tell me if the explanations are clear enough for you.
>>
>> Regards,
>>
>> -- Benoît Minisini
>
> Thank you for updating that page, Benoît. I think it is quite clear
> regarding the behavior of "As Name".
>
>
> I had given it a cursory read it previously, and have just now read it
> more thoroughly.
>
> I did spot some typos, but I can take the time to fix those.
>
> There are some things that I do find confusing:
>
> A. "2.2. Default parent object (or default default observer)". Should
> that be simply, "or default observer"?

This is really the default default observer. The default observer is the 
"current running" object where you create your new object. And a form 
has a default for that, so you have to write the word default twice.

>
> B. 3.1. What is inherited: "You must use the ME keyword to access the
> inherited elements from the class inside." I think I understand what
> that ultimately means but am not exactly sure what the "class inside"
> would be.

I mean: ...from the class implementation code.

>
> C. 3.4. Inheritance and constructor: Regarding the order of arguments,
> it is stated that the arguments of elder classes are specified first.
>
> However, 'hMyListBox = NEW MyListBox("Name", hContainer)' appears to
> contradict this and the other examples. It, as far as I can tell, gives
> the argument of the younger class first.
>
> Should the syntax be, 'hMyListBox = NEW MyListBox(hContainer, "Name")'?

You're right, that is a mistake. The arguments of elder classes come 
first. If you want to fix that too, you can do it.

Regards,

-- 
Benoît Minisini

Re: [Gambas-user] Documentation: Events not firing in dynamically instantiated forms.

[T L. D. <t.l...@gm...>]

On 11/27/2014 08:49 PM, Benoît Minisini wrote:
>> B. 3.1. What is inherited: "You must use the ME keyword to access the
>> >inherited elements from the class inside." I think I understand what
>> >that ultimately means but am not exactly sure what the "class inside"
>> >would be.
> I mean: ...from the class implementation code.
>
>> >
>> >C. 3.4. Inheritance and constructor: Regarding the order of arguments,
>> >it is stated that the arguments of elder classes are specified first.
>> >
>> >However, 'hMyListBox = NEW MyListBox("Name", hContainer)' appears to
>> >contradict this and the other examples. It, as far as I can tell, gives
>> >the argument of the younger class first.
>> >
>> >Should the syntax be, 'hMyListBox = NEW MyListBox(hContainer, "Name")'?
> You're right, that is a mistake. The arguments of elder classes come
> first. If you want to fix that too, you can do it.

Done. :-)


-- 
Lee
__________

"Artificial Intelligence is no match for natural stupidity."