Announcement

**martinwcole** · 01-27-2016, 05:13 AM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

If the calc fields are in the table, presumably you know that table calc fields are only recalculated when the table is changed and saved.
Having summary fields on a form that have to re-summarize every time you fetch a record sounds like a heck of a load!!

**SNusa** · 01-27-2016, 12:50 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Hi Martin....
No, the calc fields are "static" when this happens.... Nothing is changing with the stored data in the tables. Only the child record (not the parent record) changes which forces the recalc. of the calculated form fields.

The actual data in the fields and browse records (derived from these calculated fields) are all good. It's only the dynamic properties (like border, button fill color and text color) that are not respecting the new values that are calculated when moving to a different record. (This "color coding" of objects is for visual cues to the user that certain records have qualified for user intervention.)

It's almost like the RTF field refresh issue.... Sometimes RTF fields (which I seldom use) are not updated with new values and you have to force a refresh on the field.
But there is no refresh/repaint/recalc/resynch function/method I can find that does the same thing for these objects properties. (Or a wait function to make sure all the recalc's have finished calculating before the objects dynamic properties are updated.) It seems that once these fields "decide they have the correct values to work with, the properties are updated and that's that." And the only way to correct it is to move to another record and back to "try again." Besides that..... THE ONLY way I have found to guarantee ALL the colors etc. are displayed/drawn correctly (for all the objects) is to use a function that reads the data back out of the fields (which are correct) and reassign the objects color properties. (As mentioned above, moving off and back to another child record USUALLY fixes this too. (So I could possibly force a down/up on the browse, but there's not always multiple records in the browse either.)

Notes:
These color attributes (and fields which are totaling correctly) are based a calculated form field which is derived from a calculated field. (see below)
The problem only occurs maybe 20% of the time. And when it does, it doesn't effect all the dynamic objects, only some of them! (and not all of the properties either!)
When I first realized this was an issue I was using the a5 built-in dynamic conditional object builder. I then wrote a gobal function to draw the fields (based on the calc. field data) and tried that on numerous different events etc instead. The same problem occurred unless I added the wait function. Although the function works fine when manually triggered, turns out the results were actually worse when placing it in the different events to automate it's usage. Adding the WAIT_UNTIL(.T.=.F.,1,1) function was necessary to get it "as good as the other way." And ultimately that's why I'm thinking it's a timing issue ..... The function works fine 100% of the time for 100% of the objects and their properties whenever it is manually triggered with a button onPush, and it works with the onTimer event too. (Presumably because it's set to at least a second, and it runs "perpetually". ~ if it doesn't have the right data the first time, it does have it a second later)

FORM CALC FIELDS:

Code:

[COLOR="#0000CD"]cn_CombinedFobYearlyProgPoints[/COLOR] = total(calc->cn_FobYearProgPoints,grp->customers_tbl,grp->keyfobs_tbl) 'CALC FIELD #1

[COLOR="#FF0000"]cn_Award3Distance[/COLOR] = ([COLOR="#0000CD"]calc->cn_CombinedFobYearlyProgPoints[/COLOR] - session_variables(this.sessionhandle()).vp_ProgArray[vp_ProgArray.find(val(session_variables(this.sessionhandle()).vc_Year),"Ryear")].award3qual) 'CALC FIELD #2 (derived from CALC FIELD #1 above

I know that second calc field is a "whopper" in terms of it's "concatenated complexity" but it sure does the trick!
(It took quite a while for me to figure out how to extract that "threshold data." ~ Because both the array size and the actual years in the Ryear field differ at times.)

Number in red is displayed correctly in all the fields, but this same value (cn_CombinedFobYearlyProgPoints) is also the basis upon which the dynamic color properties (attributes) of buttons on the form are conditionally displayed.

**SNusa** · 01-27-2016, 01:13 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Should have first specified: The problem I'm having is with "Calculated Values" (on forms).... Not "Calculated Fields" (in tables)

Unlike RTF fields and dynamic object attributes: I'm beginning to wonder whether data in fields (which includes data in browse cells) is "constantly looking" for changes and responding/updating accordingly. If this is the case, I would thing there should be a way to flag a specific object's dynamic content as dirty which could/would in turn force an update of all the objects dynamic properties (based on new data)

I had been looking into calculated field functions/methods but found little......
I came across calculated_fields_reset() (in the XBE I think), but can't find any documentation on it.
Nor could I find any function/method to force a "resync" (set dirty?, recalc?) of an objects dynamic properties which might be used with a refresh or repaint etc.....
~And maybe even the RTF fields (when based on calculated field data) can't be "force refreshed"/also has this same issue? I haven't tried that.

And just maybe I can force an update somehow (of the second calculated field) via combining a CALCULATED_FIELD_SET() Function with a CALCULATED_FIELD_GET()?
(which might trigger a refresh of the objects dynamic properties?)

That didn't work.....
You can read the value of the calculated value with CALCULATED_FIELD_GET() but CALCULATED_FIELD_SET() doesn't set a value, it actually creates a calculated field....

**Ted Giles** · 01-28-2016, 10:02 AM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

So Rob, if the values are correct, but the colour and borders are going wonky, would Conditional Objects be better?

Any chance of a small sample Db and Form showing the problem?

**SNusa** · 01-28-2016, 10:45 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Hi Ted;
I'll see what I can "pack up" to send you lol.... And yes, maybe conditional objects might have been a viable solution. (Xbasic makes every object "conditional", so I've never used them lol.) I'm spending one more day on this... I'm 90% sure the problem is the calculated fields and an a5 internal timing. (The a5 "engine" seems to assume the calculations are done before they actually are, and then uses that incorrect partial summary value for processing the objects dynamic properties.) Adding the WAIT_UNTIL(.T.=.F.,1,1) puts a band-aid on it. (As does the form OnTimer event which is always "looking" at the values and repeatedly updating the object properties while the form is in focus.) Presently, I'm coding a work around for "first record in browse event triggering anomaly" that persists in the desktop browse object. (Yep, I'm a perfectionist at times, AAArrrggghhh!)

