Page Index Toggle Pages: [1] 2  Send Topic Send Topic Print Print
Hot Topic (More than 10 Replies) First click doesn't always 'take' (Read 3783 times)
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
First click doesn't always 'take'
Jul 20th, 2009 at 10:42pm
Print Post Print Post  
Some of my command buttons in some of my forms don't consistently fire on the first click attempt.  Is this a Sesame issue, a Windows issue, or a 'Larry writing sluggish code' issue?

btw, I use 'just in time' compilation.
  

Larry
Back to top
IP Logged
 
Carl Underwood
Senior Member
Members
*****
Offline



Posts: 1351
Location: New Hampshire
Joined: Mar 11th, 2003
Re: First click doesn't always 'take'
Reply #1 - Jul 20th, 2009 at 10:58pm
Print Post Print Post  
Do you have subforms? (Based on some of your posts, I believe you do, right?) You may find that if focus is in the subform, and you click on a command button that is on the main form, you are actually moving focus to the main form with the first click. Then, the second click will activate the button.
  


Carl Underwood
CDU Computer Consulting LLC
Epsom, New Hampshire
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #2 - Jul 21st, 2009 at 3:06pm
Print Post Print Post  
ah!  That makes perfect sense.  Yes, I do have subforms.  I'll investigate that today.

Although I will mention that in my SOLines, I used to be able to tab onto a command button from another field in that same form, and then press the space bar to push the button.  But now it requires me to click the button with the mouse (on the first time.  After that I can use the space bar to press the button).   I know I changed something to cause that, but can't fathom what.
  

Larry
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #3 - Dec 14th, 2009 at 4:00am
Print Post Print Post  
still having a 'have to click some subform command buttons twice' when navigating from the parent form.  Is there a way around that?  In other words, if I retrieve a record in my Purchase Order parent form, and then next click on a command button in my POLines subform, is there a way to code it so that the first click of the subform command button 'takes'?  I've got a couple of users who just don't seem able to slow down enough to accommodate the stutter.  My subform command button code is :

PlaceLineItems::OnElementEntry

     If (@Mode() = 1)
       {

                 FormAttribute("Purch", "PurchPlaced", ATTR_ID_VISIBILITY, 1)
                 FormAttribute("Purch", "PurchSave", ATTR_ID_VISIBILITY, 0)
                 FormAttribute("Purch", "PurchReceived", ATTR_ID_VISIBILITY, 0)
                 FormAttribute("Purch", "PurchClosed", ATTR_ID_VISIBILITY, 0)

                 Visibility(QtyRecd0,0)
                 Visibility(QtyStillDue,0)
                 Visibility(DateRecd,0)
                       Visibility(PrintLabels,0)
                 Visibility(TotalRecd, 0)
                 Visibility(POLinesInvoiced,0)
                 Visibility(NextRecord,0)
                 Visibility(NextRecord0,0)
                 Visibility(NextRecord2,0)
                 Visibility(NextRecord20,0)
                 Visibility(NextRecord1,1)
                 Visibility(NextRecord10,1)
                 Visibility(AddNewLineItem,0)
                 Visibility(POLinesYN,1)
                 Visibility(ItemAvail,1)
                 Visibility(PI, 1)
                 Visibility(PrevDate, 1)
                 Visibility(QtyAvail, 1)
                 Visibility(QtyOnOrder, 1)

                    ReadOnly(POLInesYN, 0)
                    ReadOnly(ItemAvail, 0)
                          ReadOnly(PI, 0)

                          vMake = ""
                          vPI = "P"
                          vCount = @FormResultSetTotal("POLines")
                          vLoopP = 1
                          While vLoopP <= vCount
                           {
                      vPOLinesYN = @FormFieldValue("", "POLinesYN", vLoopP)
                      If vPOLinesYN <> "Y"
                              {
                                 FormFieldValue("", "Saved", vLoopP, vMake)
                           FormFieldValue("", "PI", vLoopP, vPI)
                        }
                            vLoopP = vLoopP + 1
                           }
                 ThrowFocus(ItemQty)

        }
« Last Edit: Dec 14th, 2009 at 5:11pm by Hammer »  

