[Gambas-user] Program going off the rails in a way I can't explain. Help?

Discussion:

Bill Richman

2010-01-18 14:23:19 UTC

I've got a really weird problem going on. I've been working on this
project for about a month, and today I decided to make some major
changes to the user interface operates. I moved some code around and
delete some code, and now when I run it in the IDE, it randomly jumps
into the sub that handles the click event for a combo-box control called
cbBedList_Click(). The routine "Populate_cbBedList()" gets called by
"Form_Open", and reads values from a database to populate the
Combo-box. As far as I can remember, I haven't changed the code for
this form at all, but seemingly for no reason, when it hits line "178
cbBedList.Clear" in the Populate sub, it starts executing the code in
cbBedList_Click! This generates an error because the cbBedList.index
value isn't set, since it wasn't actually clicked. If I remark out the
contents of the Click event, the Populate routine finishes, although I
still see the debug statement from line 169. If I remark out everything
from 168-173, it still runs fine (although obviously I don't get click
events handled for the combo-box any longer!). I'm pulling my hair
out. The stack backtrace shows:

FMain.cbBedList_Click.169
(native code)
FMain.Populate_cbBedList.178
FMain.Form_Open.26

Setting a breakpoint at 178 and single-stepping shows exactly what the
backtrace does; the next line to be executed after 178 is 169! ANY
ideas??? Please?

===

168 PUBLIC SUB cbBedList_Click()
169 DEBUG "We're in cbBedList_Click()!"
170 ' BedNum = BedList[cbBedList.index + 1]
171 ' DrawPlots($db, BedNum)
172
173 END
174
175 PUBLIC SUB Populate_cbBedList()
176 DIM sql AS String
177 'populate the bed selection listbox
178 cbBedList.Clear
179 sql = "select bedname, bednum from Beds"
180 $res = $db.Exec(sql)
181 DEBUG "$res.Count=" & $res.Count
182 FOR EACH $res
183 DEBUG "$res!BedName=" & $res!BedName
184 cbBedList.Add($res!BedName)
185 DEBUG "cbBedList.count=" & cbBedList.Count
186 DEBUG "$res!BedNum=" & $res!BedNum
187 BedList[cbBedList.count] = $res!BedNum
188 NEXT
189 END

--
Bill Richman - Lincoln, Nebraska
Tilter at windmills, maker of pies in the sky, & curmudgeon
email: ***@geektrap.com web: www.geektrap.com

Benoît Minisini

2010-01-18 14:46:11 UTC

Permalink

Post by Bill Richman
I've got a really weird problem going on. I've been working on this
project for about a month, and today I decided to make some major
changes to the user interface operates. I moved some code around and
delete some code, and now when I run it in the IDE, it randomly jumps
into the sub that handles the click event for a combo-box control called
cbBedList_Click(). The routine "Populate_cbBedList()" gets called by
"Form_Open", and reads values from a database to populate the
Combo-box. As far as I can remember, I haven't changed the code for
this form at all, but seemingly for no reason, when it hits line "178
cbBedList.Clear" in the Populate sub, it starts executing the code in
cbBedList_Click! This generates an error because the cbBedList.index
value isn't set, since it wasn't actually clicked. If I remark out the
contents of the Click event, the Populate routine finishes, although I
still see the debug statement from line 169. If I remark out everything
from 168-173, it still runs fine (although obviously I don't get click
events handled for the combo-box any longer!). I'm pulling my hair
FMain.cbBedList_Click.169
(native code)
FMain.Populate_cbBedList.178
FMain.Form_Open.26
Setting a breakpoint at 178 and single-stepping shows exactly what the
backtrace does; the next line to be executed after 178 is 169! ANY
ideas??? Please?
===
168 PUBLIC SUB cbBedList_Click()
169 DEBUG "We're in cbBedList_Click()!"
170 ' BedNum = BedList[cbBedList.index + 1]
171 ' DrawPlots($db, BedNum)
172
173 END
174
175 PUBLIC SUB Populate_cbBedList()
176 DIM sql AS String
177 'populate the bed selection listbox
178 cbBedList.Clear
179 sql = "select bedname, bednum from Beds"
180 $res = $db.Exec(sql)
181 DEBUG "$res.Count=" & $res.Count
182 FOR EACH $res
183 DEBUG "$res!BedName=" & $res!BedName
184 cbBedList.Add($res!BedName)
185 DEBUG "cbBedList.count=" & cbBedList.Count
186 DEBUG "$res!BedNum=" & $res!BedNum
187 BedList[cbBedList.count] = $res!BedNum
188 NEXT
189 END

