I was just pointing out that the browse itself is not slow. It takes only about 10 lines of code to create a browse, and regardless of the size of the database the browse displays a new screen in about a second (when you press the [Pg Dn] key).
Is yours taking longer than a second?
When I said it must be “your” other code, perhaps I should have said “the” other code. I mean that it could be the tabs, dialog, or Explorer bar that is affecting the speed or the perceived speed. Unless, perhaps, you meant that one second is “slow?”
You print from another routine and then return to the same browse that you were already looking at. No refresh of the browse required -James
Don't say nonsense. I don't print from another routine I call the press from the explorerbar menu, I print and then refresh the xbrowse as I've always done –Silvio
Apparently you are doing the exactly what I said, calling the print routine from a button. The printing routine has nothing to do with the browse speed. However, the printing could take some time and if the user is waiting for it to complete, then the browse screen will be inactive while the printing is going on. This is not the fault of the browse, yet users will probably think it is. One solution is to display on the screen something indicating that printing is going on. This could be as simple as changing the cursor to the hourglass icon while printing.
Question, is it you or your customers, that are saying the browse is too slow?
here we are not talking about articles nor wholesaler we do not say nonsense -Silvio
I only mentioned that story to illustrate how less data can provide more information. This is definitely not “nonsense.” That wholesaler sold out to Whole Foods (net sales in 2017, 16 billion dollars), and Whole Foods was then purchased by Amazon. That all started with my software and the concept of providing less information which vastly increased sales.
My point was that less is more. If your browse system is really too slow, then maybe you should consider exploring other options, such as only showing certain records, and/or fields, in the browse, instead of all records and all fields.
I am just trying to point out other things that may contribute to the browse being slower than it normally would be. Some things, like printing, may be interpreted by users as the “browse is too slow” when actually it has nothing to do with the browse.
If a simple browse (with no other code) is considered as too slow, then you have very limited options, maybe browse an array, add more RAM, get a faster CPU, and/or use a solid state drive. Or, just live with it.
If the browse with the Explorer bar, tabs and dialog is too slow, then you could consider a different design to increase the speed.
I am merely pointing out some issues that may be contributing factors with the speed or perceived speed issue.
