Calculated field and or Variable

[Stan Mathews]

Re: Calculated field and or Variable

Correct, Allen.

Basic Concepts and Terminology

[SNusa]

Re: Calculated field and or Variable

.....So you are saying I should have stated it here as vn_V-Items ? I thought the "V-Items AS N" made it clear it was a number variable. Am I still missing something?

If you look at the variable right there near where it is declared, it's pretty obvious. But if you encounter (and try to use) this variable elsewhere on the form, (or as your code grows) you could easily make the mistake of thinking V-Items is the name of an item (type C) and not an amount.

Plus, as Allen stated (wasn't thinking as I never used the hyphen) alpha is going to run into problems "thinking" you're trying to subtract the value of "items" from the value "V". (to Alpha, your variable "V-Items" looks like two separate variables. (upon which it will try to perform a mathematical calculation, in this case subtraction)

For your variable, I personally would use a prefix of vnx_ (vnx_ItemsTOT, or vnx_ItemTOT, vnx_ItemsTotal, or vnx_ItemTotal etc.) which reflects the field you are actually calculating). ~Whenever I define calculated field variable, I always add an x to designate it as such, as it reminds me of the xy on the Alpha toolbar)

NOTE: While you can also specify variable scope (vn, vns, vng etc.) for instant recognition, there is one caveat. If you later realize you made an error in scope definition and need fix it.... All your code may run fine, but the variables will incorrectly reflect the original designated scope when the variable was first named.

[preston2]

Re: Calculated field and or Variable

You should not be using a "-" in your variable name. Alpha will think that you wish to subtract a variable "Items" from a variable "V"

Allen

Declaring a Variable

Got it.

[MoGrace]

Re: Calculated field and or Variable

Hi Preston,
Looking at your invoice form, I see that first the customer is purchasing the garments, then for the garments, the print charges must be calculated and added to the invoice. I see the need for both a Purchase Order and a Work Order.

So why not use a separate 'wo_chgs' table (can link to the P/O) to calculate these additional amounts which can then be added to the price of the garments? In your example there are both light and dark garment colors. Isn't it possible that the first garment group will have different print options than the 2nd? And you mention the location where the printing is to be put (weren't those choices: front, back, left and right?) that must also be specified. So somewhere in this process, it seems that a work order must be involved that puts all this detail forth. And that work order is where the heavy lifting can be done for calculating these charges which are then added to the invoice.

In my example below 65 garments are purchased & printed: all the employees at Big Daddy's get polo shirts with a logo printed on the front, but only 15 of them want the l/s shirts with the logo on the back. And only 20 want the hoodies that have printing on the front and a logo on the right sleeve. I was not sure whether you would add the garments together to get the 1st print location, or only if the print job was the same - so I separated some which may be using different colors for light vs dark colored garments.

[SNusa]

Re: Calculated field and or Variable

This is a late response to your initial question. (how to get calculated field into a variable)

Here's how: http://msgboard.alphasoftware.com/al...l=1#post598439

vc_vxyTotals = calculated_field_get(local_variables(),"vxyTotals").VALUE_GET()
[COLOR="#0000CD"]' (where vxyTotals is the calculated field on form)[/COLOR]

[preston2]

Re: Calculated field and or Variable

This is a late response to your initial question. (how to get calculated field into a variable)

Here's how: http://msgboard.alphasoftware.com/al...l=1#post598439

vc_vxyTotals = calculated_field_get(local_variables(),"vxyTotals").VALUE_GET()
[COLOR="#0000CD"]' (where vxyTotals is the calculated field on form)[/COLOR]

Ok, let me see if I follow this.

Lets say I have a calculated field named "Items" on a form thats calculated result is a number.

I would get the calculated field results into a variable named "vn_items" to use in Xbasic by using the following.

dim vn_Items as n
vn_Items = calculated_field_get(local_variables(),"Items").VALUE_GET()

[SNusa]

Re: Calculated field and or Variable

Ok, let me see if I follow this.

Lets say I have a calculated field named "Items" on a form thats calculated result is a number.

I would get the calculated field results into a variable named "vn_items" to use in Xbasic by using the following.

dim vn_Items as n
vn_Items = calculated_field_get(local_variables(),"Items").VALUE_GET()

Yep, providing items is of type N here......... Click here: ==> CALCULATED_FIELD_GET Function

It's located in the Wiki under Functions (above)

[preston2]

Re: Calculated field and or Variable

Yep.... Click here: ==> CALCULATED_FIELD_GET Function

Located in the Wiki under Functions (above)

Thanks Robert for clarifying that for me. I had already studied the calculated_filed_get function on Wiki along with all the aspects such as the "local_variables" function before I posted message 21. It just takes me awhile to grasp where I need to substitute my real world stuff in place of some of the things in examples. But I am learning more and more each day.

[SNusa]

Re: Calculated field and or Variable

Thanks Robert for clarifying that for me. I had already studied the calculated_filed_get function on Wiki along with all the aspects such as the "local_variables" function before I posted message 21. It just takes me awhile to grasp where I need to substitute my real world stuff in place of some of the things in examples. But I am learning more and more each day.

Me too. I actually reinforce my present knowledge of a5 by watching and responding to other threads (of common interest) here on the forum. Glad I could help. (Learning a5 is a daunting task at first. But at some point, everything just "begins to click!") ~My best suggestion to you would be to categorize all your subscribed threads here into folders, thus creating your own forum "go-to list." ~ It makes a good starting point, at least!

I'm actually more comfortable with writing basic X-basic code today than I am at "planting form controls." ~ Good notes on hundreds of hours of online training. (and a few reference books of years gone by) ~I now just use the Genies (Action Scripting) for reference if I get stuck coding.... ("I view the X-basic code, and make mine work")

IMHO, beyond becoming comfortable with the GUI (and understanding database setup).... Core X-basic, Object References, Pointers, Where to look in Wiki, (and then knowing what pitfalls to avoid from the get-go) is "The Key To a5!"

I don't know if this indicates which side of the ("gifted" <---> "challenged") slider scale I'm personally on: But it took me nearly a two month commitment of "hard-core" (8+ hours /day) of intense involvement to pull it all together.... Now I just need some "seasoning"..... At present, it may take me 3x the time as a "seasoned pro", but I think I can now do almost anything with a5, and do it well..... (at least on the desktop side) ~ Learn the desktop and core X-basic first ~ then the web will come "easy!"