1. Unexplainable behavior
I'm posting this follow up under a new subject because I'm at my wits end on
this and would like somebody (anybody?) to take another look to see if anything
pops out.
I have a handler for a checkbox onClick event that I want to fire when the user
clicks on a label to the left of the checkbox. I would presume this is fairly
common behaviour.
I programmed an invokeHandler command into the onClick event of the label and
it certainly invokes the checkbox onClick handler when the label is clicked.
But there is a problem in that it appears to actually invoke the handler twice
when running at "full speed". If it is slowed down by way of a sleep(1) command
or insertion of a message_box, either in the label's onClick or anywhere
downstream in the checkbox's onClick procedure it runs only once.
My label click procedure now looks like this:
procedure lblchkMyCheck_onClick (integer self, integer event, sequence params)
atom myAtom
setCheck(chkMyCheck,not(isChecked(chkMyCheck)))
sleep( 1)
myAtom = invokeHandler(chkMyCheck,w32HClick,{})
end procedure
My checkbox handler does a lot of things, one of which is to repaint virtually
every control on the screen (if that matters), along with present the results of
a calculation in a textbox (just one of many controls on the screen).
If I pull out the sleep(1) line, then the system does something that seems like
there is a bit of code somewhere I've forgotten about (which I generally refer to
as a poltergeist), because the above code runs twice, the first time with the
value of chkMyCheck appropriately changed from what it started out as and the
second time with the opposite. That is, the second time it is run with the value
of chkMyCheck exactly as chkMyCheck started, thereby putting a result on the
screen which is the same as when I started (obviously a bit unproductive,
complete with the check mark appearing for an instant and then resetting itself
back to how it started.
If I insert any CPU halting mechanism at any point in time (a sleep command,
or a message box) then the second execution is not done, the check box is
appropriately changed only once and the value displayed in the textbox is the
correct (updated) value.
As another hint as to what is going on, if I remove the sleep and message box
commands, I can still get it to work, if I click on the label and hold down
the left click button for a full second before letting it up.
I could understand how holding the left click button down might cause the event
to be registered twice, but this is the exact opposite. By clicking quickly and
lightly it executes twice. By clicking once (very slowly and heavily) it only
executes once. Baffling to me.
If that is enough information to trigger somebody's (terrible) memory of
something similar I'd love to hear about it.
Thanks
Mike
2. Re: Unexplainable behavior
Mike777 wrote:
>
> I'm posting this follow up under a new subject because I'm at my wits end on
> this and would like somebody (anybody?) to take another look to see if
> anything
> pops out.
>
> I have a handler for a checkbox onClick event that I want to fire when the
> user
> clicks on a label to the left of the checkbox. I would presume this is fairly
> common behaviour.
>
> I programmed an invokeHandler command into the onClick event of the label and
> it certainly invokes the checkbox onClick handler when the label is clicked.
>
> But there is a problem in that it appears to actually invoke the handler twice
> when running at "full speed". If it is slowed down by way of a sleep(1)
> command
> or insertion of a message_box, either in the label's onClick or anywhere
> downstream
> in the checkbox's onClick procedure it runs only once.
>
> My label click procedure now looks like this:
>
> procedure lblchkMyCheck_onClick (integer self, integer event, sequence params)
> atom myAtom
> setCheck(chkMyCheck,not(isChecked(chkMyCheck)))
> sleep( 1)
> myAtom = invokeHandler(chkMyCheck,w32HClick,{})
> end procedure
>
> My checkbox handler does a lot of things, one of which is to repaint virtually
> every control on the screen (if that matters), along with present the results
> of a calculation in a textbox (just one of many controls on the screen).
>
> If I pull out the sleep(1) line, then the system does something that seems
> like
> there is a bit of code somewhere I've forgotten about (which I generally refer
> to as a poltergeist), because the above code runs twice, the first time with
> the value of chkMyCheck appropriately changed from what it started out as and
> the second time with the opposite. That is, the second time it is run with
> the value of chkMyCheck exactly as chkMyCheck started, thereby putting a
> result
> on the screen which is the same as when I started (obviously a bit
> unproductive,
> complete with the check mark appearing for an instant and then resetting
> itself
> back to how it started.
>
> If I insert any CPU halting mechanism at any point in time (a sleep command,
> or a message box) then the second execution is not done, the check box is
> appropriately
> changed only once and the value displayed in the textbox is the correct
> (updated)
> value.
>
> As another hint as to what is going on, if I remove the sleep and message box
> commands, I can still get it to work, if I click on the label and hold down
> the left click button for a full second before letting it up.
>
> I could understand how holding the left click button down might cause the
> event
> to be registered twice, but this is the exact opposite. By clicking quickly
> and lightly it executes twice. By clicking once (very slowly and heavily) it
> only executes once. Baffling to me.
>
> If that is enough information to trigger somebody's (terrible) memory of
> something
> similar I'd love to hear about it.
>
> Thanks
>
> Mike
1/ add a ?123 somewhere in what you expect to be your only handler for the
ckeckbox, and unambiguously determine whether it is run once or twice.
2/ If you get two of them, then search your entire project for the name of the
supposedly unique handler. That will point you to the place(s) where it is called
while you had forgotten about it.
3/ If you get only one of them, call getHandler(chkMyCheck,w32HClick),
getHandler(Screen,w32HClick) and determine whether two or more pieces of code
toggle the check box.
4/ create, outside IDE, a very basic window, a very basic w32HClick handler for
it, and see what happens when you click the window. Perhaps your mouse is sending
things it shouldn't, and you'll see it that way.
Actually I'd start with 4/.
CChris
3. Re: Unexplainable behavior
Mike777 wrote:
>
> I'm posting this follow up under a new subject because I'm at my wits end on
> this and would like somebody (anybody?) to take another look to see if
> anything
> pops out.
From memory, the setCheck routine automatically invokes the handler for the
checkbox already so you don't have to do it manually.
Try this instead ...
procedure lblchkMyCheck_onClick (integer self, integer event, sequence params)
atom myAtom
setCheck(chkMyCheck,not(isChecked(chkMyCheck)))
end procedure
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
4. Re: Unexplainable behavior
Mike777 wrote:
>
> I'm posting this follow up under a new subject because I'm at my wits end on
> this and would like somebody (anybody?) to take another look to see if
> anything
> pops out.
>
> I have a handler for a checkbox onClick event that I want to fire when the
> user
> clicks on a label to the left of the checkbox. I would presume this is fairly
> common behaviour.
I'm gonna stop you right there. I don't presume this to be common practice at
all. You're kind of re-inventing the wheel here. If you give a CheckBox a title
when you create it, that text will appear to the right of the box, and be
click-able and trigger onClick (w32HClick) events automatically. I see no sense
in creating an additional label to receive the click events. If all you want is
to place the label on the left side of the box, just use the BS_LEFTTEXT style.
-Greg
5. Re: Unexplainable behavior
Greg Haberek wrote:
>
> Mike777 wrote:
> >
> > I'm posting this follow up under a new subject because I'm at my wits end on
> > this and would like somebody (anybody?) to take another look to see if
> > anything
> > pops out.
> >
> > I have a handler for a checkbox onClick event that I want to fire when the
> > user
> > clicks on a label to the left of the checkbox. I would presume this is
> > fairly
> > common behaviour.
>
> I'm gonna stop you right there. I don't presume this to be common practice at
> all. You're kind of re-inventing the wheel here. If you give a CheckBox a
> title
> when you create it, that text will appear to the right of the box, and be
> click-able
> and trigger onClick (w32HClick) events automatically. I see no sense in
> creating
> an additional label to receive the click events. If all you want is to place
> the label on the left side of the box, just use the BS_LEFTTEXT style.
Greg,
I'd be happy to give this a try. Is there a method whereby I can reset the text
to appear with respect to the control I already have? The control is referred to
a number of places in the code and if I delete that control and replace it with a
new one it will take me quite a while to hunt down all the places that the name
has to be edited. I've already tried setting the BS_LEFTTEXT style, but it
doesn't seem to have any impact on the existing checkbox.
Thanks
Mike
6. Re: Unexplainable behavior
Mike777 wrote:
>
> Greg Haberek wrote:
> >
> > Mike777 wrote:
> > >
> > > I'm posting this follow up under a new subject because I'm at my wits end
> > > on
> > > this and would like somebody (anybody?) to take another look to see if
> > > anything
> > > pops out.
> > >
> > > I have a handler for a checkbox onClick event that I want to fire when the
> > > user
> > > clicks on a label to the left of the checkbox. I would presume this is
> > > fairly
> > > common behaviour.
> >
> > I'm gonna stop you right there. I don't presume this to be common practice
> > at
> > all. You're kind of re-inventing the wheel here. If you give a CheckBox a
> > title
> > when you create it, that text will appear to the right of the box, and be
> > click-able
> > and trigger onClick (w32HClick) events automatically. I see no sense in
> > creating
> > an additional label to receive the click events. If all you want is to place
> > the label on the left side of the box, just use the BS_LEFTTEXT style.
>
> Greg,
>
> I'd be happy to give this a try. Is there a method whereby I can reset the
> text to appear with respect to the control I already have? The control is
> referred
> to a number of places in the code and if I delete that control and replace it
> with a new one it will take me quite a while to hunt down all the places that
> the name has to be edited. I've already tried setting the BS_LEFTTEXT style,
> but it doesn't seem to have any impact on the existing checkbox.
>
> Thanks
>
> Mike
Could you post the statements that create the checkbox and the label? That would
help deciding whether your design is weird from Windows' standpoint or not.
In case this is the issue, a checkbox comes with a label already. By default, it
displays on the right of the small square, and you can switch it to the left as
Greg mentioned. Did you, by any chance, create the checkbox with an empty caption
and then a label to hold the text? This is usually uselessly complex, set the
checkbox caption instead.
btw Derek: setCheck() only sends the BM_SETCHECK message to the button, which
has no effect other than toggling the check mark, assuming the style of the
button defines any.
CChris
7. Re: Unexplainable behavior
CChris wrote:
>
> Mike777 wrote:
> >
> > Greg Haberek wrote:
> > >
> > > Mike777 wrote:
> > > >
> > > > I'm posting this follow up under a new subject because I'm at my wits
> > > > end on
> > > > this and would like somebody (anybody?) to take another look to see if
> > > > anything
> > > > pops out.
> > > >
> > > > I have a handler for a checkbox onClick event that I want to fire when
> > > > the
> user</font></i>
> > > > clicks on a label to the left of the checkbox. I would presume this is
> > > > fairly
> > > > common behaviour.
> > >
> > > I'm gonna stop you right there. I don't presume this to be common practice
> > > at
> > > all. You're kind of re-inventing the wheel here. If you give a CheckBox a
> > > title
> > > when you create it, that text will appear to the right of the box, and be
> > > click-able
> > > and trigger onClick (w32HClick) events automatically. I see no sense in
> > > creating
> > > an additional label to receive the click events. If all you want is to
> > > place
> > > the label on the left side of the box, just use the BS_LEFTTEXT style.
> >
> > Greg,
> >
> > I'd be happy to give this a try. Is there a method whereby I can reset the
> > text to appear with respect to the control I already have? The control is
> > referred
> > to a number of places in the code and if I delete that control and replace
> > it
> > with a new one it will take me quite a while to hunt down all the places
> > that
> > the name has to be edited. I've already tried setting the BS_LEFTTEXT
> > style,
> > but it doesn't seem to have any impact on the existing checkbox.
> >
> > Thanks
> >
> > Mike
>
> Could you post the statements that create the checkbox and the label? That
> would
> help deciding whether your design is weird from Windows' standpoint or not.
Here's the code that is generated by the IDE for the checkbox:
constant chkMyCheck = createEx( CheckBox, "chkMyCheck", Window1, 230, 571, 13,
20, 0, 0 )
setFont( chkMyCheck,"MS Sans Serif",8,Normal+Bold)
Here's the code that is generated by the IDE for the label:
constant lblchkMyCheck = createEx( RText, "Use the first one? ", Window1, 80,
571, 146, 20, 0, 0 )
> In case this is the issue, a checkbox comes with a label already. By default,
> it displays on the right of the small square, and you can switch it to the
> left
> as Greg mentioned. Did you, by any chance, create the checkbox with an empty
> caption and then a label to hold the text? This is usually uselessly complex,
> set the checkbox caption instead.
The message you are responding to indicates that I am attempting to do that and
failing. BTW, I had done this originally because I wanted the text to be a bit
more fancy than I could get the attached label to appear as. I've since given up
on that so if I can just restore the label to the check I'd be happy (if clicking
it once does what it is supposed to do, which it should, but then again what I've
currently got "should").
> btw Derek: setCheck() only sends the BM_SETCHECK message to the button, which
> has no effect other than toggling the check mark, assuming the style of the
> button defines any.
?123 didn't do anything for me (I don't seem to get a box of any sort showing up
anywhere, although I suppose I just didn't look in the right spot). Instead, I
created a global integer and +=1'd it and then I display it in the status bar.
It proves that my execution count was correct. It increments by one when I click
the checkbox (slow or fast). It increments by one if I leave the sleep(1) in
place or I hold down the left click for a long time. It increments by two if I
click quickly without a sleep(1).
Mike
8. Re: Unexplainable behavior
- Posted by Bernie Ryan <xotron at blu?f?og.com>
Jan 29, 2008
-
Last edited Jan 30, 2008
Mike and CChris:
RText is a STATIC control you have to set the SS_NOTIFY style to
have it notify it's parent.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
9. Re: Unexplainable behavior
- Posted by CChris <christian.cuvier at agri?ulture.go?v.fr>
Jan 29, 2008
-
Last edited Jan 30, 2008
Bernie Ryan wrote:
>
>
> Mike and CChris:
>
> RText is a STATIC control you have to set the SS_NOTIFY style to
>
> have it notify it's parent.
>
> Bernie
>
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
Very true.
However Mike appears to get too many mouse clicks, not not enough.
The safest bet is that the techniques I suggested will show earlier code lurking
in the background, or a funky mouse.
CChris
10. Re: Unexplainable behavior
- Posted by Mike777 <anon4321 at gmai?.c?m>
Jan 29, 2008
-
Last edited Jan 30, 2008
Greg, Chris, et al,
> > > > I'm gonna stop you right there. I don't presume this to be common
> > > > practice at
> > > > all. You're kind of re-inventing the wheel here. If you give a CheckBox
> > > > a title
> > > > when you create it, that text will appear to the right of the box, and
> > > > be
> click-able</font></i>
> > > > and trigger onClick (w32HClick) events automatically. I see no sense in
> > > > creating
> > > > an additional label to receive the click events. If all you want is to
> > > > place
> > > > the label on the left side of the box, just use the BS_LEFTTEXT style.
I misspoke. I meant only that clicking the label should operate the same as
clicking the checkbox. I didn't mean to imply that it is common practice to have
the label in a separate control.
> > > I'd be happy to give this a try. Is there a method whereby I can reset
> > > the
> > > text to appear with respect to the control I already have?
Got it. I had shrunk the size of the checkbox to the point where it was just
barely visible within the size of the control. When I expanded the size, the
label showed up and its behaviour is as expected.
> I created a global integer and +=1'd it and then I display it in the status
> bar. It proves that my execution count was correct. It increments by one
> when
> I click the checkbox (slow or fast). It increments by one if I leave the
> sleep(1)
> in place or I hold down the left click for a long time. It increments by two
> if I click quickly without a sleep(1).
There is a part of me that is just a bit queasy about my codebase at the moment,
because there is something in there that is not operating as expected. I'll take
a snapshot of this before I fix things and at least be able to call this back up
to experiment.
But, for now, it is on to the next issue.
Thanks
Mike