Larry
Back to top
IP Logged
 
Bob_Hansen
Senior Member
Members
*****
Offline


WOW, They have the Internet
on computers now!

Posts: 1861
Location: Salem, NH
Joined: Nov 24th, 2002
Re: First click doesn't always 'take'
Reply #4 - Dec 14th, 2009 at 5:04am
Print Post Print Post  
Moving between forms almost always results in two clicks, first one for focus, the next one for the action.  This has been an irritation from the very first beta version of Sesame.  After a while, you just learn to accept it. 

I think the only way to perform this in one click is to put a button on the form that currently has the focus.  That button would then be programmed to go to the other form, set the focus and perform the desired action.  You could make the target button action into a SubRoutine so that you could use it on multiple buttons.  But that whole process is just an involved workaround, and you would need to do that for every anticipated action on the sub form.

  



Bob Hansen
Sesame Database Manager Professional
Sensible Solutions Inc.
Salem, NH
603-898-8223
Skype ID = sensiblesolutions
Back to top
IP Logged
 
Acebanner
Full Member
***
Offline



Posts: 123
Location: New York City
Joined: Jan 23rd, 2008
Re: First click doesn't always 'take'
Reply #5 - Dec 14th, 2009 at 8:52pm
Print Post Print Post  
lksseven wrote on Jul 21st, 2009 at 3:06pm:
ah!  That makes perfect sense.  Yes, I do have subforms.  I'll investigate that today.

Although I will mention that in my SOLines, I used to be able to tab onto a command button from another field in that same form, and then press the space bar to push the button.  But now it requires me to click the button with the mouse (on the first time.  After that I can use the space bar to press the button).   I know I changed something to cause that, but can't fathom what.


Did you upgrade to Sesame 2.5 recently? Some of my forms seem to behave slightly different since I upgraded. I'm still looking at the form programming to be sure.
  
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #6 - Dec 14th, 2009 at 10:18pm
Print Post Print Post  
yes, I did upgrade to ver 2.5.

I'm glad to know it's not just my 'stumbling code' that's the culprit.

I've worked around it by creating a 'writeln' message when going from Parent to Child.  When the user clicks 'x' to erase the writeln message, that transfers focus to the child subform, so that the first click then 'takes'.

parent PONum:ShockednElementExit

If (@Mode() = 1)
  {
     SubformVisibility("POLines", 1)
     vPYN = @FormFieldValue("POLines", "POLinesYN", 0)
     If vPYN <> "Y"
       {
           writeln("close this window and")
           Writeln("click on the POLines function you wish to begin")
           FormThrowFocus("POLines", "Launchpad")
       }

     
  }
  

Larry
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #7 - Dec 15th, 2009 at 5:34am
Print Post Print Post  
Bob,

you said "That button would then be programmed to go to the other form, set the focus and perform the desired action."

Is there a command to 'setting the focus', or is that just a function of FormThrowFocus to the subform element before performing the desired action?
  

Larry
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #8 - Dec 16th, 2009 at 10:16pm
Print Post Print Post  
fwiw,

when I removed this code section from POLines:ShockednFormEntry, then I got rid of the stutter, and the first click on a command button in POLines 'takes'.