**SNusa** · 02-04-2016, 03:31 AM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

What appears to be missing is an <object>.dynamic_property_refresh() method. None of the object "refresh" (or resynch methods for that matter) have any influence on objects properties which are dynamically set with calculated form values that change. Once the are set, that's it. (Unlike calculated fields in a table which can be "tricked into causing a field refresh on a form via a table enter_begin and enter_end. ~ For more info on this, search for "object events" in the new help system.)

Moving forward: I have some info to share (when using calculated values) which may be helpful to others.....
When dealing with actual data fields, they can always be updated successfully by attaching the <parentform>.resynch() method to the appropriate events. (no big surprises here)
However: if you have a two calculated values (both defined using the xy button) and the second one is dependent upon the first value...... You may have to use <parentform>.resynch() twice!
(Place two lines of <form>.resynch() codes one right below/after the other one. Apparently, the second time you "resynch()", the second calculated field receives the correct/finalized amount from the first one.)

Optionally/alternatively, you you might want to use <object>.REFRESH_LAYOUT().
Note: The help documentation is rather confusing as it implies this command does not resynch. However, watching the script recorder indicates that .refresh_layout() is the same thing as .resynch()!

RTF fields are similar, in that they can also be "refreshed" following a ".resynch()" (method as described above). ~ Either individually, or all at the same time by using <parentform>.Refresh_Fields().

Now for the bad news (with a solution):
Unless I've missed something, dynamically assigned object properties can/do suffer from a timing issue. And if they don't resolve properly (ie: you're using dbsum() on tables with thousands of records etc....) You will likely run into problems as the the a5 engine resolves these properties before the calculations have fully competed. (And yes, conditional objects also suffer from this same timing problems. ~ Actually they fared just as poorly, and in some ways, actually worse/less predictable.)

The only solution I could find to guarantee dynamically calculated object properties are displayed correctly was:
To write a function (which assigns these property attributes based on calculations), and then call the function using the layout's "onTimer" event. (Which runs in the background every few seconds etc....) ~ Fortunately this problem typically won't result in field data being incorrect if the form designed properly.) And you can "get around this" so as long as you don't mind a background process playing "catch-up" (continually running in the background) as it updates the object properties every few seconds.

Of course you can also choose to NOT use any dynamically displayed object attributes based on changing values etc. But I'm a big believer in "visual display cues." (Especially on "busy data screens" in a retail environments. So I spent a considerable amount of time on this.) Also (because the two were closely related), I think I found a workaround for the browse events which fail to always "fire" as expected. (Kind of amazed I have the browse working this nicely!)

