"1/10 second" rule

[Cliff Nichols]

Just for not hijacking another thread, I thought I would ask just exactly what is the "1/10 second rule"?

In my mind, its application specific, and faster than a human will react because they think something is "Locked-Up" because it takes longer than the user would think. So it keeps "Display" vs "Actual Work" on a happy balance

Just to ask, if its something we come about with time? (I usually adhere to this rule myself, or display something to show not locked up), or is there an actual "Coined rule"???

Only reason I ask, is cause an incident at the gas pump, and wonder "Why 9/10ths of a cent??" till I learned the meaning of milles sorta thing

(amazing what you learn from the past)

[John Petty]

Cliff
I think it is also user specific, some classes of users will very quickly start clicking buttons because the think something is wrong, on the other hand I have programs for myself that will "white screen" for 5 to 10 minutes but then as the programs run for days and I know why its not a problem.
The only reason I can think of for the selection of 1/10th second is that it is approximately the length of a time slice and so if the computer is very busy with many jobs then the actual period of the "white screen" could be somewhat longer.
John

[Michael Mattias]

If Mr. Petzold says its a rule, it's a rule.

See recent thread from Mr. Doty.... users were clicking on a button a second (third? fourth?) time because the program did not react - or least they did not SEE a reaction - quickly enough for them to believe they actually clicked the button the first time. The extra 'clicks' got queued up and - as they should have - were processed again when the program finished whatever it was doing "on click" and was once again ready to process user-generated notifications.

I think it is also user specific, some classes of users will very quickly start clicking buttons because the think something is wrong

In my experience there is only ONE class of users who do this: All of them.


MCM

[Erich Schulman]

I have often seen warnings "Do not click SUBMIT again or your credit card may be charged twice". Perhaps enough times of seeing that warning -- or dealing with the consequences of ignoring it -- will help start getting users accustomed to not decuple-click. Shutting down properly is now an accepted practice, though it once seemed strange.

[Joseph Cote]

I can't even guess the percentage split, but I'd say a good number of those who keep clicking, or hitting Return don't think the program didn't notice, but are merely impatient and taking it out on the thing they already have their fingers or mouse on.

We have a big ongoing project at work to chage over from a CICS based environment to a web based one. Whatever else folks might think of IBM, they've done a pretty good job at making CICS (and COBOL and DB2) work well together, and work fast. The users were used to nearly instant response from CICS. They were not so happy with waiting 2-4 seconds for the web version of the same application, and ofen mentioned that on the satisfaction surveys. We ended up writing a pass-though step on the server that popped up a screen that said, more or less, "Processing. Thank you for your patience" depending on the function requested, and then went on with the real processing. This cut the slowness complaints by more than 2/3rds. (The other 1/3rd were mostly folks who we knew were determined to be unhappy with the New Thing.)

Lesson learned: acknowledge the user command as quickly as possible, and let them know if they might have to wait more than a few seconds.

Seems obvious enough, and yet a lot of good applications leave you hanging for a while.

[John Petty]

If Mr. Petzold says its a rule, it's a rule.

See recent thread from Mr. Doty.... users were clicking on a button a second (third? fourth?) time because the program did not react - or least they did not SEE a reaction - quickly enough for them to believe they actually clicked the button the first time. The extra 'clicks' got queued up and - as they should have - were processed again when the program finished whatever it was doing "on click" and was once again ready to process user-generated notifications. MCM

You can't be serious, surely there aren't programmers who as a first action on the click of an important button don't disable the button.

[Mike Doty]

It is possible to double click on a disabled button and the clicks are queued.
Solution was to execute some DOEVENTS and down the road put into a separate thread.
On my test system FOR X = 1 to 4: DOEVENTS:NEXT fixed it.
I thought this was impossible, but was able to duplicate it.

[John Petty]

We have a big ongoing project at work to chage over from a CICS based environment to a web based one.

I wish your company luck.
Just over 2 years ago a company I had consulted to many years earlier begged me to come back (first parting was a little less than friendly but as I respected the person who asked I did) to advise on a new package basically to run the company (they had run my previous recommedation happily for a number of years but outgrown it).
They had just been bought by a major public company and the responsible director suggested looking at a well known Web Package which I did along with many other packages. My recommendation, an in house running package, the director disagreed (hey I got well paid so what) and put in the Web based.
One year later they asked me back, wrote off a $250,000 cost of the web based package and paid me again (much less I have ethics) to confirm my original recommendation which they are now very happy with.
Why not Web Based? Apart from the obvious of speed everything is displayed by a web browser. Which one? Which version? Very hard for a programmer to control where the window is displayed, its size (given different screen resolutions) controlling focus etc etc that are usual in normal windows programming are extremely difficult in applications that use web browsers.
For very good reasons (for their future profits) MS, Google etc say this is the way of the future, it may be but my experience is not yet.

[John Petty]

It is possible to double click on a disabled button and the clicks are queued.