The three fields are all unbound number fields ....

     If (vPODate = @Date) and (vPOPlaced0 = "")

     {


// next section is for QtyAvail and QtyOnOrder

           vItemNum = @FormFieldValue("", "ItemNum", 0)
           vRS1 = @XResultSetSearch(@FN, "Inventory", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum)
           vTot = @XResultSetTotal(vRS1)

           vQtyAvail = @XResultSetValue(vRS1, "QtyAvail")
           vQtyOnOrder = @XResultSetValue(vRS1, "QtyOnOrder")
               FormFieldValue("", "QtyAvail", 0, vQtyAvail)
           FormFieldValue("", "QtyOnOrder", 0, vQtyOnOrder)
           XResultSetClose(vRS1)



// next section is for QtyOnBuild


           vItemNum = @FormFieldValue("", "ItemNum", 0)
           vPODate = @FormFieldValue("", "PODate", 0)
           //vPOYN = @FormFieldValue("", "POLinesYN", 0)
           //vDate = "PODate"


           vRS1 = @XResultSetSearch(@FN, "Purch!POLines", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum, "!PODate=" + @Date)
           vTot2 = @XResultSetTotal(vRS1)

           vDate = @XResultSetValue(vRS1, "PODate")
           vPOYN = @XResultSetValue(vRS1, "POLinesYN")
           vItemQty = @XResultSetValue(vRS1, "ItemQty")
                                                       
                       For vLoop = 1 to vTot2
                                       
                             XResultSetCurrentPosition(vRS1, vLoop)
                             vPOYN = @XResultSetValue(vRS1, "POLinesYN")
                             
                             If vPOYN <> ""
                               {
                                          XResultSetRemoveRecord(vRS1)
                                vLoop = vLoop - 1
                                vTot2 = vTot2 - 1                                
                                         }
                               Next

                       vLoop = 1                        
                       For vLoop = 1 to vTot2

                             XResultSetCurrentPosition(vRS1, vLoop)
                             vP = @XResultSetCurrentPosition(vRS1)

                             vItemQty = @XResultSetValue(vRS1, "ItemQty")

                             vQtyOnBuildTotal += @TN(vItemQty)

                       Next

           FormFieldValue("", "QtyOnBuild", 0, vQtyOnBuildTotal)
           XResultSetClose(vRS1)
               
         }
  

Larry
Back to top
IP Logged
 
Hammer
YaBB Administrator
Lanticans
*****
Offline


Fire bad. Tree pretty.

Posts: 3436
Location: Ohio
Joined: Nov 22nd, 2002
Re: First click doesn't always 'take'
Reply #9 - Dec 17th, 2009 at 2:28am
Print Post Print Post  
FormFieldValue and @FormFieldValue can push focus to a different form, yes.
  

- Hammer
The plural of anecdote is not data.
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #10 - Dec 17th, 2009 at 7:44pm
Print Post Print Post  
Hi Hammer,

I commented out the XResultSet code in my OnFormEntry programming, and substituted
vPrac = @FormFieldValue("", "ItemQty", 0)
FormFieldValue("", "QtyOnBuild", 0, vPrac)

so that I was still executing a FormFieldValue.   The programming worked great, with no stutter or 2nd click required.   

It seems from my testing that the XResultSet programming, OnFormEntry anyway, is the cause of the stutter or loss of focus, so that the first click of the command button is required to regain focus, and then the second click of that button actually executes the programming.

I would mention, too, that when the XResultSet programming is in place, when I click the command button the first time, the status bar on Sesame runs through its quick 'search' scroll, but the guts of the code doesn't 'take'
  

Larry
Back to top
IP Logged
 
Hammer
YaBB Administrator
Lanticans
*****
Offline


Fire bad. Tree pretty.

Posts: 3436
Location: Ohio
Joined: Nov 22nd, 2002
Re: First click doesn't always 'take'
Reply #11 - Dec 17th, 2009 at 8:01pm
Print Post Print Post  
lksseven wrote on Dec 17th, 2009 at 7:44pm:
I would mention, too, that when the XResultSet programming is in place, when I click the command button the first time, the status bar on Sesame runs through its quick 'search' scroll, but the guts of the code doesn't 'take'


I'm not sure what that ^^^ means.

XResultSet by itself is an unlikely culprit. There is a whole bunch going on and then focus eventually lands someplace other than where you want it at that moment. To be more specific than that, you need to dig in more. You got the behavior to stop by commenting out a chunk of your code. Put it back in and start removing smaller bits within that chunk. See if you can narrow down which part of the routine is causing the focus to stick.
  

- Hammer
The plural of anecdote is not data.
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #12 - Dec 17th, 2009 at 11:19pm
Print Post Print Post  
Hammer,

I tested the programming 3 different times, with the following program iterations.  I made 3 different shapshots of my POLines:ShockednFormEntry programming, and present it below.  Snapshot 1 works (meaning that the command button PlaceLineItems executes all of its code on the first click;   with FormFieldValue plugging value in QtyOnBuild field, and with XResultSet commands commented out).  Snapshots 2 and 3 do not work (meaning that the programming in 2 and 3 - with XResultSet code active - causes the command button PlaceLineItems to not execute all of its code upon clicking it, requiring a second click).

