Comments and requests about TWBrowse

[MarcoBoschi]

Hi,
I have a big dialog with a Listbox inside.
oBrw:cAlias is a dbf table in a server volume. Network is very slow.
I drag another application's dialog left and right again and again and again..
I note a very slow refresh. It is tedious and ugly looking.
Repaint of other applications with similar listbox work more quickly

My proposal is this: is it possible to modify TWBrowse class so as to make it much faster.
Method Paint makes a lot of skip in the database without a reason
He should do so only if it has the focus and if the user touches any key or the mouse and not if the application is in the background
If I did not explain enough here I am available, Meanwhile, thanks for your attention.

Marco

[Antonio Linares]

Marco,

If the network is slow you could consider to load the records into an array and browse the array instead of the DBF.

Every amount of time you may check if the DBF has been modified and if so, then you reload the array.

[MarcoBoschi]

Antonio,
thanks for your interest.
Even locally you can note this "refresh"
You say to load only visible records?
Could not become a new feature of twbrowse class?
It's just an idea
Have a nice weekend

marco

[MarcoBoschi]

Antonio,
please I have another question: xBrowse provides this feature?
marco

[Antonio Linares]

Marco,

Class TWBrowse is the fastest FWH browse as it performs very few calculations to display the fields data. It is really strange that you find it slow. Surely there is a problem with your network or server that is slowing down the data access.

Class TXBrowse is much more sofisticated and provides many features thats why it is a little slower than TWBrowse. But even Class TXBrowse is very fast for modern computers and networks.

Definetively there may be a problem in your network. What Windows versions are you using from the client computers and in the server ? It is very important not to use different Windows versions on the same network.

What computers processors are you using ? Memory amount ? Only on very old computers you could experience a slow performance.

[MarcoBoschi]

Antonio,
I know very well that TWBrowse is very very fast.
This is just an idea: If my application is in background the repaint method should not read information from the table but only by an array containing the records visible at that moment.
I do not know well twbrowse class, I just use it.
The class could distinguish between actions desired by user and actions performed by the system. In the first case (user and foreground) is obvious that Method Paint should re-read records from table.
In the second one (system, background and involuntary) for instance evoked only to move another application over it on the desktop, it would be much faster, if repaint was just "the image" of that moment, or as written above, reading an array.
My observation is more theoretical than practical.
If there are particular problems of development could be a good implementation
The end user uses an app with less inertia

Bye
marco

[Antonio Linares]

Marco,

could distinguish between actions desired by user and actions performed by the system

Thats the key. How to identify them ?

Even if the window or dialog, that contains the browse, don't have the focus, the user may be watching the records, or using a timer to refresh them from the dbf. How to know when the records should not be the DBF real ones ?

Its a quite difficult question...

[MarcoBoschi]

Antonio,
You're in right.
I hope to prepare a sample for you and other guys to explain better what I think exactly.
Have a nice day

marco

[nageswaragunupudi]

Mr Marco

In the second one (system, background and involuntary) for instance evoked only to move another application over it on the desktop, it would be much faster, if repaint was just "the image" of that moment, or as written above, reading an array.

Here is a derived class from TXbrowse. This does not read data to repaint when it gets PAINT messages when it is out of focus for reasons given by you above.

Hope this can be tested in real applications and see if this is useful.

Code: Select all  Expand view

#include 'fivewin.ch'
#include 'xbrowse.ch'

#xtranslate DelObj <o> => If <o> != nil; DeleteObject( <o> ); endif; <o> := nil

CLASS TXBR3 FROM TXBROWSE

   CLASSDATA lRegistered AS LOGICAL // used internally

   DATA  hSaveScr

   METHOD Paint()
   METHOD Destroy()

ENDCLASS

METHOD Paint() CLASS TXBR3

   local aInfo

   if ::hSaveScr != nil .and. GetFocus() != ::hWnd
      aInfo := ::DispBegin()
      DrawBitmap( ::hDC, ::hSaveScr, 0, 0 )
      ::DispEnd( aInfo )
   else
      Super:Paint()
      DelObj ::hSaveScr
      ::hSaveScr  := WndBitMap( ::hWnd )
   endif


