Slow Refresh Rate of Screens

[Jim Coltz]

Re: Slow Refresh Rate since last update

I am not seeing any problem under vista or XP. Do you know if the problem is specific to a particular database, or can you duplicate it with Alphasports?

If you can duplicate with Alphasports, is there a particular form that shows the problem, or do they all? Can you describe exactly what you are doing.

If it is specific to your database, can you send us a copy to test on our machines.

Thanks.

I've sent a copy along with a bug report for you good folks to review. Thanks.

[Selwyn Rabins]

Re: Slow Refresh Rate since last update

I've sent a copy along with a bug report for you good folks to review. Thanks.

Can you please resend your message. I got the email, but there was no attachment.

Thanks

[Cian Chambliss]

Re: Slow Refresh Rate of Screens

Ok, to determine if the bug is due to presence of *ANY* menu, or just a single popup menu conditional command: does running the form with a custom menu based on the BLANK menu, that has only one entry still run slowly (i.e. just add an item to the blank menu called 'test'). If the answer is yes, then the problem has to exist generically (i.e. in all menus on forms) - if the simple menu with a single entry runs as quickly as having no menu, then next thing I would like to try is narrowing down what submenu of the standard form menu has the problem - by starting with a new custom menu based on the 'form' menu. and removing pulldowns one at a time (i.e. remove the File menu, then remove the edit menu etc...)

Thanks,
Cian

[aschone]

Re: Slow Refresh Rate of Screens

I wanted to report that I am seeing some of the same symptoms that are being reported in this thread.

I have only one database out of several that I have noticed this in. When I open the database I have a main form that auto loads. When this form is loading you are able to watch the menu bar populate its self from left to right I know when it is done because the "Minimize, Restore, Maximize" are the last buttons to be painted on the screen. Brand New forms and all currently existing forms display the same symptoms. This database is also experiencing the same bug that is reported here.

This problem is very pronounced on my workstation, on another workstation with the same database there is not a problem. The workstation that doesn't have issues is also newer and more powerful than my workstation. So I believe that workstation configuration may play a role in this problem.

On the other hand, several other version 8 databases that I use on my workstation do not have the issue. So I also believe that the issue is caused in part by something in the database.

Both databases that I tested are using the <System Menu> for every menu and right click option on the form.

Let me know if you need any additional info.

Thank you,
-Andy

[aschone]

Re: Slow Refresh Rate of Screens

Ok, to determine if the bug is due to presence of *ANY* menu, or just a single popup menu conditional command: does running the form with a custom menu based on the BLANK menu, that has only one entry still run slowly (i.e. just add an item to the blank menu called 'test'). If the answer is yes, then the problem has to exist generically (i.e. in all menus on forms) - if the simple menu with a single entry runs as quickly as having no menu, then next thing I would like to try is narrowing down what submenu of the standard form menu has the problem - by starting with a new custom menu based on the 'form' menu. and removing pulldowns one at a time (i.e. remove the File menu, then remove the edit menu etc...)

Thanks,
Cian

When I used a menu that only had one item "test" the problem was still there but the length in time to fully paint the menu was radically reduced with just one option "test" and then the "Minimize, Restore, Maximize" buttons.

With the database that has the problem opened and in a maximized view. I open the form in design mode. Then Minimize the Alpha5 application, so I am looking at my desktop, then Maximize Alpha5 the menu bar will go thru the slow repaint. *Edit this also occurs if the form is in "Form view" mode as well.

If I change tabs from a Form in design mode to a xbasic script in the code editor I again see the menu bar do a slow refresh. This happens on switching to the code editor and again on the returning to the Form in design mode.


Another symptom -
Like I mentioned previously I only have one database currently with this issue. In the "problem database" when I move my mouse over the menu options there is a "mouse over" event that causes the menu option to highlight. This highlight is typically 2 menu's choices behind where my mouse is. I can physically see the menu options flash on the screen, i.e. they disappear, reappear displayed as if mouse was hovering over them, then dissappear, then reappear as if the mouse was no longer hovering over them. In the "Good database" I do not see this delay when I mouse over the menu options. In this test I was just moving the mouse from side to side over the menu options monitoring the result with out actually clicking anything.

