[surve] what if...

The object of a form would not lost focus when a form opens on top of
it? Would it make everyone's life easier?

--
.~. 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
^ ^ 17:02:01 up 24 days 23:14 0 users load average: 1.03 1.06 1.01
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Dan
Sat Jan 06 03:42:54 CST 2007

Actually, no. It would not make anyone's life easier.

However, you might want to fiddle with the AlwaysOnTop property. It might
give you some of what you want. And, of course, if you really want controls
that don't fiddle with focus you can put them in a toolbar.

Dan

Man-wai Chang wrote:
> The object of a form would not lost focus when a form opens on top of
> it? Would it make everyone's life easier?

Olaf
Sat Jan 06 06:28:16 CST 2007

Hi,

if you wat multiple forms to be active and each
having one control at it's focus, you could
compile many exes, letting each form run as
it's own process.

Can it be, you have burdend yourself with
problems by having valid events, that don't
allow focus lost? Should only use such things
in modal forms and/or use a more central
point for validation in a form, eg in QueryUnload(),
then lost focus through a new form is no
problem.

Bye, Olaf.

Olaf
Sat Jan 06 06:33:16 CST 2007

Hi again,

you're lately having a lot of problems, which
may arise from a bad design of your framework.

You should look for some best practices and
partly solutions/components usable for your
framework.

book recommendations:
http://www.hentzenwerke.com/catalog/vfpbp10.htm
http://www.hentzenwerke.com/catalog/buildfox.htm

Bye, Olaf.

Man-wai
Sat Jan 06 07:43:57 CST 2007

> you're lately having a lot of problems, which
> may arise from a bad design of your framework.

1. Why bothered? Foxpro is going to disappear, right?
Everything is done to eradicate xBase developers, isn't it?
2. It's fun and challenging to start from scratch.
3. Different programmer has different perspective and ways
of doings. Advertised framework may not fit your mentality.
We are not clones for each other. :")
I am a cantonese, you are a "american"(?).


--
.~. 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:41:01 up 25 days 3:53 0 users load average: 1.04 1.02 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Sat Jan 06 07:45:45 CST 2007

> However, you might want to fiddle with the AlwaysOnTop property. It might
> give you some of what you want. And, of course, if you really want controls
> that don't fiddle with focus you can put them in a toolbar.

I meant every form has its own focus. Even if the newly opened
form is modal, it would not take away the focus from the caller
form. It's not about always on top. It's not about having only
one focus always.

Back in the days of DEFINE WINODWS and @...SAY..GET,
there is no focus "stealing" when a WINDOW pops opened
on top of an existing window.


--
.~. 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:43:01 up 25 days 3:55 0 users load average: 1.00 1.01 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Sat Jan 06 07:46:44 CST 2007

I was thinking about "survey", and I typed "surf"...ooops... "surve". :)
MY brain is not following my will... argh... ARGH .....

--
.~. 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:45:01 up 25 days 3:57 0 users load average: 1.00 1.00 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Bernhard
Sat Jan 06 08:13:57 CST 2007

Hi Man-wai Chang,

maybe if you do not

newform.show

but

newform.visible=.T.

the focus will stay in the oldform.

IIRC form.show implies an activation of the form and sets focus to the form,
while only setting form.visible=.T. does not.

Regards
Bernhard Sander

Al
Sat Jan 06 08:27:45 CST 2007

I agree with you !
IMHO, if a new form is opened (say in response to user needing some info and
opening form B while editing form A), there is no reason to have anything
fire in form A (other than possibly form.deactivate).

Imagine sitting on a field that has immediate validation, either from valid
or lost focus, or any range check, or ... (there are many good reasons for
some immediate validation) and the user has not yet input anything (or
something invalid such as an invalid date!) and needs to open another form
(event driven <g>)

al


"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:%23HfZ6GXMHHA.536@TK2MSFTNGP02.phx.gbl...
>
> The object of a form would not lost focus when a form opens on top of
> it? Would it make everyone's life easier?
>
> --
> .~. 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
> ^ ^ 17:02:01 up 24 days 23:14 0 users load average: 1.03 1.06 1.01
> news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Man-wai
Sat Jan 06 08:42:48 CST 2007

> Imagine sitting on a field that has immediate validation, either from valid
> or lost focus, or any range check, or ... (there are many good reasons for
> some immediate validation) and the user has not yet input anything (or
> something invalid such as an invalid date!) and needs to open another form
> (event driven <g>)