Thanks Mike I didn't know that. Being an old fashioned "belt and braces man" I normally for important code put in a Static busy or in use flag as well so havn't seen it (didn't say that earlier, thought people would laugh)

[Michael Mattias]

Hence, on click...

- disable
- start thread function
- re-enable on completion of thread function

.... makes sense, after all?

However, I think the 'problem' here was with how "DDT" implements CONTROL DISABLE... if it requires a DIALOG DOEVENTS (posts WM_ENABLE), then that's why Mike's code did not effect the disable. If it does a SEND of WM_ENABLE the effect should be immediate. But CONTROL DISABLE is proprietary so we don't know how it's done.

FWIW, from SDK doc: EnableWindow() API sends WM_CANCELMODE followed by WM_ENABLE.

MCM

[Joseph Cote]

One year later they asked me back, wrote off a $250,000 cost of the web based package and paid me again (much less I have ethics) to confirm my original recommendation which they are now very happy with.
Why not Web Based? Apart from the obvious of speed everything is displayed by a web browser. Which one? Which version? Very hard for a programmer to control where the window is displayed, its size (given different screen resolutions) controlling focus etc etc that are usual in normal windows programming are extremely difficult in applications that use web browsers.
For very good reasons (for their future profits) MS, Google etc say this is the way of the future, it may be but my experience is not yet.

Since this is an entirely home-grown project, we're not dealing with anybody else's framework. And since the desktop is dictated by our IT standards folks, we know that *everybody* is running IE6 on XPPro/SP2 etc. It does work pretty well, and we're about 80-90% done with the conversion (after eight years...) so I'd say this one has worked out. The users get way more info per screen than the 80-by-24 CICS pages. Navigation is a lot easier for them. And we've automated a lot of things that had been done via mainframe batch before. (Example: a specific legal document would need to be created. old way was special letterhead on the mainframe printer. New way, web app creates a PDF file that can be printed on a local laserprinter and mailed off right away. Or a new thing we're trying, e-mailing the doc to the client right from the web app.)

[Cliff Nichols]

WOW did I spurn a new one.

All in all the original question inadvertently answered the original question. "Why 1/10th of a second"???

Answer is: "Application Specific"

and why??

1. Faster than a human can normally "Double-Click"
2. If a "Double-Click" then code can account for it
3. Allow or Dis-Allow according to you specific needs
4. Users that can click faster than that...ummm REALLLLY need to step away from the

All in all, users are like kids on crack-phones...instant gratification, or something is wrong.