PS: If you're using calculated values within layouts, it's extremely beneficial to reference as many fields as possible via their .text properties as opposed to their .value properties. Convert, or do whatever you must when reusing the data once you've accessed it via the calculated (xy) value. Because when you access a field on a form via it's .value property (a field that is based on a calculated value..... It needlessly seems to recalculate the value! Aside from slowing down the page, too many of these will break things. On a positive note: I am literally amazed at the speeds I have achieved, given all the table summary operations in use on my form. I've presently got 6,000+ records that are being filtered &/or subtotaled 8 different ways (dbsum, total etc.) via calculated values. ~ And it literally happens in a flash! (One second or less even when the filtered sets are 1/2 of the data/3000 records!)

**martinwcole** · 02-04-2016, 11:39 AM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

I have never had any issues with form calc fields
I always just formcalc1.refresh(), formcalc2.refresh(), formcalc3.refresh
you could put the refresh commands in the onfetch event of the form

**DaveM** · 02-04-2016, 01:57 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

I have had some issues with calc fields in the past. Usually had a ton of them and were depending on other caslc fields up to 5-6 deep.
Having said that, I have not had problems in recent versions. I don't know if some of it got better or because I took the heavy lifting to scripts and functions showing the results in variables on the form rather than calculated fields.

**SNusa** · 02-04-2016, 04:54 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Hi guys;

First
@MartinCole: What I wish I could find (similar to the refresh you suggested) is a method like <form>.Refresh_Dynamic_Properties(). (Or <Object>.Dynamic_Property_Flag_Dirty and/or <Object>.Dynamic_Property_Reprocess() method.) ." ~ Rerefresh, resynch etc. does not check to see whether the underlying values used to dynamically assign object attributes are correct/"clean." (a way to force a5 to recheck an objects dynamic property value and see if they are based on correct values after they are drawn on screen.)

@DaveM: I'm working with calculated VALUES, not fields. (wording mistake I made in my initial post) More about this below, and why they can't be in functions for this usage. (Due to requirements, I actually have these calculated summary values placed in unbound fields in browses.)

I can use resynch, refresh, and repaint, refresh_layout, refresh_fields etc... trying to redraw these dynamically assigned object attributes until I'm blue in the face and nothing happens. ~ But manually assigning these same object properties (via a function or even via the IW window) using the same exact variables and code does update the display as expected.

Yes, it's very odd. There's a lot going on in this one form. And much of the data within the child table (which contains about 6000 records at present) is summed several different ways. (Multiple programs, multiple years, combined totals and a master summary etc.) I think this is just pushing/stressing the a5 .dbf a little. (DBF's because I wanted to make this a highly portable and package-able/easy-install desktop component.) Honestly: Until recently, I was concerned that the overhead of the large .dbf's might be too demanding on alpha's internal ".dbf engine." (Particularly because of the summary requirements.) But a5 seems to handle the load with a vengeance! (I'm sure a high end PC with SSd's is making a difference too!)

The calculated fields along with the refresh methods etc. work fine for displaying actual data in fields and in browses, but not RELIABLY for dynamically assigning object properties based on these calculated field totals. When I'm trying to use that calculated value data (based on dbsum's of large tables) to color/assign button attributes, button edges, and button background colors etc. is when the problem surfaces.) But because much of these calculated values are being displayed right within a browse... Taking the heavy lifting to a function is not feasibly feasible. (Calculated VALUES, not Fields.) Although the system seems very efficient, I think the problem lies in just too many buttons (12 buttons one per month) which have several properties dependent upon the calculated DBSUM summary fields. In the split second it takes to process the calculated fields, you can actually see the object properties change but not all of the buttons change "all the way" so I have to clean up afterwards.

PS: To give everyone an "idea" of how efficient this form is/is not functioning... I suspect this layout will continue to work reasonably with with child table sizes beyond 25,000 records. Also, interestingly enough, out of all the dynamically assigned (x12 buttons) attributes (border, fill, font, text color & text displayed): Text displayed in these buttons is always right. it's the coloring that isn't! I will spend more time with conditional objects down the road in combination with some of the tricks I've used to see whether I can get them working better. (I didn't do a lot of testing with them.)