The biggest problem of having only one focus is when you have
a form that needs to accept both speedy keyboard and mouse input.
The when(), valid(), keypress() and lostfocus() stuffs made everything
a mess.

--
.~. 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:40:01 up 25 days 4:52 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 09:06:19 CST 2007

>> you're lately having a lot of problems, which
>> may arise from a bad design of your framework.
>
> 1. Why bothered? Foxpro is going to disappear, right?
> Everything is done to eradicate xBase developers, isn't it?
then why do it at all?

> 2. It's fun and challenging to start from scratch.
Ah, I see.

> 3. Different programmer has different perspective and ways
> of doings. Advertised framework may not fit your mentality.
> We are not clones for each other. :")
> I am a cantonese, you are a "american"(?).

I'm german. Doesn't really matter.

1. best practices are about simple things, how to
do it best (you may question that and find a way
to do it even better, that's not the main point).
It's on how to avoid traps and hurdles or wrong
ways others already have taken. Mistakes and
problems being avoidable. Do's and Dont's.

2. The second book is about creating frameworks,
it may be working with an example framework and
that example framework could give you biased ideas
on what to do how and you might end up with a quite
similar framework, true. Still it's a good starting point.


I just saw a multitude of your problems and they
might be related. So why not pointing you to
some general advices?

Don't want to take them? Okay, I don't force you.

Bye, Olaf.

Imaginecorp
Sat Jan 06 09:12:58 CST 2007

Hello Man-wai-chang;
I am not following your train of thought. What you are saying can very
easily be done... Except Modal forms as they are meant for input, not
information. If you are in a field and want to open a form for Information
purposes, just send the Field to the child form and have the child form set
the Focus back to the field...Though this will not work with a Valid...Maybe
it will work if you call the new form and then return a .F....interesting
must try it.
--
Mohammed
www.imaginecorp.com/what_we_do.htm

"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:%23HfZ6GXMHHA.536@TK2MSFTNGP02.phx.gbl...
>
> The object of a form would not lost focus when a form opens on top of
> it? Would it make everyone's life easier?
>
> --
> .~. 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
> ^ ^ 17:02:01 up 24 days 23:14 0 users load average: 1.03 1.06 1.01
> news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Olaf
Sat Jan 06 09:18:49 CST 2007

>I was thinking about "survey", and I typed "surf"...ooops... "surve". :)
> MY brain is not following my will... argh... ARGH .....

Don't worry, there are few persons/things
following your will...or mine.

You didn't by chance meant suggestion?

Bye, Olaf.

Olaf
Sat Jan 06 10:06:49 CST 2007


> (there are many good reasons for some immediate validation)

No, there is only one reason: To work on unbuffered
tables.

And that is only acceptable in few situations, eg. for
a form/table which only one adminstrator works with
and you can expect null conflicts.

I'm open for other suggestions or examples, but It's
a best practice to centralize validation and make it
right before tableupdate() end transaction or
equivalent actions.

By the way if you reactivate FormA (eg. when returning
from FormB), the same control will get back focus, that
had focus before, if you don't influence this in the
Activate() event.

Bye, Olaf.

swdev2
Sat Jan 06 10:46:39 CST 2007

There's a difference between 'lost focus' and 'being in scope'

I solved the 'out of scope' problem ages past by making the form name a
public variable before the form was instantiated, then if I needed to call
some method in THAT form , already loaded , from ANOTHER form, then I had a
public reference to it and could reference it directly.

It's bad form, btw, from an OOP standpoint. But it works.

What are you trying to accomplish?
ps - if you are Cantonese, why are you in Hong Kong? Hong Kong people have
a different name other than 'Cantonese' . and - IN Hong Kong, Cantonese is
viewed more as a dialect / language than anything else, right?
--
===================
William Sanders / EFG VFP / mySql / MS-SQL
www.efgroup.net/vfpwebhosting
www.terrafox.net www.viasqlserver.net

"Man-wai Chang" <toylet.toylet@gmail.com> wrote in message
news:#HfZ6GXMHHA.536@TK2MSFTNGP02.phx.gbl...
>
> The object of a form would not lost focus when a form opens on top of
> it? Would it make everyone's life easier?
>
> --
> .~. 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
> ^ ^ 17:02:01 up 24 days 23:14 0 users load average: 1.03 1.06 1.01
> news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Al
Sat Jan 06 11:08:14 CST 2007