Display is EVERYTHING but strategically placed, shows the end user what they want (although slows things down unless strategically threaded), but the user will NEVER know (unless you can blink faster than that

[Dominic Mitchell]

FOR X = 1 to 4: DOEVENTS:NEXT

That is like using a sledgehammer on the message queue.
SDK programming provides mechanisms to remove a specific message or range of messages from the queue.
For example, to remove all mouse messages, use code similar to the following:

  WHILE PeekMessage(tmsg, hWnd, %WM_MOUSEFIRST, %WM_MOUSELAST, %PM_REMOVE)
  WEND

[Michael Mattias]

... exactly what is the "1/10 second rule"? ... is there an actual "Coined rule"???

From "Programming Windows 95" by Charles Petzold, chapter 14

The first attempt by Microsoft ... to implement multitasking in a quasi-DOS/Windows enviroment was OS/2 and the Presentation Manager (PM)......

..Thus PM programmers learned how to divide their programs into one message-queue thread that created all windows processed messages to them, and one or more non-message-queue threads that performed lengthy background tasks. PM programmers also learned about the "1/10 second rule." Basically, they were advised that a message-queue thread spend no more than 1/10 second processing any message. Anything that takes longer should be done in a different thread. If all programmers followed this rule, no PM program could hang the system for more than 1/10 second."

[ new section, "The Windows Advantage"]

... I mentioned earlier the "1/10 second rule." Well, loading a large file into memory may take longer than 1/10 second. Does this mean that file-loading routines should be implemented in separate threads? Not Necessarily. When a user commands a program to open a file, he or she usually wants that operation carried out immediately. Putting the file-loading routines in a separate thread simply adds overhead. It's just not worth it, even if you want to boast to your friends you write multithreaded programs!

Three points..

1. Mr. Petzold nowhere discusses "who" came up with the 1/10 second figure or "when" they did so. (Not that I can find, anyway).

2. I am somewhat surprised he doesn't mention (not that I can find, anyway), the "white empty screen" phenomenon which occurs when a window procedure is busy processing a message and the window needs to be repainted for some other reason.

3. Regardless, your window procedure will only process one (1) queued message at a time. If you load a file in response to a button click (WM_COMMAND notification message), ain't no more queue messages (eg WM_PAINT, the 'redraw' message) gonna be handled until the processing of that WM_COMMAND message is completed.

[Mike Doty]

PekkMessage vs DOEVENTS 4 times

'PeekMessage definitely works, thank you.
'The hammer DOEVENTS4 takes care of a blank control and flicker.
'Tried using DIALOG and CONTROL REDRAW instead of DOEVENTS4 and get flicker.
'------------------------------------------------------------------------------------------------------------------
'Added this remark at 9:54 AM
'DOEVENTS4 also allows scrolling the listview while it is being updated and moving the dialog around the screen. I like it.
'------------------------------------------------------------------------------------------------------------------

FUNCTION DisplayRecordSet(hDlg AS DWORD) AS DWORD
  LOCAL row AS DWORD, col AS LONG, ColumnCount AS LONG
 
  LOCAL counter AS LONG  'not needed
 
  LOCAL x AS LONG
  CONTROL DISABLE hDlg, %LISTVIEW
  CONTROL KILL hDlg, %LISTVIEW
  CONTROL ADD "SysListView32", hDlg, %LISTVIEW, "SysListView32_1", 0, 21, _
        466, 257, %WS_CHILD OR %WS_VISIBLE OR %LVS_REPORT, %WS_EX_CLIENTEDGE _
        OR %WS_EX_LEFT OR %WS_EX_RIGHTSCROLLBAR
 
  'ColumnCount = slGetColumnCount
  ColumnCount = 8
  IF ColumnCount THEN
        MOUSEPTR 11
    LISTVIEW SET STYLE hDlg, %LISTVIEW, %LVS_EX_GRIDLINES OR %LVS_EX_FULLROWSELECT
    FOR col = 1 TO ColumnCount   'Insert columns with column names
      'LISTVIEW INSERT COLUMN hDlg, %LISTVIEW,col,slGetColumnName(col),100,0
      LISTVIEW INSERT COLUMN hDlg, %LISTVIEW, col, "col" + STR$(col), 100,0
    NEXT
  ELSE
    ? "No columns"
    EXIT FUNCTION
  END IF
 
  row = 0
  counter = 0 
  DO WHILE row < 10000   'modified this later, had a SQLitening function here  9:34 AM, CST
    INCR row
    INCR counter
    'LISTVIEW INSERT ITEM hDlg, %LISTVIEW,row, 0 , slF(1) 'Insert row, 0=no image
    LISTVIEW INSERT ITEM hDlg, %LISTVIEW, row, 0, "col" + STR$(counter)
    FOR col = 2 TO ColumnCount                               'add text into columns
      'LISTVIEW SET TEXT hDlg, %LISTVIEW, row, col,slF(col)
      INCR counter
      LISTVIEW SET TEXT hDlg, %LISTVIEW, row, col, "col"+ STR$(counter)
    NEXT
    IF row =30 THEN
      CONTROL REDRAW hDlg, %LISTVIEW
    ELSEIF ROW MOD 1000 = 0  THEN          'refresh screen every so often
      Message hDlg, "Reading record" + STR$(row)
      DOEVENTS4
    END IF
  LOOP
  CONTROL SHOW STATE hdlg, %LISTVIEW, %SW_HIDE
  FOR col = 1 TO ColumnCount   'fit columns
    LISTVIEW FIT CONTENT hDlg, %LISTVIEW, col
  NEXT
  CONTROL SHOW STATE hDlg, %LISTVIEW, %SW_SHOW
  Message hDlg, "Total records" + STR$(row)
  MOUSEPTR 1
  FUNCTION = row
  WHILE PeekMessage($NUL, hDlg, %WM_MOUSEFIRST, %WM_MOUSELAST, %PM_REMOVE):  WEND   'clear message queue
  'DOEVENTS4
END FUNCTION

[Michael Mattias]

Inquiring minds want to know....

Why would you use all the new 'LISTVIEW do this' commands, except when you add the listview control to the screen, where you use "CONTROL ADD "SysListView32"..."

"CONTROL ADD LISTVIEW" would seem to be more consistent, wouldn't it?

MCM

[Mike Doty]

PBFORMS uses that name as a default.

[Michael Mattias]

Just a little note , more or less related...

I guess PowerBASIC Inc. is getting really serious about "we want you all to code DDT style."

The dialog and image editors are no longer installed with PB/Win 9x. PB Support gave me some hokum response about 32 v 64 bit Windows with these 16-bit applications, but I have my own theory about why these tools were dropped frrm the release WITHOUT AN ENTRY IN THE 'WHAT'S NEW' section of the help file.


MCM

[Dominic Mitchell]

DOEVENTS4 also allows scrolling the listview while it is being updated and moving the dialog around the screen. I like it.

That is actually the poor man's multithreading tool, a holdover from 16-bit Windows.
In 32-bit Windows MsgWaitForMultipleObjects is used to solve these problems.
But you need access to the message loop to implement it.

[Michael Mattias]

But you need access to the message loop to implement it

Correct me if I'm wrong here, but I think the PB compilers support coding SDK-style, where you DO have such access.....