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!

Summing totals in text fields on forms.

Status
Not open for further replies.

dale3972

Programmer
Feb 6, 2014
23
US
Hello again. Thanks for all the help in the past. I have managed to convert all my 2.6 forms into beautiful visual forms but I am having a problem with some of the text fields that in the past converted payments into totals. I have tried everything. Here is what I am trying to do. On my payment form I have this. WC_case is my main database.

CHECK AMOUNT (TEXT LABELS) CONTROL SOURCE: WC_CASE.CK_PAID
DA FEE WC_CASE.DA_PAID
MERCHANT FEE WC_CASE.FEE_PAID

TOTAL: (Here is where I am having problems) How to total these? What property in the text field box should I be going to? I have tried SUM ck_paid + da_paid + fee_paid. I have tried making a variable gnTotal, declaring it, and adding gnTotal = ck_paid + da_paid + fee_paid. I don't know what it is about the visual help section, but it does not seem to answer anything for me.

So how do I create a text field that totals the three text fields I have on a form?

Thanks so much in advance!
 
I never was a fox 2.6 user, did a totalling text field existed there? How did it know what to sum?

You are almost there, take your variable idea, then you can set the textbox VALUE to gnTotal, and it's displayed.

Without such a variable, which wouldn't work with many such sums anymore, use the properties window and set the totals textbox CONTROLSOURCE property to the expression (wc_case.ck_paid + wc_case.da_paid + wc_case.fee_paid) including parentheses.

Bye, Olaf.
 
You guys are great. Dave I did look at the value property and can see the possibilities with it. Thanks. Olaf, problem solved, what I was not doing was putting the parenthesis around the ck_paid + da_paid + fee_paid in the control source. I did and now everything works fine! Thanks! In Fox 2.6 there was no total text field per say. Total was a label I used. But you could add ck_paid + da_paid + fee_paid in the output section without the parenthesis.

I spent three hours trying to figure this out last night. Thanks for saving me hours more time. Must appreciated!!!
 
Actually any expression in CONTROLSOURCE should do, it's a long winded story, why in detail the parenthesis is needed. It wasn't always needed, that became a problem in VFP7, AFAIR.

I think it has to do with name expressions being valid for both variables and fields, it has to do more with the two way nature of the CONTROLSOURCE to read the value from the specified controlsource and also take it as the destination to write back modified values. Adding parenthesis makes sure it's an expression for a calculated value, VFP then doesn't try to determine a destination to write back to, the control is readonly and the expression is simply only evaluated and displayed.

That's a nice side effect. You can make use of it, because if you eg set the controlsource of the check amount textbox to (ck_paid), the textbox will be readonly, too, without it's .ReadOnly property being set .T. and even though it's not a readonly cursor and the DBF doesn't have its write protection flag set.

Bye, Olaf.

 
I would have know that parenthesis would be the source of my frustration. The story may be long winded, does not matter as long as it works. lol. Thanks again! :)
 
I meant that I would have never known that the parenthesis would be the source of my frustration. Much thanks!
 
FWIW, I wouldn't do it with ControlSource. I'd add a method that computes the total, and then call that method from the InteractiveChange and ProgrammaticChange methods of the three textboxes.

In fact, I probably create a textbox class with the calls in it and use it for all three fields. The advantage of doing it this way is that if you have another form that needs a similar approach, the work is just about done for you. You just have to write the totalling code in the method.

And if the calculation changes down the road, you fix it in one place and it just works.

Tamar
 
Thanks Tamar. But I am trying to stay away from classes and anything non 2.6 as I can. I was left with converting several Worthless Check applications into Visual and I am going to keep it simple as possible. I know I have to rebuild the forms but that is all I am going to do. When it comes to changing the app to another customers, I am simply going to rename the form and make any appropriate changes in the buttons, etc. Thanks for your help, however.
 
I am trying to stay away from classes and anything non 2.6 as I can.

But you can still adopt Tamar's suggestion of using an alternative to ControlSource. Her advice was to compute the total (a simple addition process) whenever the value in any of the textboxes changes. Whether or not you do that at the class level doesn't alter the basic technique. For what it's worth, I would also do it that way, rather than with a ControlSource.

You might argue that doing a calculation in the InteractiveChange of a control is non-2.6. But then, so is using a ControlSource.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Is it about the pending change of display you have with a controlsource or about OOP?

I would agree avoiding OOP in general is a bad choice, in this case it's a bit over the top, you could also do Thisform.Refresh() in each InteractiveChange and ProgrammaticChange of the other textboxes to refresh the sum, when needed. The calculation is already at a centralized place in the total textbox controlsource. If it get's more complex you can call a method from the controlsource, too. This encapsulates this calculation at the total textbox. Also, the refresh only is needed at all, if the ck_paid, da_paid, or fee_paid values will change. Will they be editable? If so, the most important part of Tamar's and Mikes suggestions are, you don't get an immediate refresh of the sum, without doing anything in the other textboxes. The user will see the sum change only when setting focus to the total textbox.

Bye, Olaf.
 
I will play around with this approach. It does sound more solid. When I said I was trying to avoid anything non 2.6 as I could, what I really meant I am trying to keep the rebuilding as simple as possible with what I already know. But looking back, I built an entire complex form with four page frames and that was pure visual. But again, I had to get help from these forums on the page frames. Thanks again, for all the help!
 
Staying away from classes is going to make your task much harder. Learning to use simple classes to avoid duplicating code and ensuring that code changes happen everywhere you need them is a huge time-saver.

Trying to find an analogy. How about this? Suppose you've only ever had an open fire to cook on, and you get a modern range with burners and an over. You might say you'll only use the burners because it's like having a fire, but you lose a lot by not using the oven. There's a whole class of things you can't cook.

Tamar
 
Very creative analogy. I am almost done with this one project, but will take your advice and open my mind some more. On my next customers project I will learn more about classes. Time is essential now. Once I have at least one app in place and running, I will have more time to reflect and improve.

Much appreciated!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top