When I say that the programming 'didn't work when XResultSet was active', I mean that the XResultSet code did do what it was supposed to do, but an unwanted byproduct seems to be that it is then causing a followup command button to require 2 clicks instead of 1 click.

This would seem to eliminate FormFieldValue as the focus pothole, and seems to indicate XResultSet as the cause of the stutter (at least in this specific instance), wouldn't it?  Certainly not trying to argue, just trying to understand.

Snapshot 1 (worked):
var vItemNum as string
var vRS1 as int

var vQtyAvail as string
var vQtyOnOrder as string
var vItemQty as int
var vTot as int
var vDate as date
var vQtyOnBuildTotal as int
var vLoop as int
var vTot2 as int
var vPOYN as string
var vPOYN2 as string
var vPODate as date
var vP as int

var vPrac as int


vPODate = @FormFieldValue("POLines", "PODate", 0)
vPOYN2 = @FormFieldValue("POLines", "POLinesYN", 0)


If (@Mode() = 0)
     {
                 
           Visibility(POLinesInvoiced, 0)
           Visibility(NextRecord2, 0)
           Visibility(QtyRecd0, 0)
           Visibility(QtyStillDue, 0)
           Visibility(TotalRecd, 0)
           Visibility(DateRecd, 0)
               Visibility(PrintLabels,0)
           Visibility(NextRecord,0)
           Visibility(NextRecord0,0)
           Visibility(NextRecord20,0)
           ReadOnly(POLinesYN, 2)
           ReadOnly(ItemAvail, 2)
           Visibility(AddNewItem,1)
           Visibility(PlaceLineItems, 1)
           Visibility(ReceiveItems, 1)
           Visibility(Invoiced?, 1)
               Visibility(Record, 1)
               Visibility(Records, 1)
               Visibility(Saved, 1)
           Visibility(PrevPO, 1)
           Visibility(PrevDate, 1)
           Visibility(ClearAll, 1)
           Visibility(QtyAvail, 1)
           Visibility(QtyOnOrder, 1)
           Visibility(QtyOnBuild, 1)
               Record = @FormResultSetCurrentPosition("POLines")
             Records = @FormResultSettotal("POLines")
               If @TN(Record) > @TN(Records)
                 {
                     Records = Record
                 }
                 
     }

If (@mode() = 1)

     {
           Visibility(PrevPO, 1)
           Visibility(QtyAvail, 1)
           Visibility(QtyOnOrder, 1)
           Visibility(QtyOnBuild, 1)
                                       
           If @Visibility(QtyRecd0) = 0
                 {
                       Visibility(NextRecord, 0)
                       Visibility(NextRecord0, 0)
                               Visibility(PrintLabels, 0)
                 } else
                       {
                             Visibility(NextRecord, 1)
                             Visibility(NextRecord0, 1)
                                              Visibility(PrintLabels, 1)
                       }
                       
           If @Visibility(POLinesInvoiced) = 0
                 {
                       Visibility(NextRecord2, 0)
                       Visibility(NextRecord20, 0)
                 } else
                       {
                         Visibility(NextRecord2, 1)
                         Visibility(NextRecord20, 1)
                       }

           If @Visibility(POLinesYN) = 0
                 {
                       Visibility(NextRecord1, 1)
                       Visibility(NextRecord10, 1)
                 } else
                       {
                         Visibility(NextRecord1, 1)
                         Visibility(NextRecord10, 1)
                       }


           If @FormAttribute("Purch", "PurchSave", ATTR_ID_VISIBILITY) = 1
                       {
                               Visibility(AddNewLineItem, 1)
                       
                 }
           
           If @FormAttribute("Purch", "PurchPlaced", ATTR_ID_VISIBILITY) = 1
                 {
                             ReadOnly(POLInesYN, 0)
                       Visibility(AddNewLineItem, 0)
                       ReadOnly(ItemAvail, 0)
                   }
                    Else
                       {
                         ReadOnly(POLinesYN, 1)
                         ReadOnly(PI, 1)
                       }

           If @FormAttribute("Purch", "PurchClosed", ATTR_ID_VISIBILITY) = 1
                 {
                             ReadOnly(POLinesInvoiced, 0)
                       
                 }
                    Else
                       {
                         ReadOnly(POLinesInvoiced, 1)
                         
                       }
                 
           If @FormAttribute("Purch", "PurchReceived", ATTR_ID_VISIBILITY) = 1
                   {
                             ReadOnly(QtyRecd0, 0)
                       
                 }
                    Else
                       {
                         ReadOnly(QtyRecd0, 1)
                         
                       }

     }
                                               
                       
     //  The below code is seems to be what causes the stutter.  If it's left out, no stutter, if the first section A is activated, no stutter.  
     //  If section A is commented out, and Section B is activated, then there is a stutter when PlaceLineItems command button is pressed.


