[VFP 9] strange problem

In a form.method(), I have these:
local m.xx
m.xx=empty(thisform.mode)
with thisform.cnCode
.cmd.enabled=m.xx
.txt.enabled=m.xx
endwith

When the .txt.enabled was set to m.xx, the form entered endless loop. If
I set .txt.enabled to either .t. or .f. without referencing m.xx, it
would be ok.

What could cause this problem?


--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Denis
Fri Jan 05 07:40:40 CST 2007

Hi

It is not a good idea to use the m. prefix. Look in the scatter and gather
commands for more info on the m. qualifier. If you are just starting out
then search the help also for naming conventions. But to solve your problem
why not just use

.cmd.enabled=empty(thisform.mode)

hth
Denis

"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:%236iQo4KMHHA.448@TK2MSFTNGP04.phx.gbl...
>
> In a form.method(), I have these:
> local m.xx
> m.xx=empty(thisform.mode)
> with thisform.cnCode
> .cmd.enabled=m.xx
> .txt.enabled=m.xx
> endwith
>
> When the .txt.enabled was set to m.xx, the form entered endless loop. If I
> set .txt.enabled to either .t. or .f. without referencing m.xx, it would
> be ok.
>
> What could cause this problem?
>
>
> --
> iTech Consulting Co., Ltd.
> Specialized in providing ePOS solutions
> Website: http://www.itech.com.hk (IE only)
> Tel: (852) 2325 3883 Fax: (852)2325 8288

Olaf
Fri Jan 05 08:38:51 CST 2007

> When the .txt.enabled was set to m.xx, the form entered endless loop.

in what matter entered it endless loop?

Do you have some enabled_assign method
that does something which again would
trigger the method you were in?

Bye, Olaf.

Man-wai
Fri Jan 05 08:39:21 CST 2007

> why not just use
> .cmd.enabled=empty(thisform.mode)

The form would again enter endless loop. I need to use task manager to
kill VFP in order to get out. The assignment of .txt.enabled to a value
other than the constants .T. and .F. would trigger the endless.

IN fact, the statement you posted was the original implementation.

READ MY problem again. :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 22:37:01 up 24 days 4:49 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Bernhard
Fri Jan 05 08:46:19 CST 2007

Hi Denis,

> It is not a good idea to use the m. prefix. Look in the scatter and gather
> commands for more info on the m. qualifier. If you are just starting out
> then search the help also for naming conventions.

Why should it be a bad idea to use the m. prefix?

The m. prefix is the only reliable way to distinguish between a memory variable
and a table field with the same name. Even if you write TABLE.FIELD, this is not
sure, whether it is a table field or an object property. Only M.TABLE.FIELD is
the object property. If you omit the m. prefix and foxpro finds a table field
with the same name, then foxpro always takes the table field.
To be sure to use the thing you want, it is very recommended to always use the
m. prefix with a memory variable.

Regards
Bernhard Sander

Gregory
Fri Jan 05 08:56:16 CST 2007

Who cares about YOUR problem ?
________________
"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:%23HGI$cNMHHA.448@TK2MSFTNGP04.phx.gbl...
>> why not just use
>> .cmd.enabled=empty(thisform.mode)
>
> The form would again enter endless loop. I need to use task manager to
> kill VFP in order to get out. The assignment of .txt.enabled to a value
> other than the constants .T. and .F. would trigger the endless.
>
> IN fact, the statement you posted was the original implementation.
>
> READ MY problem again. :)
>
> --
> .~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
> ^ ^ 22:37:01 up 24 days 4:49 0 users load average: 1.00 1.00 1.00
> news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Paul
Fri Jan 05 13:28:25 CST 2007


"Bernhard Sander" <fuchs@no.spam> wrote in message
news:e6pkEhNMHHA.5012@TK2MSFTNGP02.phx.gbl...
> Hi Denis,
>
>> It is not a good idea to use the m. prefix. Look in the scatter and
>> gather commands for more info on the m. qualifier. If you are just
>> starting out then search the help also for naming conventions.
>
> Why should it be a bad idea to use the m. prefix?
>
> The m. prefix is the only reliable way to distinguish between a memory
> variable and a table field with the same name. Even if you write
> TABLE.FIELD, this is not sure, whether it is a table field or an object
> property. Only M.TABLE.FIELD is the object property. If you omit the m.
> prefix and foxpro finds a table field with the same name, then foxpro
> always takes the table field.
> To be sure to use the thing you want, it is very recommended to always use
> the m. prefix with a memory variable.
>
> Regards
> Bernhard Sander