Which version of Gambas do you use? With which GUI component? On which
desktop?

--
Benoît Minisini

Bill Richman

2010-01-18 16:33:50 UTC

Permalink

Post by BenoÃ®t Minisini

Which version of Gambas do you use? With which GUI component? On which
desktop?

Gambas 2.7, gb.gui, Ubuntu Linux 2.6.27-16-generic, Gnome 2.24.1

Benoît Minisini

2010-01-18 17:07:26 UTC

Permalink

Post by Bill Richman

Post by BenoÃ®t Minisini

Which version of Gambas do you use? With which GUI component? On which
desktop?

Gambas 2.7, gb.gui, Ubuntu Linux 2.6.27-16-generic, Gnome 2.24.1

The ComboBox.Clear() method should not raise Click event. This is an old bug
that has been fixed since Gambas 2.7. You should upgrade Gambas, or handle
that specific case in your code by hand (i.e. by using a global variable as a
lock).

Regards,

--
Benoît Minisini

Bill Richman

2010-01-18 23:16:09 UTC

Permalink

Well, I upgraded to Gambas 2.19 using the instructions for Ubuntu
Intrepid found here: http://gambasdoc.org/help/install/ubuntu?view.
Since "Help/About" now reports 2.19, I have to assume that worked, and
I'm still getting the same behavior (jumping into the "_click" event
when running the .clear method of the combo-box control). Although it
seems like it runs the _click handler a couple of times for each call to
.clear, and once during the first usage of the .add method as well:

FMain.Populate_cbBedList.178: About to run cbBedList.Clear
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.Populate_cbBedList.180: Right after cbBedList.Clear
FMain.Populate_cbBedList.185: $res.Count=9
FMain.Populate_cbBedList.187: $res!BedName=first
FMain.cbBedList_Click.169: We're in cbBedList_Click()!

I can try setting up a flag to kick me out of the _click until after the
control is populated, as someone else suggested, but that seems pretty
ugly. Is there some way I can be sure I'm running 2.19 (in which you
noted this bug has been fixed) other than the ?/About menu, or is that
definitive?

Thanks,

-Bill

Bill Richman - Lincoln, Nebraska
Tilter at windmills, maker of pies in the sky, & curmudgeon

Post by BenoÃ®t Minisini

Post by Bill Richman

Post by BenoÃ®t Minisini

Which version of Gambas do you use? With which GUI component? On which
desktop?

Gambas 2.7, gb.gui, Ubuntu Linux 2.6.27-16-generic, Gnome 2.24.1

Doriano Blengino

2010-01-19 07:54:21 UTC

Permalink

Post by Bill Richman
Well, I upgraded to Gambas 2.19 using the instructions for Ubuntu
Intrepid found here: http://gambasdoc.org/help/install/ubuntu?view.
Since "Help/About" now reports 2.19, I have to assume that worked, and
I'm still getting the same behavior (jumping into the "_click" event
when running the .clear method of the combo-box control). Although it
seems like it runs the _click handler a couple of times for each call to
FMain.Populate_cbBedList.178: About to run cbBedList.Clear
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.Populate_cbBedList.180: Right after cbBedList.Clear
FMain.Populate_cbBedList.185: $res.Count=9
FMain.Populate_cbBedList.187: $res!BedName=first
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
I can try setting up a flag to kick me out of the _click until after the
control is populated, as someone else suggested, but that seems pretty
ugly. Is there some way I can be sure I'm running 2.19 (in which you
noted this bug has been fixed) other than the ?/About menu, or is that
definitive?

I think that setting up a flag won't hurt anyway, even if it is ugly.
The whole GUI world (not only gambas) seems to have this kind of
mentality (to raise an event in response to modifications made by code),
so even where this problem does not show, may be in the future it will
(this is called "update a software to the latest version").

Regards,
Doriano

Kadaitcha Man

2010-01-19 08:37:53 UTC

Permalink

Post by Doriano Blengino
I think that setting up a flag won't hurt anyway, even if it is ugly.
The whole GUI world (not only gambas) seems to have this kind of
mentality (to raise an event in response to modifications made by code),