As I mentioned previously If I open a form in design view, I see the delay in menu repaint. If I change from "design view" to "form view" I see the delay again. Also same with going back to "design view" back to "form view" the menu repaint is very delayed. But if I close the form by clicking the "x" I do not see a menu repaint issue (only one form open, control panel with "form" tab selected is in background). So by closing the form I am going back to the control panel, the default menu attached to the control panel with "Forms" tab selected does not cause an issue.

[turbojack]

Re: Slow Refresh Rate of Screens

[QUOTE=aschone;426813] I only have one database currently with this issue. In the "problem database" when I move my mouse over the menu options there is a "mouse over" event that causes the menu option to highlight. This highlight is typically 2 menu's choices behind where my mouse is. I can physically see the menu options flash on the screen, i.e. they disappear, reappear displayed as if mouse was hovering over them, then dissappear, then reappear as if the mouse was no longer hovering over them. In the "Good database" I do not see this delay when I mouse over the menu options. In this test I was just moving the mouse from side to side over the menu options monitoring the result with out actually clicking anything.
[QUOTE]


Is this database where you could zip up & send to alpha to play with?

The problems I am seeing I do not see all the time. I have not figured out when it will do it. So I feel if I sent them what I have, Alpha will say it works good.

[aschone]

Re: Slow Refresh Rate of Screens

Is this database where you could zip up & send to alpha to play with?

The problems I am seeing I do not see all the time. I have not figured out when it will do it. So I feel if I sent them what I have, Alpha will say it works good.

I would need to ask permission from the database owner, but prior to me asking can an Alpha5 employee respond to let me know if they do need a sample submitted? Hate to ask for permission if it wont be needed.

[toothfixer]

Re: Slow Refresh Rate of Screens

When I used a menu that only had one item "test" the problem was still there but the length in time to fully paint the menu was radically reduced with just one option "test" and then the "Minimize, Restore, Maximize" buttons.

With the database that has the problem opened and in a maximized view. I open the form in design mode. Then Minimize the Alpha5 application, so I am looking at my desktop, then Maximize Alpha5 the menu bar will go thru the slow repaint. *Edit this also occurs if the form is in "Form view" mode as well.

If I change tabs from a Form in design mode to a xbasic script in the code editor I again see the menu bar do a slow refresh. This happens on switching to the code editor and again on the returning to the Form in design mode.


Another symptom -
Like I mentioned previously I only have one database currently with this issue. In the "problem database" when I move my mouse over the menu options there is a "mouse over" event that causes the menu option to highlight. This highlight is typically 2 menu's choices behind where my mouse is. I can physically see the menu options flash on the screen, i.e. they disappear, reappear displayed as if mouse was hovering over them, then dissappear, then reappear as if the mouse was no longer hovering over them. In the "Good database" I do not see this delay when I mouse over the menu options. In this test I was just moving the mouse from side to side over the menu options monitoring the result with out actually clicking anything.

As I mentioned previously If I open a form in design view, I see the delay in menu repaint. If I change from "design view" to "form view" I see the delay again. Also same with going back to "design view" back to "form view" the menu repaint is very delayed. But if I close the form by clicking the "x" I do not see a menu repaint issue (only one form open, control panel with "form" tab selected is in background). So by closing the form I am going back to the control panel, the default menu attached to the control panel with "Forms" tab selected does not cause an issue.

I am seeing all of the problems you mention on my databases. Hope the Alpha 5 engineers can solve the problem, as my database has become unusable due to the delays of menu and toolbar repainting everytime I change screens.

[martinwcole]

Re: Slow Refresh Rate of Screens

