Editbox lost focus issue

I can't reproduce the following 100% of the time, but it seems to me that if
I exit an editbox in one of my forms by clicking on a listbox (and/or
perhaps elsewhere) on the same form, the underlying tables are not always
updated properly. The update is accomplished via sql statements in the
lostfocus() event of the control. There is no controlsource and the fields
in question are character memo fields. The lb does drive the table that
stores the data, but I can verify that this is not a case of the data being
written to the wrong record. One obvious question is: Is there any way to
exit an eb control that won't fire the lostfocus() event?
TIA.
-Lew

Gene
Thu Oct 19 14:45:46 CDT 2006

"Lew Schwartz" <lschwartz@sionline.com> wrote:

>I can't reproduce the following 100% of the time, but it seems to me that if
>I exit an editbox in one of my forms by clicking on a listbox (and/or
>perhaps elsewhere) on the same form, the underlying tables are not always
>updated properly. The update is accomplished via sql statements in the
>lostfocus() event of the control. There is no controlsource and the fields
>in question are character memo fields. The lb does drive the table that
>stores the data, but I can verify that this is not a case of the data being
>written to the wrong record. One obvious question is: Is there any way to
>exit an eb control that won't fire the lostfocus() event?
>TIA.

I am not sure what you are complaining about. Is it:

1) Sometimes, the underlying tables are not being updated, and they
should be.

2) Sometimes, the underlying tables are being updated, and they
should not be.

Clicking on a toolbar item will not cause a loss of focus. This
means that the updating will not happen. If the toolbar action causes
the data to be updated, it will not have the new value for the last
control that you were entering into. Is this what you are wondering
about?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Lew
Thu Oct 19 16:59:46 CDT 2006

It's #1 Gene, thanks. There are no toolbars around, just other controls on
an otherwise plain vanilla form.

"Gene Wirchenko" <genew@ocis.net> wrote in message
news:o7lfj25dvhe58ango6jbb7mqadu2rb61bd@4ax.com...
> "Lew Schwartz" <lschwartz@sionline.com> wrote:
>
>>I can't reproduce the following 100% of the time, but it seems to me that
>>if
>>I exit an editbox in one of my forms by clicking on a listbox (and/or
>>perhaps elsewhere) on the same form, the underlying tables are not always
>>updated properly. The update is accomplished via sql statements in the
>>lostfocus() event of the control. There is no controlsource and the fields
>>in question are character memo fields. The lb does drive the table that
>>stores the data, but I can verify that this is not a case of the data
>>being
>>written to the wrong record. One obvious question is: Is there any way to
>>exit an eb control that won't fire the lostfocus() event?
>>TIA.
>
> I am not sure what you are complaining about. Is it:
>
> 1) Sometimes, the underlying tables are not being updated, and they
> should be.
>
> 2) Sometimes, the underlying tables are being updated, and they
> should not be.
>
> Clicking on a toolbar item will not cause a loss of focus. This
> means that the updating will not happen. If the toolbar action causes
> the data to be updated, it will not have the new value for the last
> control that you were entering into. Is this what you are wondering
> about?
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.

Gene
Thu Oct 19 18:07:18 CDT 2006

[reordered to chronological]

"Lew Schwartz" <lschwartz@sionline.com> wrote:

>"Gene Wirchenko" <genew@ocis.net> wrote in message
>news:o7lfj25dvhe58ango6jbb7mqadu2rb61bd@4ax.com...
>> "Lew Schwartz" <lschwartz@sionline.com> wrote:
>>
>>>I can't reproduce the following 100% of the time, but it seems to me that
>>>if
>>>I exit an editbox in one of my forms by clicking on a listbox (and/or
>>>perhaps elsewhere) on the same form, the underlying tables are not always
>>>updated properly. The update is accomplished via sql statements in the
>>>lostfocus() event of the control. There is no controlsource and the fields
>>>in question are character memo fields. The lb does drive the table that
>>>stores the data, but I can verify that this is not a case of the data
>>>being
>>>written to the wrong record. One obvious question is: Is there any way to
>>>exit an eb control that won't fire the lostfocus() event?
>>>TIA.
>>
>> I am not sure what you are complaining about. Is it:
>>
>> 1) Sometimes, the underlying tables are not being updated, and they
>> should be.
>>
>> 2) Sometimes, the underlying tables are being updated, and they
>> should not be.
>>
>> Clicking on a toolbar item will not cause a loss of focus. This
>> means that the updating will not happen. If the toolbar action causes
>> the data to be updated, it will not have the new value for the last
>> control that you were entering into. Is this what you are wondering
>> about?

