Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Refresh on each input 1

Status
Not open for further replies.

audiopro

Programmer
Apr 1, 2004
3,165
GB
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
 
Yes, I'm th third in the row, if you set a control visibility, that will show it, no need for a refresh.
The only thing which you might want to trigger in your lostfocus is showing controls and hiding others.

I can understand in case of 200 fiels this is supporting a better streamlined workflow instead of showing all controls from the start.

That's a totally different situation.

I haven't done such a thing, I'm in the camp of not enforcing a certain input order, but as said in that case the user needs a bit of orientation and where to start.

There's something else you can do, which does not need much code per action. Assume you form allows a clerk to enter payment method via an optiongroup, that optiongroup may set the activepage of a pageframe with page1 for cash and page2 for credit card payment, etc. You set the pageframe.tabs to .f. and only the pure pages will be visible.

I inherited a horror application with a single form with sometimes 3 or 4 levels of pageframes inside pageframes, this is not where it should end. Also, in this same form, there are many containers one over the other, which are made visible or hidden at runtime. This makes editing and mainting this form simply undable. Everything is digged so deep, if you would want to visually navigate to some control, you would actuall need to move controls out of the way, and later put them back, or the whole thing would not work anymore.

You could also think of splitting your form into several forms, which show up as popups. So I point back to Dan, you don't do 200 control forms. Even if you have a workflow that can go so many different routes, that it may take 200 or more controls of which the one half or the other third is only shown in corner cases. Then by all sanity, you don't quench this into one form, just because it's one workflow of POS payment.

Single simple forms with datasession set to 1 (default datasession) work in the same dataseswsion as the form they are started from, this is one thing you should make use of, to let your popup forms have easy access to the same DBF and even to the current records, without doing anything in their form dataenvironment, load or init. Single form with a subpart of your workflow can be maintained much easier and also be developed in parallel and you can add further forms for further added sub workflows, eg a new payment method or for weighing or barcode scanning.

This kind of form overpopulated with controls is a dying species. Tablet and touch are the future and this involves zooming and panning. You can still do huge forms this way, but an easier use than through scrolling comes with screens (there you may even have the revival of dos screens, no more windows over windows, single screens you swipe back and forth) and controls need to get larger, though dpi values go up, just because your granularity now isn't the pixel you can address with a mouse pointer, but fingerprint large areas.

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

I'm afraid this sort of thing often happens in this forum. Someone asks a relatively straighforward question, and we then answer it to death. (I'm as guilty as anyone in doing this.)

I hope it won't put you off asking more questions in the future. Most of the time, we do manage to come up with some useful answers.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
AudioPro - I think this is what you're looking for. I have a method in my standard form class called EnableControls. That's where I put all the code that figures out which controls should be enabled or disabled, or in your case, made visible or invisible.

Then, I call that method from anywhere that conditions can change such that I need to check that stuff.

If you were developing new forms, the right way to do this would be to add a call to ThisForm.EnableControls() in the LostFocus of each of your "base" control classes (that is, your first level subclasses derived from the VFP base classes).

Since you're working with existing forms, and apparently are using base controls, the easiest way to handle this will be to add a form method, BindLostFocus, with code like this:

Code:
LPARAMETERS oObject

LOCAL oControl

FOR EACH oControl IN oObject FOXOBJECT
  IF PEMSTATUS(m.oControl, "LostFocus", 5)
     BindEvent(m.oControl, "LostFocus", ThisForm, "EnableControls", 1)
  ENDIF

  IF PEMSTATUS(m.oControl, "Objects", 5)
     ThisForm.BindLostFocus(m.oControl)
  ENDIF
ENDFOR

Call this method from the form's Init.

Tamar
 
Tamar
Thank you for understanding what I am doing.
I already have the method which controls fields and all that side of things is working.
All I wanted was a means of adding the phrase 'thisform.fresh' (the name of my method) into all of the lost.focus events at once, rather than enter them individually. The whole thread has been in vain as it seems such things are not possible. I thought it could either be done with a form level 'change' function or the instruction could be added at runtime.
The best method is a base class with the lost.focus instruction already embedded but I am adapting an existing form.

Olaf
The layout is all in a single container in the form of a grid. Only the relevant fields show and they are coloured to show the viewer the state of them, green is good, yellow is optional data and red is missing or incomplete data. The grid is split into sections and changing the contents of a single field can affect fields in other sections which is why I want the form to be refreshed/repopulated after each field entry.

There are 4 people who use the system for adding and editing records in the stock database and they all find it simple to use. I used to work at the shop myself and developed it as part of their EPOS system which integrates with their website.

Keith
 
Tamars answer is fine, it's elaborating on bindevent, what I already hinted on, additionally to introducing the idea of a central EnableControls. Enabling/Disabling controls also is what the ffc application framework does in forms you create with the wizard, so this concept is well known and defined.

But I have another understanding of UI today. I don't like disabled controls, because they most often just rise questions from users, what to fill in to enable something. This can be the fault of the developer not streamlining the workflow properly, this can also be a problem of the user's understanding.

I often have forms with a compound control known as "mover". You have a list of options filled with selectable items, you have a list of selections, initially empty. You add something to the selections list, then click an action button, eg print a receipt or start a further form, whatever.