IMHO, for desktop applications, it is much more productive and user friendly
to give immediate feedback to user than to wait for "form validate".
Immediate feedback is not just for invalid entries. In some cases an entry
may be valid but so unusual that you want to give a info alert. This is not
to say that form validate is not usefull, it is, and even necessary.

just because most web browser apps currently work as "form validate" does
not make it desirable (witness AJAX and other client side methods that are
not just for responsiveness)

do you want to go back to having to correct a forms fields one at a time
after form validate ?, and what if other fields depend on a field that now
makes other fields incorrrect ?

this is also true of non-database application; would you want spell checking
at end of document only ?

al
BTW, who decides "best practice", is there a "best practice" god I am
unaware of ?


"Olaf Doschke" <b2xhZi5kb3NjaGtlQHNldG1pY3MuZGU.strconv.14@t-online.de>
wrote in message news:enohel$502$01$1@news.t-online.com...
>
>> (there are many good reasons for some immediate validation)
>
> No, there is only one reason: To work on unbuffered
> tables.
>
> And that is only acceptable in few situations, eg. for
> a form/table which only one adminstrator works with and you can expect
> null conflicts.
>
> I'm open for other suggestions or examples, but It's
> a best practice to centralize validation and make it
> right before tableupdate() end transaction or
> equivalent actions.
>
> By the way if you reactivate FormA (eg. when returning
> from FormB), the same control will get back focus, that
> had focus before, if you don't influence this in the
> Activate() event.
>
> Bye, Olaf.

Olaf
Sat Jan 06 12:40:00 CST 2007

> and what if other fields depend on a field that now
> makes other fields incorrrect ?
that is a good example of why to not make a validation
at field level. Interdependencies can cause problems
for field validations.

recently ther was some longwind thread on this, don't
remember if on UT or Tek-Tips or even here.

Quintessence: make form level validation, call
the form level validation function at field level
to give a warning, but still always return .T. in
the valid event. As the essence is preventing false
data in the tables, not in the form. Give the user a
chance to rightyfy the entered data.

Concerning your example of spell checking: If
validation is complex, give the user that function
in the toolbar or a form button, why not? It's not
important to limit the validation to close before
saving/updating data, sorry if I made that impression.
'But it's important to let the user enter the data the
way he wants it, skipping optional controls, whatever.
If you want to control the order in which data is entered,
make it several forms called in a row or enable controls
in stages after sufficient data was entered.

> BTW, who decides "best practice", is there a
> "best practice" god I am unaware of ?

I already said in another post nearby, that "best
practice" shouldn't be taken literally.

But there are known good ways to cope with the
problems Man-Wai Chang has now, he's not the
first one going through all this. It's more stupid to
start fom scratch and claim "I'll do it better all the
way than anyone else did", than to take these
best practices into account. At least have a look,
it might be what you/he searched for.

If you want to invent a new ice cream recipe,
do you start from scratch, or wouldn't you first
take a look at some recipes that are successful,
tasting good (to you)? Yes, you can only invent
a revolutionary ice cream, if you put something
new and unusual in it. But then again it should be
cold and creamy to be ice cream, shouldn't it?
And you surely don't want to reinvent the freezer,
do you?

Bye, Olaf.

Dan
Sat Jan 06 16:11:43 CST 2007

What a horrible idea! Focus is difficult enough to manage when there's only
one of 'em.

Dan

Man-wai Chang wrote:
>> However, you might want to fiddle with the AlwaysOnTop property. It
>> might give you some of what you want. And, of course, if you really
>> want controls that don't fiddle with focus you can put them in a
>> toolbar.
>
> I meant every form has its own focus. Even if the newly opened
> form is modal, it would not take away the focus from the caller
> form. It's not about always on top. It's not about having only
> one focus always.
>
> Back in the days of DEFINE WINODWS and @...SAY..GET,
> there is no focus "stealing" when a WINDOW pops opened
> on top of an existing window.

Man-wai
Sun Jan 07 20:12:52 CST 2007

> Quintessence: make form level validation, call
> the form level validation function at field level
> to give a warning, but still always return .T. in
> the valid event. As the essence is preventing false
> data in the tables, not in the form. Give the user a
> chance to rightyfy the entered data.