>It's #1 Gene, thanks. There are no toolbars around, just other controls on
>an otherwise plain vanilla form.

What you are describing is the problem when a toolbar comes into
the picture. Clicking on a toolbar button does not result in a loss
of focus for the form, becauase the toolbar does not get focus. This
is a deliberate design, but it causes the problem you state.

If this is actually your problem, you need something to force a
focus loss when a toolbar button is clicked (or whatever it is that is
getting worked on without getting the focus). (I first wrote
"activiated", but that is something else.)

What I did in the toolbar was to create a form and display it
off-screen. That got the focus. More importantly, that means that
the data control loses the focus, and that loss triggers the
validation. I assume that this approach would also trigger your
.lostfocus() code.

I hope this helps, but I really do not have enough detail to be
sure. (Your claim of no toolbars is the puzzling bit. I do not know
what else can become active without getting the focus besides a
toolbar. Does anyone else know?)

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Dan
Thu Oct 19 18:17:46 CDT 2006

Gene Wirchenko wrote:
> What you are describing is the problem when a toolbar comes into
> the picture. Clicking on a toolbar button does not result in a loss
> of focus for the form, becauase the toolbar does not get focus. This
> is a deliberate design, but it causes the problem you state.
>
> If this is actually your problem, you need something to force a
> focus loss when a toolbar button is clicked (or whatever it is that is
> getting worked on without getting the focus). (I first wrote
> "activiated", but that is something else.)
>
> What I did in the toolbar was to create a form and display it
> off-screen. That got the focus. More importantly, that means that
> the data control loses the focus, and that loss triggers the
> validation. I assume that this approach would also trigger your
> .lostfocus() code.
>
> I hope this helps, but I really do not have enough detail to be
> sure. (Your claim of no toolbars is the puzzling bit. I do not know
> what else can become active without getting the focus besides a
> toolbar. Does anyone else know?)

Creating a form seems like overkill. Generally, from the toolbar all you
need to do is call .Setfocus() on the control you're leaving. That forces a
Lostfocus/Valid evaluation. (_Screen.Activeform.Currentcontrol.Setfocus() is
what most people use, except with grids which require a little more care.)

These symptoms do sound like the same problem, but without a toolbar in the
mix something isn't kosher.

Dan

Gene
Thu Oct 19 19:22:41 CDT 2006

"Dan Freeman" <spam@microsoft.com> wrote:

[snip]

>Creating a form seems like overkill. Generally, from the toolbar all you

It works and is well-defined.

>need to do is call .Setfocus() on the control you're leaving. That forces a

Where is that documented (by Microsoft)? I do not like trusting
to undocumented behaviour.

>Lostfocus/Valid evaluation. (_Screen.Activeform.Currentcontrol.Setfocus() is
>what most people use, except with grids which require a little more care.)
>
>These symptoms do sound like the same problem, but without a toolbar in the
>mix something isn't kosher.

Exactly my concern. I do so like it when my answers are correct.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Josh
Thu Oct 19 20:09:21 CDT 2006

> What you are describing is the problem when a toolbar comes into

"there are no toolbars around"



--- AntiSpam/harvest ---
Remove X's to send email to me.

Gene
Thu Oct 19 21:05:28 CDT 2006

Josh Assing <XjoshX@jassing.com> wrote:

>> What you are describing is the problem when a toolbar comes into
>
>"there are no toolbars around"

...that he knows of.

The question comes down to which values are not updated. If it
is always the last control whose value was changed, it suggests that
whatever happens after that is either a toolbar doing something or
something else that behaves like one.

It need not always happen. If the last value changed is not the
current control, the .valid, .lostfocus, and a bunch of other events
will have fired and their methods will have been executed. If the
last value is the current control when whatever-it-is occurs, then the
update will not happen.

We will have to see what Mr. Schwartz says about this.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Josh
Thu Oct 19 21:13:52 CDT 2006


> ...that he knows of.

Gene - if we can't take what the person says as "fact" (in the absence of
overwhelming proof), then we can take it all as untruths.