return nil

METHOD Destroy() CLASS TXBR3

   DelObj ::hSaveScr

return Super:Destroy()

 

Usage ...

XBROWSE may be defined as usual but at the end add the clause " CLASS TXBR3()"

[James Bott]

Marco,

TWBrowse does only read the records in the display when it is repainted. If you are viewing records in a filter this could be very slow.

You could disable the browse when the user opens another window or dialog, then enable it when they return to the window or dialog containing the browse. This way it would not get repainted.

James

[MarcoBoschi]

Ok thanks

[MarcoBoschi]

James,
I've tested a program with

ACTIVATE DIALOG oDlg ON INIT oBrw:disable()
to disable twbrowse.
Then I move on the desktop another little window of another application.
It seems that repaint of dialog with obrow inside is active.
It is very very slow
thanks

[James Bott]

Marco,

I think you have something else going on.

Below is a test program. After starting it, move the mouse cursor over it and you will hear a beep as the browse repaints. Then press the button and the browse will be disabled. Now try moving the mouse over it again and there is no beep. This confirms that the browse is not repainting when disabled.

We are going to have to see your code to figure out what is going on in your app that is causing the problem.

James

Code: Select all  Expand view

// Test disabled TWBrowse for painting while disabled.
// Use with FWH\samples\customer.dbf file

#include "fivewin.ch"

function main()

   local oWnd, oLbx, oBar

   use customer

   define window oWnd title "Test Browse"

   define buttonbar oBar of oWnd
   define button of oBar action oLbx:disable()

   @0,0 listbox oLbx fields first, last;
      alias "customer";
      of oWnd

   oLbx:bSkip:= {|nRecs| (msgbeep(),customer->(dbskipper( nRecs)) ) }

   oWnd:oClient:= oLbx

   activate window oWnd

return nil

[James Bott]

Apparently, my test was flawed. I concerned me that I was only hearing one beep when the screen was repainted. So I figured out it needed a sysrefresh() and a slight delay so all of the beeps could be heard.

The below example is a fix. Now even when the control is disabled() you can hear beeps.

I notice when the screen gets repainted there seem to be many more beeps than there are records displayed which means more records are being read than are needed. Maybe the screen is being repainted two or more times. This needs further investigation.

Any ideas, Antonio, or Rao? Or anyone else?

James

Code: Select all  Expand view

function main()

   local oWnd, oLbx, oBar

   use customer

   define window oWnd title "Test Browse"

   define buttonbar oBar of oWnd
   define button of oBar action oLbx:disable()
   define button of oBar action oLbx:enable()

   @0,0 listbox oLbx fields first, last;
      alias "customer";
      of oWnd

   oLbx:bSkip:= {|nRecs| (msgBeep(),sleep(.1),sysrefresh(),customer->(dbskipper( nRecs)) ) }

   oWnd:oClient:= oLbx

   activate window oWnd

return nil

[James Bott]

Ok, I see the problem. Any movement of something over the browse will trigger a repaint and thus a re-read of all the displayed records. As the object over the browse moves, the screen may need to be repainted many times thus many re-reads of the records. When the records are in a filter or are being read from a network drive this may make a very noticable delay in the repaint.

Also, you can't stop repainting when the control is disabled since the screen still needs to be repainted. If you couldn't read the records, then there would be no data to display.

The simple solution is to use recordsets. Since these are arrays stored locally, then the repaint will be fast. The downside is that records that have been changed at the source will not be visible on the client (in the recordset) until the recordset is refreshed.

Another solution might be to modify the browse to buffer the displayed data in an array (as Marco suggested), so that only the array is reread whenever the screen is repainted but only when the control is out of focus. This could be complex to implement and would also slow down the normal display since the buffer array would have to be reloaded each time a new record was displayed in the browse.

James