The typical practise is to stop/focus at the field that
fails validation. If you always returned .T. in each field,
then you could not keep the focus.

--
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:20:54 CST 2007

> The typical practise is to stop/focus at the field that
> fails validation. If you always returned .T. in each field,
> then you could not keep the focus.

That is intended in the strategy I laid out.

I'd set the focus to an invalid value/control
when the user clicks save or exit and there
is something invalid.


Imagine this situation:
A record needs two dates in cronological order.
user enters

date1 08.01.08 (typo, user wanted 08.01.07)
date2 01.04.07

Now your kind of validation would force the user to
enter a date2, which is after date1, to be able to set
focus to something else. But in fact the error is NOT
in date2, but in date1!

In this situation the user can of course enter 01.04.08
as date2, then go back to date1 change that to 2007,
then go back to date2 and change that to 2007 too again.

But with my strategy the user can move around freely and
just change date1 to the correct value, done.

Much easier, no annoyance, no forcing to enter something
invalid temporarily to then be able to correct the overall
error.

Does that now make sense to you?

First let the user finish it's entries, then muck about errors.

Bye, Olaf.

Man-wai
Mon Jan 08 06:52:58 CST 2007

> In this situation the user can of course enter 01.04.08
> as date2, then go back to date1 change that to 2007,
> then go back to date2 and change that to 2007 too again.
>
> But with my strategy the user can move around freely and
> just change date1 to the correct value, done.

Tell ya: this is not new. IBM mainframe block-mode terminal uses
this strategy. Unfortunately, not every bosses and/or usres like
delayed verification.

If I could shoot anyone, I would force every users/bosses to accept
form-level validation. ;)

--
.~. 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:51:01 up 27 days 3:03 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
Mon Jan 08 08:30:49 CST 2007

> Tell ya: this is not new. IBM mainframe block-mode terminal uses
> this strategy. Unfortunately, not every bosses and/or usres like
> delayed verification.

I have been playing with it for a few months: REXX + Panel. Have
forgotten all of them now.


--
.~. 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:29:01 up 27 days 4:41 0 users load average: 1.01 1.03 1.00
news://news.3home.net news://news.hkpcug.org news://news.newsgroup.com.hk

Gene
Mon Jan 08 21:19:20 CST 2007

"Olaf Doschke" <b2xhZi5kb3NjaGtlQHNldG1pY3MuZGU@strconv.14.de> wrote:

[snip]

>Imagine this situation:
>A record needs two dates in cronological order.
>user enters
>
>date1 08.01.08 (typo, user wanted 08.01.07)
>date2 01.04.07
>
>Now your kind of validation would force the user to
>enter a date2, which is after date1, to be able to set
>focus to something else. But in fact the error is NOT
>in date2, but in date1!

There are two forms of validation to consider here: control-level
and form-level. Form-level validation should only be done when the
form is supposedly complete. You can, with control-level validations,
say, check that date1 is in the current month and that date2 is in the
current month, but you have to wait for the form-level validation to
ensure that date1<date2.

[snip]

Sincerely,

Gene Wirchenko

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

Olaf
Tue Jan 09 02:05:07 CST 2007

> There are two forms of validation to consider here: control-level
> and form-level. Form-level validation should only be done when the
> form is supposedly complete.
agreed, I'd say that is the case if the user wants to save or exit.

> You can, with control-level validations,
> say, check that date1 is in the current month and that date2 is in the
> current month
you could also even validate, just the things you can
validate when only considering this value. Could of course
also use a date picker to ensure only valid dates can be
picked. Could also check, wheter the date is within a certain
range, if that matters.

You could also support a user to only need to enter
month/day and let the year default to this year.

Whatever, but....

> but you have to wait for the form-level validation to
> ensure that date1<date2.

Yes, true.

Bye, Olaf.

Al
Tue Jan 09 07:45:01 CST 2007

> Quintessence: make form level validation, call
> the form level validation function at field level
> to give a warning, but still always return .T. in
> the valid event. As the essence is preventing false
> data in the tables, not in the form. Give the user a
> chance to rightyfy the entered data.

essentially, we agree, form level for data consistency etc
and field level for user

Now that we have solved that problem <g>, lets get back to
the original "leaving form"
It should now be clear that valid/lost focus/etc should NOT fire when
switching
to another form by clicking/menu/ etc

al