So that route -- There is a toolbar, there's also no code in the lostfocus
event; thus nothing is updated.

;-)


--- AntiSpam/harvest ---
Remove X's to send email to me.

Gene
Thu Oct 19 23:01:16 CDT 2006

Josh Assing <XjoshX@jassing.com> wrote:

>> ...that he knows of.
>
>Gene - if we can't take what the person says as "fact" (in the absence of
>overwhelming proof), then we can take it all as untruths.

Have you ever done technical support? Just a little?

I have, and have run into the problem of what, in fiction, is
called the unreliable narrator.

Mr. Schwartz may be describing something to the best of his
ability and still be wrong in his description. The best explanation
that I have right now is that there is a toolbar there somewhere or
something that behaves in the same way.

No, I do not need overwhelming proof to go this way. I just need
reasonable doubt. I believe I have that now. If I am mistaken, then
I will be learning something. I have no problem with that.

>So that route -- There is a toolbar, there's also no code in the lostfocus
>event; thus nothing is updated.
>
>;-)

You put a smiley, but it is a serious point. He should check the
.lostfocus for each and make sure the code is there and that it gets
executed.

The most important part of troubleshooting is replication of the
problem. That includes verifying the data that is given if there is
any reasonable doubt as to its accuracy.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Lew
Fri Oct 20 08:28:06 CDT 2006

Well, here's what I say.
The control in question (for now) is an editbox with no .controlsource.
A table and a child cursor are involved in the update. The table stores
parent/child data so the typical data environment (not the vfp de) is: the
table is open plus any number of child, readwrite/nofilter cursors, and the
underlying field type is memo. The code in the lostfocus of the eb contains
2 sql update statements, one for the table and a second for the cursor, all
attached by a single pk. I have verified that the data is being written to
the correct records in both table and cursor.
This morning, I'll experiment with using a .controlsource and removing
the sql update on the child cursor.
-Lew

Josh
Fri Oct 20 09:49:41 CDT 2006

Can you post/send me a sample and steps to repro it.

On Fri, 20 Oct 2006 09:28:06 -0400, "Lew Schwartz" <lschwartz@sionline.com>
wrote:

> Well, here's what I say.
> The control in question (for now) is an editbox with no .controlsource.
>A table and a child cursor are involved in the update. The table stores
>parent/child data so the typical data environment (not the vfp de) is: the
>table is open plus any number of child, readwrite/nofilter cursors, and the
>underlying field type is memo. The code in the lostfocus of the eb contains
>2 sql update statements, one for the table and a second for the cursor, all
>attached by a single pk. I have verified that the data is being written to
>the correct records in both table and cursor.
> This morning, I'll experiment with using a .controlsource and removing
>the sql update on the child cursor.
>-Lew
>


--- AntiSpam/harvest ---
Remove X's to send email to me.

imaginecorp
Fri Oct 20 10:22:01 CDT 2006

Hello Lew;
Seems like you are lost between the others {LOL}
First I would use the controlsource for the EditBox. If that is not
feasable, I would paste the update code NOT in LostFocus But in The Valid
event of the EditBox in a wrapper.
IF NOT EMPTY(THIS.VALUE)
**** your update Code
ENDIF
This way you want the code to run only if there is something in the Edit Box
and not everytime the user "Visits" the edit box. You could if you like
further check if the Value has changed with
IF NOT EMPTY(THIS.VALUE) AND OLDVAL(<<fieldname>>,<<tablename>>) # THIS.VALUE
**** your update Code
ENDIF
The valid event will definately update the Table as long as you are doing an
Tableupdate()
Good Luck
Mohammed
www.imaginecorp.com/whatwedo.htm



"Lew Schwartz" wrote:

> I can't reproduce the following 100% of the time, but it seems to me that if
> I exit an editbox in one of my forms by clicking on a listbox (and/or
> perhaps elsewhere) on the same form, the underlying tables are not always
> updated properly. The update is accomplished via sql statements in the
> lostfocus() event of the control. There is no controlsource and the fields
> in question are character memo fields. The lb does drive the table that
> stores the data, but I can verify that this is not a case of the data being
> written to the wrong record. One obvious question is: Is there any way to
> exit an eb control that won't fire the lostfocus() event?
> TIA.
> -Lew
>
>
>