1) Flags are necessary in any GUI.

2) Events caused by code should fire as if the user had performed the function.

Otherwise the performing code would have to emulate the control's
event sequence and there goes OO encapsulation. not to mention the
need to write unnecessary and oft-repeating code.

HTH

Doriano Blengino

2010-01-19 09:12:46 UTC

Permalink

Post by Kadaitcha Man

1) Flags are necessary in any GUI.

Post by Kadaitcha Man
2) Events caused by code should fire as if the user had performed the function.
Otherwise the performing code would have to emulate the control's
event sequence and there goes OO encapsulation. not to mention the
need to write unnecessary and oft-repeating code.

Debatable (but I am unwilling to debate).
Is it more oft-repeating and unnecessary to write:

combo1.add('An item")
combo1_click ' would be better to "raise an event to an object"

(note: 2 lines of code, and only one is meaningful to our discussion) or

private bUpdatingCombo as boolean
...
bUpdatingCombo = true
combo1.add("An item")
bUpdatingCombo = false
...
' (later, in combo1_click)
if bUpdatingCombo then return
...

(note: 4 lines of code needed and a global variable used in three
different places).

And things can be more complicated than this stupid example if there is
some inheritance involved - which is the order of execution of the
several event handler? And should we block every event handler in the
hierarchy (if it is possible) or just some? What happens behind the
scenes (encapsulation!)?

Regards,
Doriano

Kadaitcha Man

2010-01-19 09:20:52 UTC

Permalink

Post by Doriano Blengino

Post by Kadaitcha Man

1) Flags are necessary in any GUI.

Debatable (but I am unwilling to debate).

Hey, I don't want to get into an argument, but the fact that you
posted code really blew your "I am unwilling to debate" line right out
of the water :)

Kadaitcha Man

2010-01-19 09:24:30 UTC

Permalink

