Losing focus

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Losing focus

Ralph Boland
I created a button class which is  version of IconicButton
(by cutting and pasting) that does extra things that I need.
One of the things that I do is expand the size of my button
(actually a collection of my buttons) when running an application that uses it.
When I do so only a small area of near the top left corner of my
button seems to have focus
so then if I click on that area the button works but otherwise it does not.

When I click within my botton's working area  <MyButton>>handleEvent:
anEvent> is called by
<MouseOverHandler>>processMouseOver: anEvent>.

When my button does not work the method <handleEvent: anEvent>  is not called
because, I believe, the portion of my button that was clicked  does
not have focus.
Note that when my button size is expanded it's position is also changed because
other morphs have also expanded but this expansion does not seems to
cause confusion
as to where the button is because the working focus area
remains in the same part of my button.
But there appears to be confusion as to the size of my button and its
focus area.

Debugging this is a pain.  When I set a break point in
<MyButton>>handleEvent: anEvent>
the emergency handler pops up.  when I do a <revert>  I get my stack with
<MyButton>>handleEvent: anEvent>  at the top of the stack.
But I have gathered little useful information by looking at this stack.
The only solution I can think of is to discard by button (buttons)
and reinstantiate them every time they need to be resized.

Is there something that I should be setting when I resize my button so
that it's focus area
is correct?

Is discarding my buttons and reinsantiating them the only solution?

Any help or insight appreciated.

Ralph Boland
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: Losing focus

marcel.taeumel
Hi Ralph,

can you file-out and share your version of the IconicButton class?

Morph >> #handleEvent: is too low-level for your use case. You should only overwrite/implement #handlesMouseDown: and #mouseDown:, for example.

Seems to me that the icon in your button is bigger than your button. Only the button/owner gets the events here. For example, if you do this, it gets tricky:

button := IconicButton new.
button labelGraphic: (MenuIcons homeIcon scaledToSize: 100@100).
button extent: 50@50.

...because the button is smaller than its icon.

What you can try is either this:

button clipSubmorphs: true.

...to see the actual bounds of the owner. Or you can use a PluggableButton:

pbutton := PluggableButtonMorph new.
pbutton action: #showln:.
pbutton model: Transcript.
pbutton arguments: #(42).
pbutton label: (MenuIcons homeIcon scaledToSize: 100@100) asMorph.
pbutton extent: 50@50.

Best,
Marcel

Am 25.10.2017 05:58:10 schrieb Ralph Boland <[hidden email]>:

I created a button class which is version of IconicButton
(by cutting and pasting) that does extra things that I need.
One of the things that I do is expand the size of my button
(actually a collection of my buttons) when running an application that uses it.
When I do so only a small area of near the top left corner of my
button seems to have focus
so then if I click on that area the button works but otherwise it does not.

When I click within my botton's working area >handleEvent:
anEvent> is called by
>processMouseOver: anEvent>.

When my button does not work the method is not called
because, I believe, the portion of my button that was clicked does
not have focus.
Note that when my button size is expanded it's position is also changed because
other morphs have also expanded but this expansion does not seems to
cause confusion
as to where the button is because the working focus area
remains in the same part of my button.
But there appears to be confusion as to the size of my button and its
focus area.

Debugging this is a pain. When I set a break point in
>handleEvent: anEvent>
the emergency handler pops up. when I do a I get my stack with
>handleEvent: anEvent> at the top of the stack.
But I have gathered little useful information by looking at this stack.
The only solution I can think of is to discard by button (buttons)
and reinstantiate them every time they need to be resized.

Is there something that I should be setting when I resize my button so
that it's focus area
is correct?

Is discarding my buttons and reinsantiating them the only solution?

Any help or insight appreciated.

Ralph Boland
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: losing focus

Ralph Boland
In reply to this post by Ralph Boland
Found/fixed problem:  When my morph containing a collection of my
button morphs was resized the icons (forms) were
resized but not the buttons.  So you were right.  Oddly enough the
containing morph knew how big each button was supposed
to be so it allocated enough screen space for each button.  I thought
it was resizing the buttons too but I was wrong.
In other places I did resize my button morphs when needed so in those
instances it (of course) worked all along.

>  Hi Ralph,

>  can you file-out and share your version of the IconicButton class?

I could but to you wouldn't have found the problem there because the
way the code is written it is the responsibility
of the code delivering the new icon/form to the button that is
responsible for changing the button's extent.
I suppose I could pass the icon/form and the new extent to the button
together and let it be responsible for the changes.
I'll think about it.

Morph >> #handleEvent: is too low-level for your use case. You should
only overwrite/implement #handlesMouseDown: and #mouseDown:, for
example.

my button class implemented #handleEvent only to set a breakpoint.  I
assume you mean that I should have instead
did the same with #mouseDown:  I will give this a try and see if it
avoids my getting the emergency window.

I had no idea that  #handleEvent is lower level than  #mouseDown:.
Is there a place that I can learn things like this?
Squeak seems to provide little documentation here (as elsewhere).
It is definitely a trial by fire for me to figure all this GUI stuff out.
I have little knowledge/interest in GUIs but need to know this since
I am developing some children's educational software in Squeak.

> Seems to me that the icon in your button is bigger than your button.
> Only the button/owner gets the events here.

YOU WERE RIGHT.  This is what I did wrong.
I knew that it is the button that gets the events; just failed to
resize the button.


> ...


> Best,
> Marcel