Lew
Fri Oct 20 10:46:35 CDT 2006

I decided some time ago not to use the valid because of some problem I found
with why and when if fires. Unfortunately, I don't remember it now.
"imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
news:C5963917-4DA1-4400-A141-098B9580A22B@microsoft.com...
> Hello Lew;
> Seems like you are lost between the others {LOL}
> First I would use the controlsource for the EditBox. If that is not
> feasable, I would paste the update code NOT in LostFocus But in The Valid
> event of the EditBox in a wrapper.
> IF NOT EMPTY(THIS.VALUE)
> **** your update Code
> ENDIF
> This way you want the code to run only if there is something in the Edit
> Box
> and not everytime the user "Visits" the edit box. You could if you like
> further check if the Value has changed with
> IF NOT EMPTY(THIS.VALUE) AND OLDVAL(<<fieldname>>,<<tablename>>) #
> THIS.VALUE
> **** your update Code
> ENDIF
> The valid event will definately update the Table as long as you are doing
> an
> Tableupdate()
> Good Luck
> Mohammed
> www.imaginecorp.com/whatwedo.htm
>
>
>
> "Lew Schwartz" wrote:
>
>> I can't reproduce the following 100% of the time, but it seems to me that
>> if
>> I exit an editbox in one of my forms by clicking on a listbox (and/or
>> perhaps elsewhere) on the same form, the underlying tables are not always
>> updated properly. The update is accomplished via sql statements in the
>> lostfocus() event of the control. There is no controlsource and the
>> fields
>> in question are character memo fields. The lb does drive the table that
>> stores the data, but I can verify that this is not a case of the data
>> being
>> written to the wrong record. One obvious question is: Is there any way to
>> exit an eb control that won't fire the lostfocus() event?
>> TIA.
>> -Lew
>>
>>
>>

Lew
Fri Oct 20 10:48:39 CDT 2006

Josh:
As I said in my first post, it's driving me nuts just because it's not
100% reproducible ( more on the order of 5%) and, no, it doesn't happen in
isolation either.

"Josh Assing" <XjoshX@jassing.com> wrote in message
news:vtnhj2hrt01m0hsb4e0mm0mmaik0hu6e8n@4ax.com...
> Can you post/send me a sample and steps to repro it.
>
> On Fri, 20 Oct 2006 09:28:06 -0400, "Lew Schwartz"
> <lschwartz@sionline.com>
> wrote:
>
>> Well, here's what I say.
>> The control in question (for now) is an editbox with no
>> .controlsource.
>>A table and a child cursor are involved in the update. The table stores
>>parent/child data so the typical data environment (not the vfp de) is: the
>>table is open plus any number of child, readwrite/nofilter cursors, and
>>the
>>underlying field type is memo. The code in the lostfocus of the eb
>>contains
>>2 sql update statements, one for the table and a second for the cursor,
>>all
>>attached by a single pk. I have verified that the data is being written to
>>the correct records in both table and cursor.
>> This morning, I'll experiment with using a .controlsource and removing
>>the sql update on the child cursor.
>>-Lew
>>
>
>
> --- AntiSpam/harvest ---
> Remove X's to send email to me.

Dan
Fri Oct 20 10:59:08 CDT 2006

I missed the part about the editbox being unbound. ISTR some flaky behavior
with unbound editboxes but it's a dim memory.

Dan

Lew Schwartz wrote:
> Well, here's what I say.
> The control in question (for now) is an editbox with no
> .controlsource. A table and a child cursor are involved in the
> update. The table stores parent/child data so the typical data
> environment (not the vfp de) is: the table is open plus any number of
> child, readwrite/nofilter cursors, and the underlying field type is
> memo. The code in the lostfocus of the eb contains 2 sql update
> statements, one for the table and a second for the cursor, all
> attached by a single pk. I have verified that the data is being
> written to the correct records in both table and cursor. This
> morning, I'll experiment with using a .controlsource and removing
> the sql update on the child cursor.
> -Lew

imaginecorp
Fri Oct 20 11:40:02 CDT 2006

Hello Lew:
Valid event is a PIA if you are trying to update another control or value to
be displayed when the form opens. Otherwise they are OK. If all you are
trying to do is update a table after an entry has been made or the value
changed, IMO Valids work best. As long as you have the code in a "wrapper"
like I posted.
I just do not trust LostFocus()
Good Luck
Mohammed
www.imaginecorp.com/whatwedo.htm


