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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

5 diff procedures of code while in a form. 1

Status
Not open for further replies.

PBSLinda

Programmer
Dec 13, 2000
6
US
PLEASE HELP, SECOND POSTING!!! I am under time constrants. I am trying to call 5 different peices of code from a form, depending on which totals need updated. Depending on the field updated 1-5 totaling can be called upon. Where do I store the diff pieces of code and how do I call them when needed. I had the code at form level., but got errors when adding new records because child records were not updated yet. The 3 tables are 1-M-M (QuoteMst, QuoteItem, QuoteItemDtl). Totals are held in a table. PLEASE SEE THREAD POSTED 12/5/00 FOR MORE DETAILS.
 
Linda,

I'm sorry, I'm still not getting it.

You said "I had the code at form level., but got errors when adding new records because child records were not updated yet."

By this, do you mean that the child records weren't posted yet? If so, have you tried adding code to the start of your calculation process that detects unposted record and then tries to post them? For example:

Code:
proc checkRecords( var uiTarget uiObject ) Logical
var
   loRetval  Logical
endVar

   loRetval = TRUE

   if uiTarget.Locked then
      loRetval = uiTarget.action( dataPostRecord )
      if loRetval then
         loRetval = uiTarget.action( dataUnlockRecord )
      endIf
   endIf

endProc

   if  checkRecords( QuiteItemDtl ) AND
      checkRecords( QuoteItem ) AND
      checkRecords( QuoteMst ) then
      doCalculations()
   endIf

Note the order; I did the interior one first and walked back up the (assumed) chain of containership.

Ideally, you should have one localized calculation routine that is triggered by each object or event that you need to keep your data up-to-date. this will vary from application to application and from design to design.

You may find it helpful to actually maintain six calculation routines, five that contain each individual pieces of code and one to control the conditions that each piece gets called.

Again, without more specific details...the text of the error messages at the very least, it's very difficult to guess.

Hope this helps...

-- Lance
 
Lance:
The six individual pieces of code (that you said is the ideal way to do the coding) is what I have been asking how to do. I don't know where to put the code or how to call it.
Linda
 
Linda,

Okay; let's back up. Based on the two threads and the email discussion, I confess that I do not yet possess enough information to hazard a good guess.

Also, I did not mean "ideal," I meant what appears to be a good design based on the information at my disposal. Remember, you're getting free advice based on an opinion perceived only on the information at hand.

Not only have I been known to be wrong, I confess that I am not clairvoyant. Also, my crystal ball has a small crack and my Tarot cards have not been kept in a cedar box.

Can you help me understand your form's current layout and when you would like the total to be updated. Also, an idea of the calculations involved and any relevant data events would be extremely helpful. I will try to offer good advice, but I'm just not getting a clear picture of the way things work on your form.

Sorry...

-- Lance
 
Thanks for sending the information privately. This is do-able, it just needs a little bit of set up.

Since you're using a multi-page form and want to call your recalculation code from any object on each of these pages, you're going to want to start by creatine custom methods on the form. Create one for each type of calculation.

That's the easy part. Now, we need to work out how best to call the code inside those custom methods. There are couple of things that will help. Let's review a few different tidbits about the way Paradox handles things and then we'll look at how we can use these to solve the overall problem.

First, the event model. Recall that Paradox first sends all events to the form object, regardless of the object that triggered the event. this lets you place code at the form level that is triggered by multiple objects.

For example, if you place code in the depart event of the form object, it will fire as focus moves from object to object. If you've placed code on in a built-in event of the form, you may have seen a construct like this:

Code:
  if eventInfo.isPreFilter() then
  
  else
  
  endIf

The IF portion of this is fires when Paradox is dispatching the event. You can use this to determine whether or not to take a global action, e.g. recalculate your totals, as follows:

Code:
  if eventInfo.isPreFilter() then
     active.postAction( userAction + 1 )  
  endIf

Active, as you probably know, is the object that has focus.

This places a request to trigger a custom action _after_ the current event has finished processing In this case, after focus has departed the active field. This will help you avoid running into problems with the refresh/recalc cycle.

To add code to this action, place the following in the action event of the form object:

Code:
  if eventInfo.isPreFilter() then
  
  else
  
     if eventInfo.id() = ( userAction + 1 ) then

        if subject.class() = "EditRegion" OR
           subject.class() = "Field" then
        
           switch
        
              case subject.TableName = "QuoteMst.DB"  : 
                 recalcMaster()
              case subject.TableName = "QuoteItem.DB" : 
                 recalcItem()
              case subject.TableName = "QuoteItmDtl.DB" : 
                 recalcDetail()
           
           endSwitch
           
        endIf
     endIf
  endIf

Subject may be new to you; it's the object that triggered this event, e.g. the one we sent the postAction to.

This lets you choose which custom method to call with the custom action is fired. You can also add in other flags and/or conditions.

Note that I verified that active was actually an unlabelled field object or the edit region of a labelled field object before calling the TableName property. This prevents the problems you might have if the object being departed was, say, a button or other non-data object.

Hope this helps...

-- Lance
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top