FiveTech Support Forums

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

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.

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

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

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.

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

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

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

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.

#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()

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

Ok thanks

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

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