"Lew Schwartz" wrote:

> I decided some time ago not to use the valid because of some problem I found
> with why and when if fires. Unfortunately, I don't remember it now.
> "imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
> news:C5963917-4DA1-4400-A141-098B9580A22B@microsoft.com...
> > Hello Lew;
> > Seems like you are lost between the others {LOL}
> > First I would use the controlsource for the EditBox. If that is not
> > feasable, I would paste the update code NOT in LostFocus But in The Valid
> > event of the EditBox in a wrapper.
> > IF NOT EMPTY(THIS.VALUE)
> > **** your update Code
> > ENDIF
> > This way you want the code to run only if there is something in the Edit
> > Box
> > and not everytime the user "Visits" the edit box. You could if you like
> > further check if the Value has changed with
> > IF NOT EMPTY(THIS.VALUE) AND OLDVAL(<<fieldname>>,<<tablename>>) #
> > THIS.VALUE
> > **** your update Code
> > ENDIF
> > The valid event will definately update the Table as long as you are doing
> > an
> > Tableupdate()
> > Good Luck
> > Mohammed
> > www.imaginecorp.com/whatwedo.htm
> >
> >
> >
> > "Lew Schwartz" wrote:
> >
> >> I can't reproduce the following 100% of the time, but it seems to me that
> >> if
> >> I exit an editbox in one of my forms by clicking on a listbox (and/or
> >> perhaps elsewhere) on the same form, the underlying tables are not always
> >> updated properly. The update is accomplished via sql statements in the
> >> lostfocus() event of the control. There is no controlsource and the
> >> fields
> >> in question are character memo fields. The lb does drive the table that
> >> stores the data, but I can verify that this is not a case of the data
> >> being
> >> written to the wrong record. One obvious question is: Is there any way to
> >> exit an eb control that won't fire the lostfocus() event?
> >> TIA.
> >> -Lew
> >>
> >>
> >>
>
>
>

Lew
Fri Oct 20 13:37:03 CDT 2006

I'm currently looking at the sql update statements. AFAIK, they
shouldn't be updating the record pointer even though I also understand that
they traverse entire tables as opposed to xBase replace which affects a
single record if used without modifiers. Anyway, I can see that the rec
pointer is definitely being updated by the sql statement. Possibly, the
wrong record is being updated and/or the content of a wrong record is being
displayed.
More later.
"Dan Freeman" <spam@microsoft.com> wrote in message
news:%231JMuCG9GHA.1492@TK2MSFTNGP02.phx.gbl...
>I missed the part about the editbox being unbound. ISTR some flaky behavior
> with unbound editboxes but it's a dim memory.
>
> Dan
>
> Lew Schwartz wrote:
>> Well, here's what I say.
>> The control in question (for now) is an editbox with no
>> .controlsource. A table and a child cursor are involved in the
>> update. The table stores parent/child data so the typical data
>> environment (not the vfp de) is: the table is open plus any number of
>> child, readwrite/nofilter cursors, and the underlying field type is
>> memo. The code in the lostfocus of the eb contains 2 sql update
>> statements, one for the table and a second for the cursor, all
>> attached by a single pk. I have verified that the data is being
>> written to the correct records in both table and cursor. This
>> morning, I'll experiment with using a .controlsource and removing
>> the sql update on the child cursor.
>> -Lew
>
>

Lew
Fri Oct 20 13:38:30 CDT 2006