If (@Mode() = 1) and (vPODate = @Date) and (vPOYN2 = "")
 {

       // the below Section A's two lines works without a stutter

vPrac = @FormFieldValue("", "ItemQty", 0)
FormFieldValue("", "QtyOnBuild", 0, vPrac)

 }


/*
           //  the below Section B seems to cause stutter when activated

           // next section is for QtyAvail and QtyOnOrder

     vItemNum = @FormFieldValue("", "ItemNum", 0)
     vRS1 = @XResultSetSearch(@FN, "Inventory", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum)
     vTot = @XResultSetTotal(vRS1)

     vQtyAvail = @XResultSetValue(vRS1, "QtyAvail")
     vQtyOnOrder = @XResultSetValue(vRS1, "QtyOnOrder")
       FormFieldValue("", "QtyAvail", 0, vQtyAvail)
     FormFieldValue("", "QtyOnOrder", 0, vQtyOnOrder)
     XResultSetClose(vRS1)


           // next section is for QtyOnBuild


     vItemNum = @FormFieldValue("", "ItemNum", 0)
     vPODate = @FormFieldValue("", "PODate", 0)
     //vPOYN = @FormFieldValue("", "POLinesYN", 0)
     //vDate = "PODate"

     vRS1 = @XResultSetSearch(@FN, "Purch!POLines", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum, "!PODate=" + @Date)
     vTot2 = @XResultSetTotal(vRS1)

     vDate = @XResultSetValue(vRS1, "PODate")
     vPOYN = @XResultSetValue(vRS1, "POLinesYN")
     vItemQty = @XResultSetValue(vRS1, "ItemQty")
                                                       
     For vLoop = 1 to vTot2
                                       
           XResultSetCurrentPosition(vRS1, vLoop)
           vPOYN = @XResultSetValue(vRS1, "POLinesYN")
                             
           If vPOYN <> ""
             {
                     XResultSetRemoveRecord(vRS1)
                 vLoop = vLoop - 1
                 vTot2 = vTot2 - 1                                
                 }
       Next

           vLoop = 1                        
           For vLoop = 1 to vTot2

                 XResultSetCurrentPosition(vRS1, vLoop)
                 vP = @XResultSetCurrentPosition(vRS1)

                 vItemQty = @XResultSetValue(vRS1, "ItemQty")

                 vQtyOnBuildTotal += @TN(vItemQty)

           Next

           FormFieldValue("", "QtyOnBuild", 0, vQtyOnBuildTotal)
           XResultSetClose(vRS1)


 }
*/