I agree, with the additional observation that m. is not required on the left
side of assignment statements.

For instance:

x = 5 && "m.x = 5" is NOT needed
y = m.x && m. is preferred

Dan
Fri Jan 05 15:07:55 CST 2007

Great catch, Olaf!

Simple assignments CANNOT "enter an endless loop". Bad programming in assign
methods CERTAINLY can.

It's like the old days when people would issue SHOW GETS in the SHOW clause
and wonder why the code would loop enlessly. <g>

Dan

Olaf Doschke wrote:
>> When the .txt.enabled was set to m.xx, the form entered endless loop.
>
> in what matter entered it endless loop?
>
> Do you have some enabled_assign method
> that does something which again would
> trigger the method you were in?
>
> Bye, Olaf.

Man-wai
Fri Jan 05 22:57:31 CST 2007


> Who cares about YOUR problem ?

Should I care your complaint, Mr. M9?

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 12:56:01 up 24 days 19:08 0 users load average: 1.03 1.03 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Fri Jan 05 22:58:21 CST 2007

> Simple assignments CANNOT "enter an endless loop". Bad programming in assign
> methods CERTAINLY can.
>
> It's like the old days when people would issue SHOW GETS in the SHOW clause
> and wonder why the code would loop enlessly. <g>

Unfortunately, I didn't use any _access or _assign method. In fact,
haven't seen a need for them.

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 12:57:01 up 24 days 19:09 0 users load average: 1.01 1.02 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Fri Jan 05 22:59:39 CST 2007

> in what matter entered it endless loop?

In a custom method. Please read my question again.

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 12:58:01 up 24 days 19:10 0 users load average: 1.00 1.02 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Thomas
Sat Jan 06 04:14:38 CST 2007

Man-wai Chang schrieb:
>>Simple assignments CANNOT "enter an endless loop". Bad programming in assign
>>methods CERTAINLY can.
>>
>>It's like the old days when people would issue SHOW GETS in the SHOW clause
>>and wonder why the code would loop enlessly. <g>
>
>
> Unfortunately, I didn't use any _access or _assign method. In fact,
> haven't seen a need for them.
>
Still the error is probably something special in YOUR code,
because I bet that using base vfp such a method alone will not
loop endlessly.

create a bare prg still showing the error...

regards

thomas

Olaf
Sat Jan 06 06:18:27 CST 2007

> In a custom method. Please read my question again.
so what happens, if you debug and singlestep through it?
Does the method start over, does the program pointer
not move forward? Simply tell what happens!

Or is it simply, that the form is modal?

In what way is it endless????

There must be something repeating/going on and
you should be able to see it in debugger, log it
or simply use wait windows at the method which
loops and display something.

Maybe you have some bindevent which causes
a reentry.

Bye, Olaf.

Olaf
Sat Jan 06 06:36:56 CST 2007

> local m.xx
> m.xx=empty(thisform.mode)
> with thisform.cnCode
> .cmd.enabled=m.xx
> .txt.enabled=m.xx
> endwith

> When the .txt.enabled was set to m.xx, the form entered endless loop. If
> I set .txt.enabled to either .t. or .f. without referencing m.xx, it
> would be ok.


> What could cause this problem?
I can't replicate.

The pragmatic solution, if .T. and .F. instead of m.xx works for you would
of course be:

local xx
xx=empty(thisform.mode)
with thisform.cnCode
if m.xx
.cmd.enabled=.T.
.txt.enabled=.T.
else
.cmd.enabled=.F.
.txt.enabled=.F.
endif
endwith

Bye, Olaf.

Thomas
Sat Jan 06 07:28:35 CST 2007