combo1.add('An item")
combo1_click ' would be better to "raise an event to an object"

My last post aside, it is not the job of the calling code to know what
the called code should do. Nor is the job of the calling code to do
what the called code ought to have done if it was not done.

End of discussion.

Regards,

Charlie Reinl

2010-01-19 17:39:05 UTC

Permalink

Post by BenoÃ®t Minisini

Post by Bill Richman

Post by BenoÃ®t Minisini

Which version of Gambas do you use? With which GUI component? On which
desktop?

Gambas 2.7, gb.gui, Ubuntu Linux 2.6.27-16-generic, Gnome 2.24.1

Salut Bill,

in an simple example I tried with qt and gtk and that ComboBox_click()
is not fired here.

gambas2 2.19.0 rev.2613

As you told, you striped of a lot of code.

One idea, make a Source archive (Ctrl+Alt+A) from your project, unpack
it in a different place, load it into the IDE, and try it.
--
Amicalement
Charlie

[OperatingSystem]
OperatingSystem=Linux
KernelRelease=2.6.24-26-generic
DistributionVendor=ubuntu
DistributionRelease="Ubuntu 8.04.3 LTS"

[System]
CPUArchitecture=i686
TotalRam=506932 kB

[Gambas]
Gambas1=gbx-1.0.17
Gambas1Path=/usr/bin/gbx

Gambas2=2.19.0 rev.2613
Gambas2Path=/usr/local/bin/gbx2

Gambas3=2.99.0 rev.2602 (can't compile actually)
Gambas3Path=/usr/local/bin/gbx3

Charlie Reinl

2010-01-18 15:39:06 UTC

Permalink

Salut Bill,

first question : which gambas 2 or 3 ?
second question : did you update that gambas ?
third question : did you try to make a ALT-F7 (compile all) in the IDE ?

there was said something about fired event by code, look in the archive.

As workaround, you can set a bIsPopulate which is set to FALSE between
line 177 - 178 and to TRUE after the Next.

And in cbBedList_Click you don't do anything if NOT bIsPopulate .

--
Amicalement
Charlie

Bill Richman

2010-01-18 16:36:52 UTC

Permalink

Post by Charlie Reinl

Salut Bill,
first question : which gambas 2 or 3 ?
second question : did you update that gambas ?
third question : did you try to make a ALT-F7 (compile all) in the IDE ?
there was said something about fired event by code, look in the archive.
As workaround, you can set a bIsPopulate which is set to FALSE between
line 177 - 178 and to TRUE after the Next.
And in cbBedList_Click you don't do anything if NOT bIsPopulate .

Gambas 2.7, gb.gui, Ubuntu Linux 2.6.27-16-generic, Gnome 2.24.1
I'm not sure what you mean by "update" gambas. To what? I tried
"compile all" because I'd been cutting and pasting code around and
thought it might be confused about locations in the compiled code, but
it didn't seem to help. Thanks for the workaround suggestion; I'll keep
it in mind in case I can't resolve this problem.

-Bill

Bill Richman

2010-01-18 16:44:19 UTC

Permalink

I added some debugging output. Screenshot of code with line numbers is
attached. (Is there any way to copy or save the code _with_ the line
numbers for purposes like this?)

Console output when run:

FMain.Populate_cbBedList.178: About to run cbBedList.Clear
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.Populate_cbBedList.180: Right after cbBedList.Clear
FMain.Populate_cbBedList.185: $res.Count=9
FMain.Populate_cbBedList.187: $res!BedName=first
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.Populate_cbBedList.190: cbBedList.count=1
FMain.Populate_cbBedList.191: $res!BedNum=1
FMain.Populate_cbBedList.187: $res!BedName=second
FMain.Populate_cbBedList.190: cbBedList.count=2
FMain.Populate_cbBedList.191: $res!BedNum=2
FMain.Populate_cbBedList.187: $res!BedName=NewTest
FMain.Populate_cbBedList.190: cbBedList.count=3
FMain.Populate_cbBedList.191: $res!BedNum=3
FMain.Populate_cbBedList.187: $res!BedName=Big Bed
FMain.Populate_cbBedList.190: cbBedList.count=4
FMain.Populate_cbBedList.191: $res!BedNum=4
FMain.Populate_cbBedList.187: $res!BedName=Another bed
FMain.Populate_cbBedList.190: cbBedList.count=5
FMain.Populate_cbBedList.191: $res!BedNum=5
FMain.Populate_cbBedList.187: $res!BedName=yet another bed
FMain.Populate_cbBedList.190: cbBedList.count=6
FMain.Populate_cbBedList.191: $res!BedNum=6
FMain.Populate_cbBedList.187: $res!BedName=and another
FMain.Populate_cbBedList.190: cbBedList.count=7
FMain.Populate_cbBedList.191: $res!BedNum=7
FMain.Populate_cbBedList.187: $res!BedName=test123
FMain.Populate_cbBedList.190: cbBedList.count=8
FMain.Populate_cbBedList.191: $res!BedNum=8
FMain.Populate_cbBedList.187: $res!BedName=asdfasdf
FMain.Populate_cbBedList.190: cbBedList.count=9
FMain.Populate_cbBedList.191: $res!BedNum=9

--
Bill Richman - Lincoln, Nebraska
Tilter at windmills, maker of pies in the sky, & curmudgeon
email: ***@geektrap.com web: www.geektrap.com

Bill Richman

2010-01-18 23:09:22 UTC

Permalink

Thanks for the suggestions. I updated to Gambas 2.19, but that didn't
seem to help. I assume you're referring to the files it creates in the
.gambas folder inside each project folder? I've deleted those -
although I think that what the "Clean up" option does - and re-run the
program. The files in .gambas reappear, and I'm still getting the
behavior where it jumps randomly into the event routine when I call the
.clear method of the combo-box control:

FMain.Populate_cbBedList.178: About to run cbBedList.Clear
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.Populate_cbBedList.180: Right after cbBedList.Clear
FMain.Populate_cbBedList.185: $res.Count=9
FMain.Populate_cbBedList.187: $res!BedName=first
FMain.cbBedList_Click.169: We're in cbBedList_Click()!
FMain.Populate_cbBedList.190: cbBedList.count=1
FMain.Populate_cbBedList.191: $res!BedNum=1

I can try what someone else suggested - setting a flag after populating
the combo-box to tell me if I'm supposed to be in the event or not - but
that seems kind of ugly.

Bill Richman - Lincoln, Nebraska
Tilter at windmills, maker of pies in the sky, & curmudgeon

Bill,
I've intermittently had this problem - I think in my case it was because I'd
made changes to the code, saved it, but gambas was running on an old pre-
compiled version.
I cleaned up the project, deleted all the compiled files, re-compiled and it
seemed to fix the problem.
Let me know if that helps for interest.
Regards
Richard