Yes, but I *love* lostfocus. It reminds me of myself, my wife and life in
general.
"imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
news:67926C20-8B9D-4D11-B6A4-449EEF75BD9F@microsoft.com...
> Hello Lew:
> Valid event is a PIA if you are trying to update another control or value
> to
> be displayed when the form opens. Otherwise they are OK. If all you are
> trying to do is update a table after an entry has been made or the value
> changed, IMO Valids work best. As long as you have the code in a "wrapper"
> like I posted.
> I just do not trust LostFocus()
> Good Luck
> Mohammed
> www.imaginecorp.com/whatwedo.htm
>
>
> "Lew Schwartz" wrote:
>
>> I decided some time ago not to use the valid because of some problem I
>> found
>> with why and when if fires. Unfortunately, I don't remember it now.
>> "imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
>> news:C5963917-4DA1-4400-A141-098B9580A22B@microsoft.com...
>> > Hello Lew;
>> > Seems like you are lost between the others {LOL}
>> > First I would use the controlsource for the EditBox. If that is not
>> > feasable, I would paste the update code NOT in LostFocus But in The
>> > Valid
>> > event of the EditBox in a wrapper.
>> > IF NOT EMPTY(THIS.VALUE)
>> > **** your update Code
>> > ENDIF
>> > This way you want the code to run only if there is something in the
>> > Edit
>> > Box
>> > and not everytime the user "Visits" the edit box. You could if you like
>> > further check if the Value has changed with
>> > IF NOT EMPTY(THIS.VALUE) AND OLDVAL(<<fieldname>>,<<tablename>>) #
>> > THIS.VALUE
>> > **** your update Code
>> > ENDIF
>> > The valid event will definately update the Table as long as you are
>> > doing
>> > an
>> > Tableupdate()
>> > Good Luck
>> > Mohammed
>> > www.imaginecorp.com/whatwedo.htm
>> >
>> >
>> >
>> > "Lew Schwartz" wrote:
>> >
>> >> I can't reproduce the following 100% of the time, but it seems to me
>> >> that
>> >> if
>> >> I exit an editbox in one of my forms by clicking on a listbox (and/or
>> >> perhaps elsewhere) on the same form, the underlying tables are not
>> >> always
>> >> updated properly. The update is accomplished via sql statements in the
>> >> lostfocus() event of the control. There is no controlsource and the
>> >> fields
>> >> in question are character memo fields. The lb does drive the table
>> >> that
>> >> stores the data, but I can verify that this is not a case of the data
>> >> being
>> >> written to the wrong record. One obvious question is: Is there any way
>> >> to
>> >> exit an eb control that won't fire the lostfocus() event?
>> >> TIA.
>> >> -Lew
>> >>
>> >>
>> >>
>>
>>
>>

Gene
Fri Oct 20 23:40:08 CDT 2006

"Lew Schwartz" <lschwartz@sionline.com> wrote:

> I'm currently looking at the sql update statements. AFAIK, they
>shouldn't be updating the record pointer even though I also understand that

This may be your error. I believe that the effect is actually
undefined. SQL, after all, does not have the concept of a record
pointer.

You might try saving the record pointer on all tables that the
SQL touches before executing the SQL, and then restore the pointers
afterward. This might have nothing to do with your problem though.

>they traverse entire tables as opposed to xBase replace which affects a
>single record if used without modifiers. Anyway, I can see that the rec

Or none at all in some cases involving eof() on a table.

>pointer is definitely being updated by the sql statement. Possibly, the
>wrong record is being updated and/or the content of a wrong record is being
>displayed.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene
Fri Oct 20 23:41:31 CDT 2006

imaginecorp <imaginecorp@discussions.microsoft.com> wrote:

>Hello Lew:
>Valid event is a PIA if you are trying to update another control or value to
>be displayed when the form opens. Otherwise they are OK. If all you are
>trying to do is update a table after an entry has been made or the value
>changed, IMO Valids work best. As long as you have the code in a "wrapper"
>like I posted.
>I just do not trust LostFocus()

Some controls do not have .valid, but they probably all have
.lostfocus.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Lew
Sat Oct 21 06:12:01 CDT 2006

Undefined by SQL yes, but in the VFP implementation, the pointer plainly
moves. Mix 'n Match xBase & SQL may be the problem. I thought about saving &
restoring the pointer, but I decided that, if I had to use xBase concepts,
then I might as well replace the xBase/SQL/xBase commands with a single
replace. Seems to be working so far, but it's still too soon to be
confident.

"Gene Wirchenko" <genew@ocis.net> wrote in message
news:dv8jj218eidmvem9bhqkdi7q8ibh5ofm08@4ax.com...
> "Lew Schwartz" <lschwartz@sionline.com> wrote:
>
>> . I believe that the effect is actually
> undefined. SQL, after all, does not have the concept of a record
> pointer.
>
>

Lew
Sat Oct 21 06:21:47 CDT 2006