Olaf Doschke schrieb:
>
> The pragmatic solution, if .T. and .F. instead of m.xx works for you would
> of course be:
>
> local xx
> xx=empty(thisform.mode)
> with thisform.cnCode
> if m.xx
> .cmd.enabled=.T.
> .txt.enabled=.T.
> else
> .cmd.enabled=.F.
> .txt.enabled=.F.
> endif
> endwith
>
That kind of cheating is not allowed on weekends when there should be
ample time to try to find true reasons! And yes, I can't replicate
either - see below (why didn't you post earlier <bg>):

thomas

LOCAL loForm
loForm = CREATEOBJECT("form_class")
loForm.Show()
READ events

DEFINE CLASS cnt_class as Container
top = 10
height = 100
width = 200
ADD OBJECT cmd as CommandButton ;
WITH top = 10, left = 10, caption = "Button"

ADD OBJECT txt as Textbox ;
WITH top = 40, left = 10

FUNCTION cmd.click()
= thisform.Tst_Form()

ENDDEFINE

DEFINE CLASS frm_btn as CommandButton
top = 300
enddefine

DEFINE CLASS btn_exit as frm_btn
caption = "Exit"
left = 300
FUNCTION click()
clear events
enddefine

DEFINE CLASS btn_Test as frm_btn
caption = "Test"
left = 100
FUNCTION click()
= thisform.Tst_Form()
enddefine

DEFINE CLASS form_class as form
height = 400
Width = 400

mode = "U"

ADD OBJECT cnCode as cnt_class
ADD OBJECT cmdExit as btn_Exit
ADD OBJECT cmdTest as btn_Test

FUNCTION tst_form()
*-- strict copy from description
local m.xx
m.xx=empty(thisform.mode)
with thisform.cnCode
.cmd.enabled=m.xx
.txt.enabled=m.xx
endwith

enddefine

Man-wai
Sat Jan 06 07:48:28 CST 2007

> Still the error is probably something special in YOUR code,
> because I bet that using base vfp such a method alone will not
> loop endlessly.
> create a bare prg still showing the error...

Micro$oft is famous to act like demo-god. If a problem
couldn't demonstrated by a simpler program, then the bug
could have been spotted earlier. :)

On the other hand, I would try to keep the case and see
whether I would have a chance to verify it after we met
after death. Stay tuned! :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 21:46:01 up 25 days 3:58 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Sat Jan 06 07:50:24 CST 2007

> That kind of cheating is not allowed on weekends when there should be
> ample time to try to find true reasons! And yes, I can't replicate
> either - see below (why didn't you post earlier <bg>):

Come on, you rich boys and girls. Fly over to Hong Kong tomorrow. I
heard US Marines could be deployed to anywhere within 2 hours in the
future. SO fly over here and let me demonstrate it right in front of
your penxs and vagxna. :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 21:49:01 up 25 days 4:01 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Sat Jan 06 07:49:14 CST 2007

> local xx
> xx=empty(thisform.mode)
> with thisform.cnCode
> if m.xx
> .cmd.enabled=.T.
> .txt.enabled=.T.
> else
> .cmd.enabled=.F.
> .txt.enabled=.F.
> endif


No use. I have tried it already. :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 21:48:01 up 25 days 4:00 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Olaf
Sat Jan 06 08:55:37 CST 2007


> No use. I have tried it already. :)
Well, then you gave us wrong informations.
You said setting it to .T. or .F. instead
of m.xx works...

Have you tried single stepping through the
code with the debugger?

set step on
Local m.xx
...

Then see what happens in the debugger.

Maybe the offending line isn't ...=m.xx but
access of thisform.mode. This must be a user
defined property. You are sure, there is no
mode_access() method? If there is the debugger
would show you.

As Thomas example does work without an endless
loop there must be some condition/code anything
outside from what you showed us taking effect.

I believe you, that you get that "endless loop", but
we can't reproduce or analize without further
informations. So you should add some more
information.

If it works in debugging mode, then it may have to do
with focus. Could it be all controls are disabled after
you set those two to enabled=.f. and there is some
code trying to give focus to anything, failing, retrying,
failing, retrying...?

Bye, Olaf.

Dan
Sat Jan 06 16:27:26 CST 2007