Have either of you sent a sample database to Alpha? The owner and chief programmer for Alpha are trying to help you, but unless you can demonstrate the problem, they can't help you.

Put some dummy data and send it to them with good instructions for repeating the problem.

[Selwyn Rabins]

Re: Slow Refresh Rate of Screens

We have not been able to duplicate this, but we did do some profiling on our code and have been able to add some optimizations that might help.

If you are seeing any slowness, here is a beta of the next patch that we will be releasing. Please let us know if this has made any improvements.

BetaPatch is now available. Download page for beta patch can be found at:
http://downloads.alphasoftware.com/a...chdownload.htm

[martinwcole]

Re: Slow Refresh Rate of Screens

Selwyn, I just tested the update - super major improvement!!!!!!!!!!!!!!!!!!

I had not previously been haveing anything to complain about, but in a scenario where I was going from a form that had no toolbar or menu bar to a browse with a toolbar, previously there was an irritating jump as it added the menu bar - now there is literally no jump - totalllllllllllllllllly clean smooth!!!!!!!!!!!!!!!!!!!!!

[toothfixer]

Re: Slow Refresh Rate of Screens

We have not been able to duplicate this, but we did do some profiling on our code and have been able to add some optimizations that might help.

If you are seeing any slowness, here is a beta of the next patch that we will be releasing. Please let us know if this has made any improvements.

BetaPatch is now available. Download page for beta patch can be found at:
http://downloads.alphasoftware.com/a...chdownload.htm

There is a noticable improvement in speed as the menus load on screen changes. Although screen repaints when screen changes occur are not as fast as they were previous to the last 2 updates, it makes my database at least usable again.

With the beta patch I notice that when the cursor is placed over a menu title, it "blinks", meaning that the title disappears and then reappears highlighted.

In conclusion, although the beta is an improvement in speed, the speed is still slower than it was prior to the last two updates.

If I can find time, I will delete the data on my database and enter some test data so that I can send you my database to help you figure out this problem. As my database contains confidential patient data, I cannot send the database "as is".

[Jim Coltz]

Re: Slow Refresh Rate of Screens

The latest beta patch (1730_3093) posted today seems to correct the issues I was having with multiple slow paints as well as the problem with conditional objects introduced in the one posted yesterday. Thanks to the entire Alpha Software Team for the quick response. I hope the effort involved with creating an example and emailing it over a dog slow dial-up connection helped in getting this resolved. It took 4 tries and couple of hours last night to get the latest example to Selwyn.

[toothfixer]

Re: Slow Refresh Rate of Screens

The latest beta patch (1730_3093) posted today seems to correct the issues I was having with multiple slow paints as well as the problem with conditional objects introduced in the one posted yesterday. Thanks to the entire Alpha Software Team for the quick response. I hope the effort involved with creating an example and emailing it over a dog slow dial-up connection helped in getting this resolved. It took 4 tries and couple of hours last night to get the latest example to Selwyn.

I'm happy that your issues were resolved with the latest beta patch. For myself, the beta patch provided a bearly noticeable speed improvement. I'm still seeing two menu repaints per screen change, as well as erractic highlighting behavior when the mouse pointer is placed over a menu title.

Yesterday, I sent Alpha 5 a copy of my database. I hope that they can solve this problem as I have spent over a year developing this database (it was my first attempt; a learning experience). If they cannot, my options are to revert to an earlier update, or scrap the project alltogether. As it was my first database, perhaps the error lies in my programming, although up to two updates ago, I did not have these problems. I cannot use the database at the slow repaint rate it is displaying. (Sorry if my frustration is showing through.)

[martinwcole]

Re: Slow Refresh Rate of Screens

Tooth,

I can definitely appreciate your frustration. After using Alpha for 9 years, I have developed this guideline: If I am having the problem, and it is Alpha based, others will have the problem, too. If no one else is having the problem, most likely it is my app.

Now while I occassionally find a bug first, and Alpha corrects it, 99% of the time, my guideline holds true.