Yes, I seem to remember that. The problem is compounded when the valid code
comes to require a revision as your program specs evolve. The valid becomes
a dead end. As far as detecting whether or not a control has been updated, I
implement that in a parent class so all my tb's inherit the ability out of
the box. I don't see any reason not to trust lostfocus(), however.
"imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
news:67926C20-8B9D-4D11-B6A4-449EEF75BD9F@microsoft.com...
> Hello Lew:
> Valid event is a PIA if you are trying to update another control or value
> to
> be displayed when the form opens. Otherwise they are OK. If all you are
> trying to do is update a table after an entry has been made or the value
> changed, IMO Valids work best. As long as you have the code in a "wrapper"
> like I posted.
> I just do not trust LostFocus()
> Good Luck
> Mohammed
> www.imaginecorp.com/whatwedo.htm
>
>
> "Lew Schwartz" wrote:
>
>> I decided some time ago not to use the valid because of some problem I
>> found
>> with why and when if fires. Unfortunately, I don't remember it now.
>> "imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
>> news:C5963917-4DA1-4400-A141-098B9580A22B@microsoft.com...
>> > Hello Lew;
>> > Seems like you are lost between the others {LOL}
>> > First I would use the controlsource for the EditBox. If that is not
>> > feasable, I would paste the update code NOT in LostFocus But in The
>> > Valid
>> > event of the EditBox in a wrapper.
>> > IF NOT EMPTY(THIS.VALUE)
>> > **** your update Code
>> > ENDIF
>> > This way you want the code to run only if there is something in the
>> > Edit
>> > Box
>> > and not everytime the user "Visits" the edit box. You could if you like
>> > further check if the Value has changed with
>> > IF NOT EMPTY(THIS.VALUE) AND OLDVAL(<<fieldname>>,<<tablename>>) #
>> > THIS.VALUE
>> > **** your update Code
>> > ENDIF
>> > The valid event will definately update the Table as long as you are
>> > doing
>> > an
>> > Tableupdate()
>> > Good Luck
>> > Mohammed
>> > www.imaginecorp.com/whatwedo.htm
>> >
>> >
>> >
>> > "Lew Schwartz" wrote:
>> >
>> >> I can't reproduce the following 100% of the time, but it seems to me
>> >> that
>> >> if
>> >> I exit an editbox in one of my forms by clicking on a listbox (and/or
>> >> perhaps elsewhere) on the same form, the underlying tables are not
>> >> always
>> >> updated properly. The update is accomplished via sql statements in the
>> >> lostfocus() event of the control. There is no controlsource and the
>> >> fields
>> >> in question are character memo fields. The lb does drive the table
>> >> that
>> >> stores the data, but I can verify that this is not a case of the data
>> >> being
>> >> written to the wrong record. One obvious question is: Is there any way
>> >> to
>> >> exit an eb control that won't fire the lostfocus() event?
>> >> TIA.
>> >> -Lew
>> >>
>> >>
>> >>
>>
>>
>>

Gene
Sat Oct 21 14:38:34 CDT 2006

[reordered to chronological]

"Lew" <lew@fastmail.fm> wrote:

>"Gene Wirchenko" <genew@ocis.net> wrote in message
>news:dv8jj218eidmvem9bhqkdi7q8ibh5ofm08@4ax.com...

>>> . I believe that the effect is actually
>> undefined. SQL, after all, does not have the concept of a record
>> pointer.

>Undefined by SQL yes, but in the VFP implementation, the pointer plainly
>moves. Mix 'n Match xBase & SQL may be the problem. I thought about saving &

So what? "undefined" means that anything could happen: the
pointer could always move, never move, or sometimes move. It might be
something that you want or expect, but it is not something you can
count on.

>restoring the pointer, but I decided that, if I had to use xBase concepts,
>then I might as well replace the xBase/SQL/xBase commands with a single
>replace. Seems to be working so far, but it's still too soon to be
>confident.

Another possibility that just came to mind is that you are not
using buffering modes or tableupdate() correctly.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Lew
Sat Oct 21 16:11:48 CDT 2006