Olaf Doschke wrote:
> If it works in debugging mode, then it may have to do
> with focus. Could it be all controls are disabled after
> you set those two to enabled=.f. and there is some
> code trying to give focus to anything, failing, retrying,
> failing, retrying...?

In FPW we used to call that the "pinball machine effect". <g>

You could literally watch focus trying to bounce around from disabled
control to disabled control in a never-ending circle, like a pinball
machine.

Dan

Thomas
Sat Jan 06 20:10:43 CST 2007

Man-wai Chang schrieb:
>>That kind of cheating is not allowed on weekends when there should be
>>ample time to try to find true reasons! And yes, I can't replicate
>>either - see below (why didn't you post earlier <bg>):
>
>
> Come on, you rich boys and girls. Fly over to Hong Kong tomorrow. I
> heard US Marines could be deployed to anywhere within 2 hours in the
> future. SO fly over here and let me demonstrate it right in front of
> your penxs and vagxna. :)
>

Sure, I'll cramp myself into an airline seat just to have my parts later
treated to vfp code ;-)

Dunno how free you are to let others see/debug your app, you might set
up a zip with your sources and test data and mail it directly if it is
small enough or create a download possibility and mail the download
credentials directly. I would not describe our email-mangling as
"unbreakable encryption", and you should ask the others before sending
megabytes.

Can't see any way of getting deeper into the issue without more info.

regards

thomas

Man-wai
Sun Jan 07 01:47:48 CST 2007

> Dunno how free you are to let others see/debug your app, you might set
> up a zip with your sources and test data and mail it directly if it is
> small enough or create a download possibility and mail the download
> credentials directly. I would not describe our email-mangling as
> "unbreakable encryption", and you should ask the others before sending
> megabytes.

Wait till my current employer fired me. Then I *MIGHT* ask for his
permission to send the code to M$. :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 15:46:01 up 25 days 21:58 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Sun Jan 07 01:49:45 CST 2007

Dan Freeman wrote:
> Olaf Doschke wrote:
>> If it works in debugging mode, then it may have to do
>> with focus. Could it be all controls are disabled after
>> you set those two to enabled=.f. and there is some
>> code trying to give focus to anything, failing, retrying,
>> failing, retrying...?
>
> In FPW we used to call that the "pinball machine effect". <g>
>
> You could literally watch focus trying to bounce around from disabled
> control to disabled control in a never-ending circle, like a pinball
> machine.

No. Trust me. I am sure that I didn't create an endless loop that
spanned over multiple controls from chained reaction.

I didn't have any code searching for a focus, neither, except the code
inside and inherent Foxpro. SO does it mean it's Micro$oft's problem :)

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 15:47:01 up 25 days 21:59 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Olaf
Sun Jan 07 05:01:39 CST 2007

> Wait till my current employer fired me. Then I *MIGHT* ask for his
> permission to send the code to M$. :)
Why to M$?

Of course reporting bugs is important to improve
a product, M$ really cares and does fix bugs.

But neither Thomas nor I work for M$ and he suggested
mailing it to him.

Bye, Olaf.

Olaf
Sun Jan 07 05:07:20 CST 2007


> I didn't have any code searching for a focus, neither, except the code
> inside and inherent Foxpro. SO does it mean it's Micro$oft's problem :)
No, You can design form without any enabled control
that could get focus in VFP6 and above without inducing
an endless loop through that. As Dan said that WAS problem
of FPW.

I'd say the chances are >50% that it's no bug, but induced to
some userdefined code.

As you can't tell us anything further, then how do you
detect or experience the endless loop from the user
perspective?

It still might be something as simple as the form being
modal, so nothing else but the form runs, but that's
no endless loop then...

Is that code in the form's init()? Does anything run after
that method?

Bye, Olaf.

Man-wai
Sun Jan 07 06:24:58 CST 2007

> But neither Thomas nor I work for M$ and he suggested
> mailing it to him.

Saw.... But I cannot do that. The codes belong to my employer.
Need his permission. I keep a checkpoint backup first.

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 20:23:01 up 26 days 2:35 0 users load average: 1.09 1.07 1.01
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Thomas
Sun Jan 07 11:12:16 CST 2007

