Refresh on each input 1

[audiopro]

Simple question.
How do I refresh the form when each input field of a form loses the focus?
I know I can use each control's lost focus event but there must be a quicker way.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

there must be a quicker way

Keith,

When you say "quicker", do you mean something that will run faster, or something that is easier for you to code.

If the former, don't worry about it. Refeshing a former is likely to be slow, so whatever mechanism you use for triggering it won't make a significant difference.

If you mean you want it to be easier to code, the obvious method would be to base each type of control on a common class, and to do the refresh in the LostFocus at the class level. Going further, you could add a switch; and only do the refresh when the switch is on.

Of course, the obvious question is why you want to do this. Refreshing a form is slow, and you would normally only do it when it is really necessary.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I see it different, as I take the first request more serious than the last.

You say you only want to refresh the form, when all control lose focus, eg when you leave the form. The easy answer for that is form.deactivate(), but I don't know if you rather mean another situation, if focus is on none of the bound controls, but the user finished editing and tabs to eg save/close or navigation buttons. And also be warned, that clicking on a toolbar in fact does not cause form.deactivate(), so eg a save button in a toolbar doing a tableupdate(), saving the buffer, can cause the last change in the current control to not be saved. But that's not a refresh problem of controls, that's a refresh problem of the buffer, which does not contain the current control's value, until it passes it's value on via valid event. The solution in a toolbar save button is _screen.activecontrol.setfocus(), which causes a whole cycle of valid, lostfocus, when, gotfocus on the current control and thereby saves the current value to the buffer. That's simplificated, because in case of a grid, that's insufficient.

>I know I can use each control's lost focus event but there must be a quicker way.
Again, as I take your first request more serious, this is not what you want, this would refresh the form after you tab from one control to the next. This is not needed at all, because your form is current in most cases, except you allow editing of the same record from many users at the same time. But then you would need automatic refresh, see SET REFRFESH, then.

For network it's best to not autorefresh, the need might be, if your form shows eg the seats of a cinema or tables in a restaurant and your pos system is used in 2 or three stations at the same time.

Bye, Olaf.

 

[audiopro]

Wow - I seem to have opened a can of worms - oops.

I understand the speed issues and maybe I am approaching what I want to do in the wrong way.

I have an form with potentially 200 input fields.
Initially a few fields are displayed and what the user types in those fields controls which subsequent fields are displayed. The form is on a small network but will only ever be accessed from a single computer.

Would it be better to call a method each time a control loses the focus and put the code in there? I always prefer to have my code in one place rather than scattered to all four corners of the wind, which seems to be the OOP way (call me old fashioned).
Same question applies really, how can I add code to all the text fields on a form at once, rather than iterate through them? A class would be good if the form was not already designed.

Has the Tek-tips email notification thingy gone awry, I don't get them any more.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

>Initially a few fields are displayed and what the user types in those fields controls which subsequent fields are displayed.

I can partially understand this may be an advantage, if 200 fields are involved, instead of binding them from the start. But if it's still a single record, VFP does not do anything more granular then reading a record, the time you load the first field of a record, all other fields also are loaded.

I am still puzzled why you want this kind of refresh, even more so because now it seems you would need to also bind fields after some other fields are filled in. And what has this to do with leaving some form?

Is this one table, or do you have parent/child data with optional child data?

I think you have to explain a bit more about the process of data input and how several forms are involved and why you need them to refresh. If everything is entered by the same single user, the entered values are the field values, a refresh would only be needed after navigating to another record, or if values are calculated automatically.

Bye, Olaf.

 

[audiopro]

You are making this a lot more complicated than it actually is.
I have 200 input controls on a form, is there a way of adding code to the lost.focus method of numerous input fields at once.







Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Not, if they are base textbox, combobox, etc. controls.

Bye, Olaf.

 

[Olaf Doschke]

What you can do is bind to all controls via BINDEVENT().

Bye, Olaf.

 

[audiopro]