...not using buffering at all.
"Gene Wirchenko" <genew@ocis.net> wrote in message
news:fktkj2lbkj755sviav9uo9ma1mt4oci9ho@4ax.com...
> [reordered to chronological]
>
> "Lew" <lew@fastmail.fm> wrote:
>
>>"Gene Wirchenko" <genew@ocis.net> wrote in message
>>news:dv8jj218eidmvem9bhqkdi7q8ibh5ofm08@4ax.com...
>
>>>> . I believe that the effect is actually
>>> undefined. SQL, after all, does not have the concept of a record
>>> pointer.
>
>>Undefined by SQL yes, but in the VFP implementation, the pointer plainly
>>moves. Mix 'n Match xBase & SQL may be the problem. I thought about saving
>>&
>
> So what? "undefined" means that anything could happen: the
> pointer could always move, never move, or sometimes move. It might be
> something that you want or expect, but it is not something you can
> count on.
>
>>restoring the pointer, but I decided that, if I had to use xBase concepts,
>>then I might as well replace the xBase/SQL/xBase commands with a single
>>replace. Seems to be working so far, but it's still too soon to be
>>confident.
>
> Another possibility that just came to mind is that you are not
> using buffering modes or tableupdate() correctly.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.

imaginecorp
Mon Oct 23 11:26:01 CDT 2006

Whatever gets the job done... Hundreds of ways to skin a cat...Though I am
sure the cat will not appreciate any of them...
Mohammed
www.imaginecorp.com/whatwedo.htm


"Lew" wrote:

> Yes, I seem to remember that. The problem is compounded when the valid code
> comes to require a revision as your program specs evolve. The valid becomes
> a dead end. As far as detecting whether or not a control has been updated, I
> implement that in a parent class so all my tb's inherit the ability out of
> the box. I don't see any reason not to trust lostfocus(), however.
> "imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
> news:67926C20-8B9D-4D11-B6A4-449EEF75BD9F@microsoft.com...
> > Hello Lew:
> > Valid event is a PIA if you are trying to update another control or value
> > to
> > be displayed when the form opens. Otherwise they are OK. If all you are
> > trying to do is update a table after an entry has been made or the value
> > changed, IMO Valids work best. As long as you have the code in a "wrapper"
> > like I posted.
> > I just do not trust LostFocus()
> > Good Luck
> > Mohammed
> > www.imaginecorp.com/whatwedo.htm
> >
> >
> > "Lew Schwartz" wrote:
> >
> >> I decided some time ago not to use the valid because of some problem I
> >> found
> >> with why and when if fires. Unfortunately, I don't remember it now.
> >> "imaginecorp" <imaginecorp@discussions.microsoft.com> wrote in message
> >> news:C5963917-4DA1-4400-A141-098B9580A22B@microsoft.com...
> >> > Hello Lew;
> >> > Seems like you are lost between the others {LOL}
> >> > First I would use the controlsource for the EditBox. If that is not
> >> > feasable, I would paste the update code NOT in LostFocus But in The
> >> > Valid
> >> > event of the EditBox in a wrapper.
> >> > IF NOT EMPTY(THIS.VALUE)
> >> > **** your update Code
> >> > ENDIF
> >> > This way you want the code to run only if there is something in the
> >> > Edit
> >> > Box
> >> > and not everytime the user "Visits" the edit box. You could if you like
> >> > further check if the Value has changed with
> >> > IF NOT EMPTY(THIS.VALUE) AND OLDVAL(<<fieldname>>,<<tablename>>) #
> >> > THIS.VALUE
> >> > **** your update Code
> >> > ENDIF
> >> > The valid event will definately update the Table as long as you are
> >> > doing
> >> > an
> >> > Tableupdate()
> >> > Good Luck
> >> > Mohammed
> >> > www.imaginecorp.com/whatwedo.htm
> >> >
> >> >
> >> >
> >> > "Lew Schwartz" wrote:
> >> >
> >> >> I can't reproduce the following 100% of the time, but it seems to me
> >> >> that
> >> >> if
> >> >> I exit an editbox in one of my forms by clicking on a listbox (and/or
> >> >> perhaps elsewhere) on the same form, the underlying tables are not
> >> >> always
> >> >> updated properly. The update is accomplished via sql statements in the
> >> >> lostfocus() event of the control. There is no controlsource and the
> >> >> fields
> >> >> in question are character memo fields. The lb does drive the table
> >> >> that
> >> >> stores the data, but I can verify that this is not a case of the data
> >> >> being
> >> >> written to the wrong record. One obvious question is: Is there any way
> >> >> to
> >> >> exit an eb control that won't fire the lostfocus() event?
> >> >> TIA.
> >> >> -Lew
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>