Man-wai Chang schrieb:
>>But neither Thomas nor I work for M$ and he suggested
>>mailing it to him.
>
>
> Saw.... But I cannot do that. The codes belong to my employer.
> Need his permission. I keep a checkpoint backup first.
>
The only simple thing I can think of right now is to enable the coverage
profiler (also possible in runtime in vfp9) to track the code running
from just before the local definition. Just hope that the coverage file
doesn't get wiped if you kill the app (some on shutdown coding might
help), or try "on escape" or other "on key label " ***interrupt
method*** to stop the endless loop - this is what the doctor orders in
these special cases.

Otherwise I guess you always compare the cost of flying somebody in to
the risk of sending us a possibly stripped down version of the code
which still shows the problem when running on a german or american
OS-version. Or yourself flying out here to show both of us the source
with the cost of only one flight <bg>. Remote Debbuging IS possible, but
that might also be a problem with your boss - I usually use RAdmin and
it works alright.

regards

thomas

Imaginecorp
Sun Jan 07 12:47:35 CST 2007

Its pretty simple...
Man-wai-chang; open the form in class browser, also the calling form...Then
cut and paste both to post on this MB...
Rather than this back and forth... 99.999999999 percent of the time the
programmer has done something wrong.
Seems like some kind of an endless refresh...the "m" prefix WILL NOT produce
what you are describing.

Plus as Denis had pointed out , its much simpler to code:
.cmd.enabled = empty(thisform.mode) OR
.cmd.enabled = iif(empty(thisform.mode),.t.,.f.)

Another thing, if not for Microsoft and VFP, you may have been unemployed...
something to think about

--
Mohammed
www.imaginecorp.com/what_we_do.htm



"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:%236iQo4KMHHA.448@TK2MSFTNGP04.phx.gbl...
>
> In a form.method(), I have these:
> local m.xx
> m.xx=empty(thisform.mode)
> with thisform.cnCode
> .cmd.enabled=m.xx
> .txt.enabled=m.xx
> endwith
>
> When the .txt.enabled was set to m.xx, the form entered endless loop. If I
> set .txt.enabled to either .t. or .f. without referencing m.xx, it would
> be ok.
>
> What could cause this problem?
>
>
> --
> iTech Consulting Co., Ltd.
> Specialized in providing ePOS solutions
> Website: http://www.itech.com.hk (IE only)
> Tel: (852) 2325 3883 Fax: (852)2325 8288

Olaf
Sun Jan 07 15:56:49 CST 2007

Hi again,

For your enjoyment:
http://www.tek-tips.com/viewthread.cfm?qid=1238170&page=1

Bye, Olaf.

Man-wai
Sun Jan 07 20:16:29 CST 2007

> Otherwise I guess you always compare the cost of flying somebody in to
> the risk of sending us a possibly stripped down version of the code
> which still shows the problem when running on a german or american
> OS-version. Or yourself flying out here to show both of us the source
> with the cost of only one flight <bg>. Remote Debbuging IS possible, but
> that might also be a problem with your boss - I usually use RAdmin and
> it works alright.

Oh.. I forgot about this remote thing. Thanks.
Well, I would ask for his permission later. Right now,
I keep a backup of the bug.

--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Man-wai
Sun Jan 07 20:46:45 CST 2007


I found the problem. Foxpro could't find a place to set its focus. Some
controls.tabstop were .f. while some others have object.when() returned
.f.. As a result, Foxpro failed to set foot on anything and kept looping
each control....

Why didn't it just give up and shout "I could not find a focusable
control" is beyond me.

--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Olaf
Mon Jan 08 06:46:13 CST 2007

> Why didn't it just give up and shout "I could not find a focusable
> control" is beyond me.

I wonder. If I eg setup a form with just a disabled textbox,
it's not going to an endless loop.

Now that you know, it should be simple to set up a form with
two controls or something like that, which shows the same effect.

Bye, Olaf.

Man-wai
Mon Jan 08 08:29:59 CST 2007

> I wonder. If I eg setup a form with just a disabled textbox,
> it's not going to an endless loop.
> Now that you know, it should be simple to set up a form with
> two controls or something like that, which shows the same effect.

