Hot Topic (More than 10 Replies) First click doesn't always 'take' (Read 3778 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
 
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 #15 - Dec 18th, 2009 at 3:56pm
Print Post Print Post  
lksseven wrote on Dec 18th, 2009 at 3:29pm:
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.)  


We may need to see the entire app. You've got so much going on, it's hard to debug it piecemeal like this.

Quote:
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).

Those two lines were just an example. I see this all through your code. If you are doing a FormField Value or @FormFieldValue where the form name argument is "" and the instance argument is 0, then you are working with the record you are on anyway and don't need to go around the long way to get/set values. Just use the LE name.
  

- Hammer
The plural of anecdote is not data.
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 #16 - Dec 19th, 2009 at 2:07am
Print Post Print Post  
This reply is probaly too late, and not needed in light of what you are doing now....

But I missed this earlier question:
Quote:
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?


There are two commands possible:  ThrowFocus() and FormThrowFocus().  For what we were discussing, then I think the FormThrowFocus() command would be the better one.  I used "set focus" because I frequently work with other languages that have commands similar to Sesame.  I was actually thinking of the process, not the command.  Sorry for any confusion.
  



Bob Hansen
Sesame Database Manager Professional
Sensible Solutions Inc.
Salem, NH
603-898-8223
Skype ID = sensiblesolutions
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 #17 - Dec 19th, 2009 at 4:49am
Print Post Print Post  
Hi Bob,

ok, thanks for the followup.  I had used formthrowfocus to send focus to the subform in the logical sequence of field entry (navigational order of tabbing would send the cursor from field to field in a logic flow of input) ... but some of my users just can't get on that bandwagon.  They're mouse-crazy and just input something and click on wherever they want to go next.  In that case, throwfocus can get things wiggy, especially if a field entry has certain 'met criteria' that calls forth a @MsgBox ...

Hammer,  thanks for the instruction to just use the LE.  I will.
        Question:  When I click on a command button as my first contact with a subform, which code then fires first - the 'subform OnFormEntry' code, or the 'command button OnElementEntry' code? 

What I can't puzzle past, is regardless of what's going on with this or that, why does the music make a melody when XResultSet is commented out, but does not make a melody when XResultSet is active?

I can send you the app if you wish.  My fear is that my code will look like the Family Circus cartoon where Billy travels the equivalent of 3 blocks (climbing trees, crawling under cars, crossing the street, chasing a cat, playing catch) just to go next door and borrow a cup of sugar for his mom.
« Last Edit: Dec 19th, 2009 at 5:32pm by lksseven »  

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 #18 - Dec 19th, 2009 at 6:40pm
Print Post Print Post  
lksseven wrote on Dec 19th, 2009 at 4:49am:
Question:  When I click on a command button as my first contact with a subform, which code then fires first - the 'subform OnFormEntry' code, or the 'command button OnElementEntry' code?


My testing shows that the command button is the very last code to execute. The following is the order of execution when beginning with focus in the parent form, then clicking directly on a command button in the subform.

Code
Select All
This is an example of a subform with 3 elements in addition to the command button.

Form     : On Form Entry
Element1 : On Form Entry
Element2 : On Form Entry
Element3 : On Form Entry
Form     : On Element Change
Form     : On Form Change
Element1 : On Form Change
Element2 : On Form Change
Element3 : On Form Change
Form     : On Element Entry
Button1  : On Element Entry 



The stutter you see must be code that is executing in one of the events listed above the Button1 : On Element Entry event.
  


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 #19 - Dec 19th, 2009 at 8:36pm
Print Post Print Post  
Thanks for the 'clarify', Carl!  I'm printing that off and sticking it in my prog. manual.
  

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 #20 - Dec 19th, 2009 at 10:40pm
Print Post Print Post  
I also should explain (or clarify) that the On Element Change line was only in that list because I had some On Form Entry code that made a change to a 4th element, which was not really supposed be part of my test.
« Last Edit: Dec 22nd, 2009 at 2:26am by Carl Underwood »  


Carl Underwood
CDU Computer Consulting LLC
Epsom, New Hampshire
Back to top
IP Logged