Thanks
I only want to add the code to text input fields.
I have gone through them and added the code manually, just wondered if there was a faster way.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Faster to develop in an already done form: Code in one place, then Bindevent to all controls you want to bind to.
Faster running: direct coding
Ideal: Code into a class, which means one place to edit and direct execution without the overhead of event binding.

Bye, Olaf.

 

[Mike Lewis]

I have gone through them and added the code manually, just wondered if there was a faster way.

Keith, that was my original suggestion. Make all the controls a sub-class of a parent class, and put the required code in the LostFocus of the parent class.

But it would be better still if you set the control source of all the controls at the outset, so that they will all get populated only when the user moves to a new record. To control which fields are displayed, toggle their Visible property. That way, you won't need to do a refresh after each input, which will make the whole thing go very much faster.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I still don't understand why he needs refresh, if the user enters/modifies the value, the control value is the freshest value there is anyway.

Bye, Olaf.

 

[Mike Lewis]

Olaf, I'm assuming it's because, in his original scenario, some of the controls weren't initially visible, and he thought that he needed to refresh those controls to make their values available. What I was suggesting avoids the need for that (although your idea of delayed binding would be another good approach).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

But it would be better still if you

.... didn't have 200 controls on a single form.

 

[audiopro]

It is an INPUT FORM!!!!
It does actually operate as an edit screen too but the refresh functionality is for checking inputted data or changed data.

I could do it with buttons but doing it this way is more intuitive, I know this because the form has been in use for over 8 years on an EPOS system which interfaces with a webshop. I am writing a new version because I need to gather some additional information for some extra functionality.

There are never more than about 50 input controls visible on a completed form but which fields are shown depends on which data fields have been completed.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, an input form does not differ from a edit form, you only bind to a new record instead of an already existing record.
And still, bound or unbound, the value typed in is the value, isn't it? What needs to be refreshed, if the source of the value is the control itself?

Bye, Olaf.

 

[audiopro]

he thought that he needed to refresh those controls to make their values available

I am not in the least bit interested in refreshing the data I have just entered, but the page is refreshed to display input fields which were hidden before but are now required. Which new fields are displayed is dependent on whether or not data was entered into the previous field. If I don't call a routine when the field loses it's focus, how can the display of the next fields be triggered?
Perhaps the phrase 'refresh' is wrong, may be 'updated' would be a better way of putting it.

A simple question has turned into a deep misunderstanding of a working model.




Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

the page is refreshed to display input fields which were hidden before but are now required.

I would suggest this is the root of any misunderstanding.

Contrary to what many VFP developers believe, you do not need to refresh a form simply to make visible any fields that were previously hidden. In most cases, the only reason to refresh a form is if the underlying data has changed (either because the record pointer has moved, or some other process has changed the data while your form is showing it).

If you were to modify your original question, changing "refresh" to "run some code to make certain fields visible", then we could get rid of much of the misunderstanding. But my original suggestion would still stand: base the controls on a common class, and call the relevant code at the level of that class.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

you do not need to refresh a form simply to make visible any fields that were previously hidden.

I agree.

Typically for each affected Form Object you only need to issue something like:
ThisForm.txtIntendedTextBox.Visible = .T.
And if it had also been previously Disabled:
ThisForm.txtIntendedTextBox.Enabled = .T.

To have a Hidden Textbox (or other Form Object) appear after having been Hidden.

For many of the Forms that I have created for clients, I have typically put code like this in the Valid Method of the controlling TextBox (or other Form object).

Good Luck,
JRB-Bldr

 

[audiopro]

I am beginning to wish I hadn't asked the darned question now.

As stated earlier, the application is up and running and has been for years, all I was looking for was a means of adding code to the lost.focus methods of numerous input controls at once. I agree the term 'refresh' was misleading but I had hoped that my second attempt at the question would get us back on track but by this time unasked questions were being answered.

I still stand by my original question though, as I had hoped there was a form wide 'on change event' like there is in javascript but it appears not.



Keith

http://www.studiosoft.co.uk