I don't know. It's possible to reproduce it, but I really don't know. It
could be a bit of tricky in order to hit that big red self-loop switch...

--
.~. Might, Courage, Vision, SINCERITY. http://www.linux-sxs.org
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 6.10) Linux 2.6.19.1
^ ^ 22:28:01 up 27 days 4:40 0 users load average: 1.03 1.04 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Thomas
Mon Jan 08 11:16:39 CST 2007

Man-wai Chang schrieb:
>
> I found the problem. Foxpro could't find a place to set its focus. Some
> controls.tabstop were .f. while some others have object.when() returned
> .f.. As a result, Foxpro failed to set foot on anything and kept looping
> each control....
>
> Why didn't it just give up and shout "I could not find a focusable
> control" is beyond me.
>
This could happen for sure if an explicit "dispatch loop" has been
coded. But I fail to see the connection to the use of m.xx variable
versus .t. or .f.? Is there really a reproducible behaiviour difference
as described in the original post on such a "non-landable" form?

regards

thomas

Man-wai
Mon Jan 08 20:03:05 CST 2007

> I have not seen that happen... We open a lot of forms where None of the
> controls are enabled unless an Edit is passed from the parent form. I would
> suggest you give it another look otherwise it may come back to bite you at a
> later time. The problem might be some place else

What about the buttons?

--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Man-wai
Mon Jan 08 20:04:11 CST 2007

> This could happen for sure if an explicit "dispatch loop" has been

I didn't code any loop in my form.

> coded. But I fail to see the connection to the use of m.xx variable
> versus .t. or .f.? Is there really a reproducible behaiviour difference
> as described in the original post on such a "non-landable" form?

I don't understand, too.

--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Olaf
Tue Jan 09 02:11:33 CST 2007

>> coded. But I fail to see the connection to the use of m.xx variable
>> versus .t. or .f.? Is there really a reproducible behaiviour difference
>> as described in the original post on such a "non-landable" form?
>
> I don't understand, too.

Well, you stated endless looping was depending on
if you used m.xx instead of simply the constants .t.
and .f.

Now finally the problem does not seem to be related
at all to your code, right?

All in all you mislead us quite a bit, not intentionally.

Bye, Olaf.

Man-wai
Tue Jan 09 03:00:49 CST 2007

> Well, you stated endless looping was depending on
> if you used m.xx instead of simply the constants .t.
> and .f.
>
> Now finally the problem does not seem to be related
> at all to your code, right?
>
> All in all you mislead us quite a bit, not intentionally.

NO. I didn't mislead anyone. Per my original question, the bug only
appeared when I set a control.enabled=m.xx. It didn't appear
when I set control.enabled directly to .t. or .f..

It's after I posted the question did I found why FOxpro looped
itself because of no focusable control.

Now that I reported the solution, why don't you try to force Foxpro
into a loop as well? The loop is not related to my codes.


--
iTech Consulting Co., Ltd.
Specialized in providing ePOS solutions
Website: http://www.itech.com.hk (IE only)
Tel: (852) 2325 3883 Fax: (852)2325 8288

Imaginecorp
Sat Jan 13 08:03:56 CST 2007

No buttons on the child forms.
The parent form sends a parameter to enable or disable the child form
controls based upon if its is in Edit, Add etc. The parent form then either
saves the Info or reverts based upon User choice.
The child form shares the parent DataSessionID and is always Default Data
session with its tables in the parent's DE.
Like I said earlier.. The problem lies elsewhere...
--
Mohammed
www.imaginecorp.com/what_we_do.htm

"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:uxXAIJ5MHHA.1280@TK2MSFTNGP04.phx.gbl...
>> I have not seen that happen... We open a lot of forms where None of the
>> controls are enabled unless an Edit is passed from the parent form. I
>> would suggest you give it another look otherwise it may come back to bite
>> you at a later time. The problem might be some place else
>
> What about the buttons?
>
> --
> iTech Consulting Co., Ltd.
> Specialized in providing ePOS solutions
> Website: http://www.itech.com.hk (IE only)
> Tel: (852) 2325 3883 Fax: (852)2325 8288