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 rpboland@gmail.com: 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
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 rpboland@gmail.com: 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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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....
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@lists.squeakfoundation.org