Thanks.  In retrospect this looks pretty obvious.  :(

Ralph

--------------------------------Original
message--------------------------------------------------

Am 25.10.2017 05:58:10 schrieb Ralph Boland <[hidden email]>:
I created a button class which is version of IconicButton
(by cutting and pasting) that does extra things that I need.
One of the things that I do is expand the size of my button
(actually a collection of my buttons) when running an application that uses it.
When I do so only a small area of near the top left corner of my
button seems to have focus
so then if I click on that area the button works but otherwise it does not.

When I click within my botton's working area >handleEvent:
anEvent> is called by
>processMouseOver: anEvent>.

When my button does not work the method is not called
because, I believe, the portion of my button that was clicked does
not have focus.
Note that when my button size is expanded it's position is also changed because
other morphs have also expanded but this expansion does not seems to
cause confusion
as to where the button is because the working focus area
remains in the same part of my button.
But there appears to be confusion as to the size of my button and its
focus area.

Debugging this is a pain. When I set a break point in
>handleEvent: anEvent>
the emergency handler pops up. when I do a I get my stack with
>handleEvent: anEvent> at the top of the stack.
But I have gathered little useful information by looking at this stack.
The only solution I can think of is to discard by button (buttons)
and reinstantiate them every time they need to be resized.

Is there something that I should be setting when I resize my button so
that it's focus area
is correct?

Is discarding my buttons and reinsantiating them the only solution?

Any help or insight appreciated.

Ralph Boland
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: losing focus

marcel.taeumel
Hi Ralph,

it is a good thing that you find it obvious in retrospect. Now, you can move on and learn more about Morphic event handling. :-)

Set a breakpoint in you button's #mouseDown:, and then take a look at the debugger's stack. Some calls are closer to the Morphic main loop, some are closer to your application code. :) Here is an illustration:


Best,
Marcel

Am 26.10.2017 09:19:17 schrieb Ralph Boland <[hidden email]>:

Found/fixed problem: When my morph containing a collection of my
button morphs was resized the icons (forms) were
resized but not the buttons. So you were right. Oddly enough the
containing morph knew how big each button was supposed
to be so it allocated enough screen space for each button. I thought
it was resizing the buttons too but I was wrong.
In other places I did resize my button morphs when needed so in those
instances it (of course) worked all along.

> Hi Ralph,

> can you file-out and share your version of the IconicButton class?

I could but to you wouldn't have found the problem there because the
way the code is written it is the responsibility
of the code delivering the new icon/form to the button that is
responsible for changing the button's extent.
I suppose I could pass the icon/form and the new extent to the button
together and let it be responsible for the changes.
I'll think about it.

Morph >> #handleEvent: is too low-level for your use case. You should
only overwrite/implement #handlesMouseDown: and #mouseDown:, for
example.

my button class implemented #handleEvent only to set a breakpoint. I
assume you mean that I should have instead
did the same with #mouseDown: I will give this a try and see if it
avoids my getting the emergency window.

I had no idea that #handleEvent is lower level than #mouseDown:.
Is there a place that I can learn things like this?
Squeak seems to provide little documentation here (as elsewhere).
It is definitely a trial by fire for me to figure all this GUI stuff out.
I have little knowledge/interest in GUIs but need to know this since
I am developing some children's educational software in Squeak.

> Seems to me that the icon in your button is bigger than your button.
> Only the button/owner gets the events here.

YOU WERE RIGHT. This is what I did wrong.
I knew that it is the button that gets the events; just failed to
resize the button.


> ...


> Best,
> Marcel

Thanks. In retrospect this looks pretty obvious. :(

Ralph

--------------------------------Original
message--------------------------------------------------

Am 25.10.2017 05:58:10 schrieb Ralph Boland :
I created a button class which is version of IconicButton
(by cutting and pasting) that does extra things that I need.
One of the things that I do is expand the size of my button
(actually a collection of my buttons) when running an application that uses it.
When I do so only a small area of near the top left corner of my
button seems to have focus
so then if I click on that area the button works but otherwise it does not.

When I click within my botton's working area >handleEvent:
anEvent> is called by
>processMouseOver: anEvent>.

When my button does not work the method is not called
because, I believe, the portion of my button that was clicked does
not have focus.
Note that when my button size is expanded it's position is also changed because
other morphs have also expanded but this expansion does not seems to
cause confusion
as to where the button is because the working focus area
remains in the same part of my button.
But there appears to be confusion as to the size of my button and its
focus area.

Debugging this is a pain. When I set a break point in
>handleEvent: anEvent>
the emergency handler pops up. when I do a I get my stack with
>handleEvent: anEvent> at the top of the stack.
But I have gathered little useful information by looking at this stack.
The only solution I can think of is to discard by button (buttons)
and reinstantiate them every time they need to be resized.

Is there something that I should be setting when I resize my button so
that it's focus area
is correct?

Is discarding my buttons and reinsantiating them the only solution?

Any help or insight appreciated.

Ralph Boland
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: losing focus

K K Subbu
In reply to this post by Ralph Boland
On Thursday 26 October 2017 12:49 PM, Ralph Boland wrote:
> I had no idea that  #handleEvent is lower level than  #mouseDown:.
> Is there a place that I can learn things like this?
> Squeak seems to provide little documentation here (as elsewhere).
> It is definitely a trial by fire for me to figure all this GUI stuff out.
> I have little knowledge/interest in GUIs but need to know this since
> I am developing some children's educational software in Squeak.

The GUI stuff in Squeak is Morphic. Here is a good place to start:

http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final.pdf

The layout and event handling in today's Squeak have evolved since the
article was written, but the principles behind Morphic are described
very well. Once you understand these, you should be able to catch up
with current code.

http://wiki.squeak.org/squeak/search is a good place to start searching
for Squeak specific help.

HTH .. Subbu
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners