Preserving values entered into a modal form - ‘static’ variables

[AndrewMozley]

A modal form provides a service of calculating the amount of material required for another data entry form ‘”quotation”; this is done in response to a function key on the quotation form.

When the modal form – call it “Calc_Req” - is first called, the user keys in several parameters – length, width, quality, wastage &c. The requirement is calculated: the result is displayed on screen and passed back to the calling form. The form “Calc_Req” then closes.

If the form “Calc_Req” is called again during the preparation of the same quotation, it would be good if the values (length &c) were remembered from the previous call and used as defaults on this modal form. How can this be best achieved?

Thank you

 

[Mike Lewis]

Andrew,

Do you only want to remember the parameter values for the current quotation, or do you want to save them across sessions?

If the former, then one option would be store the values in properties of the calling form. So the calling form would have properties such as nWidth, nWastage, etc. When the calling form calls the modal form, pass a reference to the calling form as a parameter (in other words, pass THISFORM to the modal form). Have the modal form store that reference as a property of itself (that, is of the modal form). Name that property, say, oCaller. Then, the modal form can access the properties of the caller by refereing to e.g. THISFORM.oCaller.nWastage, and so on. The modal form can easily save and retrieve values from those properties, and use them in subsequent calls.

If you want to save the values across sessions, then you will need to store them in a table.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

My first idea would be just hiding instead of releasing the form. That works for the current application session. If you're using RETURN lnResult from Unload to get the response back to the caller, that'll need a new mechanism for passing back the result.

One of the easiest ways is you have a callbackform property in the modal form, that can be set from the caller to itself, the caller form sets loModalform.Callbackform = THISFORM before showing the loModalform.

Then returning a result can be done by providing a callback method in the caller form by definition, you eg always have a ResponseArrive() method in your calling forms and called forms call that callback. So the modal form then calls THISFORM.Callbackform.ResponseArrive(lnResult) and afterward hides itself with Thisform.Hide() instead of releasing. When you later Show it again, the current state is preserved.

That's also a good way to work with non modal forms, which don't support the return from Unload anyway.

Bye, Olaf.

 

[AndrewMozley]

Thank you. These are both very helpful suggestions. In answer to your question, Mike, the values do not need to be remembered between sessions; and the ‘Calculate’ form is only called from one form - ‘Quotation'.

At present I will probably go with keeping these interesting values as properties of the calling form, and passing Thisform to the modal form so that I can pick the values up from it.

But I will also experiment with your approach Olaf. Am I right in thinking that if I do ‘Thisform.hide’ in the modal form ‘Calc_Req’, that will allow the calling form, ‘Quotation’ to pick up from where it originally called ‘Calc_Req’, (in a KeyPress event).

Andrew

 

[Olaf Doschke]

It would be interesting to test what happens if you hide a modal form, indeed. but may you simply change it to non modal.

Your continuation code then should simply be in the ResponseArrive() method, as that is what Calc_Req calls back to in the Quotation form. You don't need and can't have any code after the form show(), because you don't come back there, there is no release of the called form. It also shouldn't be modal for that matter and then means code following would run too early. So you split up your code before the form request up to the DO FORM and after getting the answer in ResponseArrive() to react to the result.

Modal forms are hurdles anyway, they hinder you to work in parallel, eg if a call comes in, you simply let everything stay open and as is and start yet another form to answer a phone call requesting some info or such things, especially within this same application. That's when modal forms are just a nuisance.

People always argue streamlining workflow by enforcing it with such modal dialogs are guiding users, I don't think so.

Bye, Olaf.

 

[AndrewMozley]

I take your point Olaf. In this case I am using a modal form (to handle a little calculation) because I wanted to inhibit other processing on the calling form.

I suppose that I could have included this calculation in a container or perhaps page within a frame on the calling (quotation) form. But this was making the form design rather messy, and - when the details for the calculation were being entered – I wanted to inhibit data entry to other parts of the quotation form.

So that was why I was inclined to go for a modal form, which would do its business and then vanish.

But I take your point that this is stopping all other activity within the application. So – for example if the user felt he wanted to enquire about stock availability – which is a different form - he cannot do that.

 

[Olaf Doschke]

It's not at all wrong to have lots of small forms popping up, actually users like and know this in many small places like the dropdown list of comboboxes. There's pros and cons about the interface strucure as things like that don't get apparent before you open up a feature, but it's also not intuitive to have a big form with all options you may use. The best user interfaces are clean and sparsely filled.

>if the user felt he wanted to enquire about stock availability – which is a different form - he cannot do that.
Yes, that aspect.

The shorter the taks is you do with a modal form, the more it suits, therefore the messagebox is a good example, it also should get your attention, but it also doesn't interrupt you with a lengthy task.

Inputting some dimensions of a window or door could also qualify for such a short modal dialog, but you see when you do this repeatedly that outsourced form ideally would stay as is and just collapse when not used for the moment.

In the past I maintained a form for product formulas, where one of the popup forms is for choosing ingredients, finding and picking them. That's also done as a permanent form not showing at first, then I show and hide it.

Bye, Olaf.

 

[Mike Lewis]

From a user interface point of view, I would be inclined to use a modal form in this case. Of course, in general, you want to make your application as modeless as possible. But where you are collecting a small amount of information related to a specific task (in this case, preparing a quotation), a modal form is acceptable - I might say even preferable. What I would avoid is modal forms for longer and more complicated tasks. So, in this case, the calling form would almost certainly be modeless.

I would also avoid nesting of modal forms, that is, where modal form 1 calls modal form 2, and so on. So the user would have to laboriously click down through the stack and then up again to exit. In other words, modal forms should be for quick in-and-out operations.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

In this case the modality just isn't ideal from the perspective of the form just being hidden and keeping its state compared to exiting to return a result from Unload.

As I said It would be interesting to test what happens if you hide a modal form, indeed. I never tried that. The return mechanism then can't work, as you don't get to unload, but the caller might continue after do form. But even if that works, you don't get the return value there, anyway, so the easiest way would be to go non modal. Not because it's necessary, but because you don't make use of the normal return meachnism anyway. And when you do that the non modal way, you also can have the overall benefit of that mode, even if it isn't a big plus.

Bye, Olaf.

 

[Mike Lewis]

I've occasionally done the hide/show thing with forms - modal and modeless - but never when returning data. I tend to use it for small help windows or extended tooltips that contain more or less static text. But I don't see any problem in this case.

Obviously, when you hide a form, it can't return a value to the caller, even if it is modal, because you are not executing the Unload method. But you could still pass values back to the caller, using the mechanism discussed earlier (storing a reference to the caller in a property of the called). You would trigger that from the Close or Save button (which in practice neither closes the form nor saves the data, but the user doesn't know that).

When you hide a modal form, in effect it becomes modeless - in the sense that the user can then move around among the other forms. So I think that strategy should work in this case. But I don't see any great advantage compared to using a modal form in the normal way. It's not as if the form would take a long to instantiate or to be destroyed. I suggest, Andrew, that you try it and see how you feel about it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, the big advantage is, that the hidden form simply keeps its textbox values. You don't need to store them, the form does. That's the whole point.

Bye, Olaf.