Snapshot 2 (first section of XResultSet active .. didn't work) ... I only pasted the last section of the programming that I altered for the test:

     //  The below code is seems to be what causes the stutter.  If it's left out, no stutter, if the first section A is activated, no stutter.  
     //  If section A is commented out, and Section B is activated, then there is a stutter when PlaceLineItems command button is pressed.


If (@Mode() = 1) and (vPODate = @Date) and (vPOYN2 = "")
 {

       // the below Section A's two lines works without a stutter

//vPrac = @FormFieldValue("", "ItemQty", 0)
//FormFieldValue("", "QtyOnBuild", 0, vPrac)
//}



           //  the below Section B seems to cause stutter when activated

           // next section is for QtyAvail and QtyOnOrder

     vItemNum = @FormFieldValue("", "ItemNum", 0)
     vRS1 = @XResultSetSearch(@FN, "Inventory", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum)
     vTot = @XResultSetTotal(vRS1)

     vQtyAvail = @XResultSetValue(vRS1, "QtyAvail")
     vQtyOnOrder = @XResultSetValue(vRS1, "QtyOnOrder")
       FormFieldValue("", "QtyAvail", 0, vQtyAvail)
     FormFieldValue("", "QtyOnOrder", 0, vQtyOnOrder)
     XResultSetClose(vRS1)


/*
           // next section is for QtyOnBuild


     vItemNum = @FormFieldValue("", "ItemNum", 0)
     vPODate = @FormFieldValue("", "PODate", 0)
     //vPOYN = @FormFieldValue("", "POLinesYN", 0)
     //vDate = "PODate"

     vRS1 = @XResultSetSearch(@FN, "Purch!POLines", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum, "!PODate=" + @Date)
     vTot2 = @XResultSetTotal(vRS1)

     vDate = @XResultSetValue(vRS1, "PODate")
     vPOYN = @XResultSetValue(vRS1, "POLinesYN")
     vItemQty = @XResultSetValue(vRS1, "ItemQty")
                                                       
     For vLoop = 1 to vTot2
                                       
           XResultSetCurrentPosition(vRS1, vLoop)
           vPOYN = @XResultSetValue(vRS1, "POLinesYN")
                             
           If vPOYN <> ""
             {
                     XResultSetRemoveRecord(vRS1)
                 vLoop = vLoop - 1
                 vTot2 = vTot2 - 1                                
                 }
       Next

           vLoop = 1                        
           For vLoop = 1 to vTot2

                 XResultSetCurrentPosition(vRS1, vLoop)
                 vP = @XResultSetCurrentPosition(vRS1)

                 vItemQty = @XResultSetValue(vRS1, "ItemQty")

                 vQtyOnBuildTotal += @TN(vItemQty)

           Next

           FormFieldValue("", "QtyOnBuild", 0, vQtyOnBuildTotal)
           XResultSetClose(vRS1)
*/

 }

Snapshot 3 ((second section of XResultSet active .. didn't work) ... I only pasted the last section of the programming that I altered for the test:

     //  The below code is seems to be what causes the stutter.  If it's left out, no stutter, if the first section A is activated, no stutter.  
     //  If section A is commented out, and Section B is activated, then there is a stutter when PlaceLineItems command button is pressed.


If (@Mode() = 1) and (vPODate = @Date) and (vPOYN2 = "")
 {

       // the below Section A's two lines works without a stutter

//vPrac = @FormFieldValue("", "ItemQty", 0)
//FormFieldValue("", "QtyOnBuild", 0, vPrac)
//}


/*
           //  the below Section B seems to cause stutter when activated

           // next section is for QtyAvail and QtyOnOrder

     vItemNum = @FormFieldValue("", "ItemNum", 0)
     vRS1 = @XResultSetSearch(@FN, "Inventory", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum)
     vTot = @XResultSetTotal(vRS1)

     vQtyAvail = @XResultSetValue(vRS1, "QtyAvail")
     vQtyOnOrder = @XResultSetValue(vRS1, "QtyOnOrder")
       FormFieldValue("", "QtyAvail", 0, vQtyAvail)
     FormFieldValue("", "QtyOnOrder", 0, vQtyOnOrder)
     XResultSetClose(vRS1)
*/

           // next section is for QtyOnBuild


     vItemNum = @FormFieldValue("", "ItemNum", 0)
     vPODate = @FormFieldValue("", "PODate", 0)
     //vPOYN = @FormFieldValue("", "POLinesYN", 0)
     //vDate = "PODate"

     vRS1 = @XResultSetSearch(@FN, "Purch!POLines", SEARCH_MODE_AND,SEARCH_SYNTAX_QA, "!ItemNum=" + vItemNum, "!PODate=" + @Date)
     vTot2 = @XResultSetTotal(vRS1)

     vDate = @XResultSetValue(vRS1, "PODate")
     vPOYN = @XResultSetValue(vRS1, "POLinesYN")
     vItemQty = @XResultSetValue(vRS1, "ItemQty")
                                                       
     For vLoop = 1 to vTot2
                                       
           XResultSetCurrentPosition(vRS1, vLoop)
           vPOYN = @XResultSetValue(vRS1, "POLinesYN")
                             
           If vPOYN <> ""
             {
                     XResultSetRemoveRecord(vRS1)
                 vLoop = vLoop - 1
                 vTot2 = vTot2 - 1                                
                 }
       Next

           vLoop = 1                        
           For vLoop = 1 to vTot2

                 XResultSetCurrentPosition(vRS1, vLoop)
                 vP = @XResultSetCurrentPosition(vRS1)

                 vItemQty = @XResultSetValue(vRS1, "ItemQty")

                 vQtyOnBuildTotal += @TN(vItemQty)

           Next

           FormFieldValue("", "QtyOnBuild", 0, vQtyOnBuildTotal)
           XResultSetClose(vRS1)


 }

  

Larry
Back to top
IP Logged
 
Hammer
YaBB Administrator
Lanticans
*****
Offline


Fire bad. Tree pretty.

Posts: 3436
Location: Ohio
Joined: Nov 22nd, 2002
Re: First click doesn't always 'take'
Reply #13 - Dec 18th, 2009 at 2:38pm
Print Post Print Post  
Let's work with Snapshot 2 since that has the smallest amount of code uncommented, but still causes the issue.

That small block still has both XResultSet and FormFieldValue running. Comment out only the XResultSet lines and see what happens. Put them back in and comment out only the FormFieldValue lines. See what happens.

BTW, I'm not sure why you are using the FormFieldValue family to get and set values from the record you are currently on. Instead of:
vPrac = @FormFieldValue("", "ItemQty", 0)
FormFieldValue("", "QtyOnBuild", 0, vPrac)

...you can just do the following, no?
vPrac = ItemQty
QtyOnBuild = vPrac

Or even just:
QtyOnBuild = ItemQty

Using FormFieldValue to work with the current form and record is making us do a lot of work to get to where you already are.  Smiley
  

- Hammer
The plural of anecdote is not data.
Back to top
IP Logged
 
lksseven
Full Member
***
Offline



Posts: 416
Location: Southwest
Joined: Jan 26th, 2009
Re: First click doesn't always 'take'
Reply #14 - Dec 18th, 2009 at 3:29pm
Print Post Print Post  
I will test per your instructions.  (update:  tested - same results.  no stutter with Snapshot 1 FormFieldValue code (also no stutter with all three snapshots commented out.   Snapshot 2 produces the stutter.   The stutter doesn't happen until the user proceeds to click into the subform on the PlaceLineItems command button for the first time.   Could somehow the code from this button not like the XResultSet code in the OnFormEntry ?   I will post that code if you want to see it.)  

I only have the two @FormFieldValue and FormFieldValue lines in there to test this stutter (or to eliminate @FormFieldValue and FormFieldValue by themselves as causing the stutter).

The stutter only happens on the first entry to the POLines subform and only happens when this XResultSet code is active (I use XResultSet throughout my programming - I love it, thank you, thank you, thank you).   And I also comment that the stutter only happens if clicking for the first time into the subform with the mouse.  If 'tabbing' into the subform from the parent form, then the stutter does not happen.    

The intent of the XResultSet code in this instance is:   a built-but-not-yet-called-in Purchase Order might be retrieved and added to throughout the day, as sales orders are generated.  Upon form entry of each PO line record, XResult is finding the real time Quantity Avail (on the shelf, not spoken for), QuantityOnOrder (items previously ordered on a PO but not received yet), and QuantityOnBuild (items placed on current PO's that have not been placed with the vendor yet) - info to help the PO placer make final judgments about quantity sizes.

  

Larry
Back to top
IP Logged
 
Page Index Toggle Pages: [1] 2 
Send Topic Send Topic Print Print