**DaveM** · 02-04-2016, 11:28 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Robert,
Not trying to beat on you at all or start a pure old argument.
Can you possibly give an example of a calculation that HAS to be done in a calc field. The reason I ask is that I have clients that have record counts from 10,000 to 950,000 with very explicit calculations that have to be to a penny exact with hundreds of calculations to get there. Almost all of these are done in functions by way of scripts.

An example may help me(and others) understand so we can help you better to get past the issue.

After thought: Do you have calc fields with abnomally long character counts, like over 1024 spaces, letters and numbers? I don't remember off hand the max before stuff gets dropped.

**SNusa** · 02-07-2016, 01:47 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

As for the calc. values: They are not long (see below) and the only thing that is strange is the way the 3'rd calculated values uses an array search function to "find" the correct array value right within the calculated value expression. (It searches an array whis is "pre-loaded" on form init, and has session level scope. ~ See 3'rd calc. value below) Layout is essentially comprised of 3 tables. (And the middle table browse has 3 calc. field columns derived from calculated & indexed dbsums right in the browse fields.)..... I'm not re-using any of these subtotaled values from fields (inside or outside the browse) in the calculated value expressions either. (This form's middle browse also subtotals these columns below/outside the browse.) All calculated values are derived "internally" in the correct sequence.

Here are the 3 "related" calculated values presumably responsible for the "anomaly." It's the third one (in red) which is what the values of the "dynamic button attributes" are based upon which calculates fine, but not immediately. (In essence, I am totaling the values of a dbsum calculated field (much like one would use the value of an invoice subtotal), and then using that value (the middle expression below) in the 3'rd calculated value. It's the 3'rd value (in red) that is causing the problem. I am subtracting the correct array values (found in the array) from this total value and either it's <= 0, or it's > 0.... (The condition upon which the buttons' dynamic properties/attributes are set.) The second calculated value totals correctly without intervention. And does the third one. But you can't count on these values being "ready" (in time) for the dynamic object properties to properly evaluate/use the expression & condition (cn_Award1Distance >= 0 etc.) to assign the object's dynamic properties correctly all of the time. (That takes a function placed within the on_Timer event.) Again, if it weren't for the coloring issue, none of this would be necessary.

Code:

[COLOR="#0000FF"]cn_FobYearProgPoints[/COLOR] = dbsum("points_tbl","C_Kper__",alltrim(Keyfobs_tbl->Keyfob)+chr(47)+Var->vc_ProgramID+chr(47)+Var->vc_Year,"POINTS")
cn_CombinedFobYearlyProgPoints = total(calc->[COLOR="#0000FF"]cn_FobYearProgPoints[/COLOR],grp->customers_tbl,grp->keyfobs_tbl)
[COLOR="#FF0000"]cn_Award1Distance[/COLOR] = (calc->[COLOR="#0000FF"]cn_CombinedFobYearlyProgPoints[/COLOR]-session_variables(this.sessionhandle()).vp_ProgArray[vp_ProgArray.find(val(session_variables(this.sessionhandle()).vc_Year),"Ryear")].award1qual)

On a very interesting note: One of the browses has a button which opens up a modal form. This form also uses the same data (of the calling form) to dynamically assign attributes to fields and also buttons. I'm getting this data directly from the .text properties (fields on the calling form which display the values of the 3'rd calculated field.) ~ I use val(<object>.text) property having learned (while working within the original form) that using a the .value property of a form field derived from a calculated value (in some instances such as while while displaying dynamic data in a RTF object using the calculated value in the equation) results in a tremendous amount of overhead when all the calc. fields were being "re-calc'ed" unnecessarily. (It even broke the browse on large subtotals. ~ Made it act similar to when the parent only browse setting is not used on browse settings..... ghosting data in cells etc.) So apparently, the .value property causes a total "recalc" of calculated values at times, at least when you're working within the calling form itself/or when it has focus.) These FIELD totals are/were always right on both forms without needing the onTimer function running. So the ONLY purpose of the function is to enforce proper color coding...... Now back to my main point (sorry I got sidetracked): This modal form had full access to the correct calculated field values too, without ever needing the function running in the background. (When I disabled and/or set the onTimer event to run every 5 minutes, I could still open up this modal second form from the browse button and the object attributes were displayed correctly on the second form. And since these object attributes were based on the data in the underlying/calling form...... That's when I realized the function only was needed for dynamic attributes, and not for any of the field values. (And that it must either be a timing issue and/or field values are handled "internally" by the a5 engine far differently/with much greater attention) as object properties.

