Regarding one specific page on one of my websites...
A form on the page submits memvars via the onClick event of an input 
type=button.  The form declaration line has onsubmit="return false". The 
function referenced by WAA_FORM appends a record in a dbf and stores the 
values.  Very straight forward.

One workstation at one client site has a curious behavior.  The new record 
is often created in multiples, two or three records.  The WAA log shows the 
storing function executing multiple times in sequence.  The IIS system log 
shows this multiple traffic (these submittals) arriving 6-8 seconds apart. 
But not every time the client uses the specific workstation.  Moreover, the 
behavior has appeared on only this page, which has a textarea input.

I think the client needs to do something, but i don't know what.  Any 
guesses are appreciated.

Bruce,
easy: your client is double-clicking your button 
There are people not really knowing when to do double- and when to do 
single-clicks - so to be sure they are always double-clicking almost 
everything 

Regards,
Martin

Martin,

> easy: your client is double-clicking your button 
> There are people not really knowing when to do double- and when to do 
> single-clicks - so to be sure they are always double-clicking almost 
> everything 

We had exactly the same problem here.  The solution is elegant, albeit a
little strange.  Add a new hidden input var to your form which contains a
unique id.

   FORM START name=MyForm, action="javascript:return false;"
      HIDE uid=(UniqueFormID())
      BUTTON 'Click Me' onClick="document.MyForm.submit();"
   EndForm

Function UniqueFormID()
   local cRet := dtos( Date() )

   cRet += StrTran( Time(), ':', '' )
   cRet += StrZero( ThreadId(), 4 )
   return cRet

When the form is returned, in the recieving function check a database table
to see if the uid is already known.  If it is, reject the request else add
the uid to the database and process the data as usual.  As part of the your
hosekeeping processes, you can get rid of 'old' records, or you can use the
table in a more meaningful way to store additional info:

  Fields      Purpose
  uid         record whether a form has already been submitted
  date        date form returned
  time        time form return (now you can calculate the time it
              takes the user to fill in and submit a form)

Regards,
          

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Drive A: not responding.. .Formating C: instead

I agree "something" is making multiple submits, but I don't think it is a 
clumsy click problem.  According to the system log, the duplicate requests 
are hitting my server at least 5 seconds apart.

Nonetheless, the solution might have to come from my end.  Taking this 
approach of looking for duplicate requests, I see a lot of overhead in 
opening and closing the verification table for each relevant submittal.  Is 
there a way to open this table in one thread and keep it open to service all 
matching tests?  This will mean a function in one thread will have to pass 
parameters to a function running in a different thread, and will get a 
return GO/NOGO value from that function.

Bruce,

> I agree "something" is making multiple submits, but I don't think it is a 
> clumsy click problem.  According to the system log, the duplicate requests 
> are hitting my server at least 5 seconds apart.
> 
> Nonetheless, the solution might have to come from my end.  Taking this 
> approach of looking for duplicate requests, I see a lot of overhead in 
> opening and closing the verification table for each relevant submittal.  Is 
> there a way to open this table in one thread and keep it open to service all 
> matching tests?  This will mean a function in one thread will have to pass 
> parameters to a function running in a different thread, and will get a 
> return GO/NOGO value from that function.

There are three ways to do this without re-opening the table every time.

1.  In each thread, check if it is open and if not open it.  Don't close it
and it should be available next time this thread is re-used.

2.  Open the table on startup and send it to z-space.  When you need it,
just request it, do whatever then send it back again.

3.  Provide a class which handles the table, and pass a reference to the
object to each thread.  Here's a cheap and convenient way of accessing an
object from any thread:

FUNCTION MyGlobalObj( o )
   STATIC oObj

   if ValType(o) == 'O'
      oObj := o
   endif
   return oObj

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

SO WHO NAMED YOU "TASTE POLICE" ANYWAY?

What is z-space?

Bruce,

> What is z-space?

Well, according to Terry Pratchett...no, let's not go there .

Z-Space = Zero Space.

Each thread has a workspace which can handle 65000 workareas.  You can pass
a workarea between threads (workspaces) by sending the workarea to the zero
space.  Think of each workspace being numbered according to the threadid of
the thread it is in.

When you send a workarea to the zero space, no thread has direct access to
it, but can request the workarea from the z-space:

 DbRelease()
 Transfers an alias name from the current work space into the Zero space. 

DbRelease( [<nWorkArea>|<cAlias>], [<bAreaBlock>] ) --> lSuccess 

 DbRequest()
 Transfers an alias name from the Zero space into the current work space. 

DbRequest( [<cAlias>], [<lFreeArea>], ; 
           [<@bAreaBlock>], [<lWait>] ) --> lSuccess 

Using this method, you can open a file once and access it from any thread.
However, only one thread can access the file at a time.

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Meddle not in the affairs of wizards, for <>...ribbit.

Bruce,
if there is such a long delay between the two requests you might want to ask 
your customer to check the NIC on that particular PC!
Maybe the response time is so bad that the customer is clicking the button a 
second time?

Regards,
Martin

We have tested this while on the phone together with no double clicking, 
frustrating second clicking, etc.

 I think your suggestion of a flaky NIC is probably the best thing to 
pursue.  Because this is in his Sony Notebook, I can put the blame on it and 
he will have virtually no way to verify.  Perfect solution from my 
standpoint.

Bruce,

"Bruce Anderson" <banderson@graphical-db.com> schrieb im Newsbeitrag 
news:v%23yh6c56FHA.5608@S15147418...
> Because this is in his Sony Notebook, I can put the blame on it and he 
> will have virtually no way to verify.  Perfect solution from my 
> standpoint.

I do like this sentence! There is a Dogbert in all of us  - more or less 

Regards,
Martin

Martin Altmann wrote:

> There are people not really knowing when to do double- and when to do 
> single-clicks 

I can understand this - how would you explain it to a user not who does not
know the technical details?

To a user, there is no difference between a toolbar icon and an icon in a
windows explorer window or on the desktop - they are both symbols for
something - but the first one reacts to a single klick, the second one (at
standard configuration) to a double klick... so how should the user know or
be able to differentiate between those two options?

This gets even tougher for "coooool" interfaces like the Quicktime player
has, where you have graphical elements that look the same like other
controls (the apple sign), but are no controls...

Thomas