I could disable the action button, until there is at least one option selected into the selection list. But sometimes beginner users merely click an item in the options list and don't move it to selection, that needs a double click or they could select multiple items and use a right arrow button to move items from the options to selections. I rather not disable the button, but instead let the click display a user friendly message to please select items into the selection list, as there is nothing I can do with no selections. This whole mechanism then is self explanatory, more than a button which only get's enabled when you select an item.

And this is just a simple example. I say this because this concept of disabling is outdated. Look at any smartphone interface, do you really know disabled items, do you know a greyed icon means something is disabled? Users click on such buttons and get angry they doen't work, and they are not told what to do.

Actually I corrected such a form recently, which was a choice of data to transfer from a pc (online) to a netbook (offline). In case you didn't make a selection you got an empty transfer file, in detail it wasn't empty, because there always is additional base data. I added the message and n ow it should be clear.

There are pros and cons, but even if you did what you did for many years, new user come in with a different mindset. Kids don't start with PCs today, they start learning to work with smartphones and are used to a totally different UI.

I can tell you a story happening to me, with something so simple as a mail client. Outlook 2010 that is. First time I used this a created a new mail and finally wanted to send it, but there was no Send button. You might wonder, I make this up, but actually, if you don't configure your outlook 2010 account a mail form has no send. It does neither have a disabled or enabled button, it simply has no button. And nothing is telling me my administrator forgot to configure outlook after installing it.

It's actually more natural to not get confronted with the whole UI, which could get enabled somehow, but with the base controls which always are needed at start. But in my case the send should be there, if the form should rather warn me before I start writing a mail, that I can't send it.

Aside of this Outlook problem, to only show controls for an initial step and hide the next steps, especially if they are optional, until they become necessary, is a good strategy, I think. But I already warned you about not putting everything into one form, you better have popup windows, and even if you would want to have the controls on this form, I wouldn't put controls on the form invisible and show them, I would rather design container classes and add them to the form. That would also make it a class you can separately edit and maintain as the developer. You can do containers, you also can do forms without title bar and position them at where you want them, where you had your controls. You have to think both about the user and about your need to maintain such a UI in the form/class designers. Events to do this would most probably not be lostfocus, but already click or interactive change of options or buttons, so a general binding of textboxes to a form method is also not, what I would do for that matter.

It's very individual what needs to be done on the form level and I wouldn't put this into a general method. What would be a good idea is not to let a button show a container, but program a mediator, a manger knowing the ui and what controls are there for what part of the workflow. Then you would for example have a payment option "credit card" and in it's click would do THISFORM.oWorkFlowManager.ShowControls("credit card payment") or THISFORM.oWorkFlowManager.ShowCreditCardPayment() or THISFORM.oWorkFlowManager.ShowPaymentMethod("credit card"). However you design this is your choice. In any case this would also be rather self explanatory code to further developers later perhaps needed to maintain the application. The workflow manager class would have whatever code is needed, to show the appropriate portion of your form or start a new form.

Bye, Olaf.
 
This whole discussion is getting a bit too heavy for me I am afraid. I am only a humble programmer eeking out a meagre existence on the crumbs of work I pick up while I wander the local streets dressed in rags.

Olaf
I know what you mean about the modern way of working being centred around a different type of UI than us old timers are used to. This fascination with little graphic symbols everywhere, where there used to be simple, intuitive text menus has been added to just about every mainstream software package available. I personally don't think the little graphics in the menus of software packages such as Word, Excel and the like are anywhere near as intuitive as the old fashioned text menus. The bewildering array of symbols on the menu bar of these programs is just confusing and finding the right one to perform a particular task can take ages.
The EPOS application in question was designed by the people who use it on a daily basis and the data input form is no exception. The data is entered in a strict order to ensure the relevant data is always added. Any empty fields which should contain data are highlighted on the form and it is not possible to save a record with essential data missing. Having all of a single record's data visible has another advantage as it makes it easy to check a particular field of numerous records.

I am sure that the functionality could be designed in hundreds of different ways but the method we use works very well in practice. After it was designed, I spent a lot of time watching other people using it and made a number of changes to make the work flow as efficient as possible. On the coding side of things, I am sure if I rewrote it the code would be much more streamlined but I don't think the functionality would be much different that it is now.

On the subject of design, I have recently been thrown in at the deep end with Windows 8 and the whole GUI appears to have been designed by someone who does nothing but play with mind numbing apps all day. The main criteria would appear to be that it looks nice and all functionality has to be hidden behind this beauty.

Critics have commented about the lack of a start button but supporters have countered that we just don't like change and we will get to love it eventually. Apparently, version 8.1 sees the reintroduction of the start menu. I really did try to get on with the oddly named Splash Screen but in the end I succeeded in bypassing it and starting my machines on their desktops.

My other design gripe is with Windows Live Mail, well I can't use the native mail client as it doesn't support the POP3 protocol. The layout of WLM is quite standard but somebody decided I needed a separate Inbox, Outbox, Sent Items Folder, Drafts folder and Junk Mail Folder. Having 30 email addresses means I have 30 sets of separate folders. I have created message rules to stuff them all into one, just like it used to be but what a load of messing.

Keith
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top