Anyways, without the "catch-up" function cleaning up the display "after the fact.": I'm left looking at two layouts both based on the exact same data from the exact same calculated values (all this data is only calculated once and then used again on a different layout (modal) via accessing object values (.text) and also session scope data from layout one via [x = session_variables(obj(vp_WindowSessionFocus.sc_RewardsMain_frmInstanceName).SESSIONHANDLE()).vc_Yearcalculated etc. on the second/modal layout screen]: And this second layout (modal) that opens up afterwards via form.viewqueried() is showing all the right data. (Another clue as to how dynamic object properties don't get the same treatment as actual field data.)

And that makes sense..... But there still should be some built in <Object>.Dynamic_Property_Reprocess() method to (re-assess) All I'd have to do is place this code where the other "refresh methods" are needed. ~ This gives me another idea. I wonder if I could write a function (not to run in the onTimer event) to check each object in a form, and look for a dynamic property attribute. (And if the object's "properties property" is set to dynamic..... I could try something like "<object>.dynamic.property = <object>.dynamic.property" or anything else to force a "re-draw?") Fortunately the "redraw overhead" is not sever running ever two seconds, because my "repaint function" first check to see if it is on "tab 2", and if not, it doesn't do anything else. (Actually I could also build a counter in, and make sure it stops "recalcing" (or maybe even set the onTimer form property itself to 0 after x amount of recalc.) ~ Just not the cleanest way.

**DaveM** · 02-08-2016, 01:32 AM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Robert,
Using scripts and functions - I sometimes use a script to call as many functions in order as necessary just to receive one value into a variable or field on a form/browse.
I have one script that runs 17 functions that need to be run in a certain order and returns 7 variables as answers that are shown on a form/browse.
The reason is that calculated fields in a form seemed to not always run in the order I needed and did not always wait for one to complete before another started.
V12 may work better, not sure. I started doing it this way back in v7.
I am pretty sure many others do this as well?

**SNusa** · 02-08-2016, 02:49 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Interesting Dave.... Is this how you would go about using your method in a child browse? (And is this even what you are suggesting? Otherwise I am confused.)

1.) Add an unbound field to the browse.
2.) Edit the "Display Format", so as to assign/display a global function as the value to display, similar to this (for my needs): [ dbsum_fnc(this:Keyfob.text,vc_year) ] right there when defining ?
Note: Without the usage of the calculated fields, passing "this:Keyfob.text" to the global function above would be necessary to pass the value of each browse record. (Which is required for calculating the summary on that record in the browse.)

I can't think of any other way to attach a function's value to a browse, or how one might otherwise get around using calculated values. This got me thinking about something else slightly related: When Alpha is displaying calculated values in a browse, does it ONLY query the totals/values on the visible records? (And does it query the rest as you scroll down past the visible ones on the screen? ~ If so, that certainly explains the Get_Viewport_Row() function.) And this would also make a lot of sense with regards to overhead concerns. (Similar in nature to the way alpha DAO accesses X amount of SQL records.) Which reminds me...

Browse navigation via code: I thought I had found a way to obtain the count of records being displayed in a browse (child table) via: vp_Browse.Fetch_last() followed by a vp_Browse.GetViewport_Row(). Turns out that this only returns the number of rows visible in the layout. I know that this number is also obtainable from COMPUTE_FIELD_STATISTICS(<browse>.<field>), but that returns a lot of extra statistical data/overhead. Maybe it's not possible, but I would think there would be some way of getting Just the total count. If so, I can't find it.

**DaveM** · 02-08-2016, 07:06 PM

Re: Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correc

Field in table
variable
run function to gat variable value - fill the field with the variable value and it displays wherever you want browse/ form/ report.
Passing values to your udf is same as passing to alpha function, just depends how you build the UDF
2016-02-08_1801.png

Announcement

The Alpha Software Forum Participation Guidelines

Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correctly.

Timing issue?: Field data OK, but other dynamic attributes (form objects) based on calc. fields not 100% displayed correctly.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment