Opening a form on a hyperlink click or button click is slow

josh

Hi,

I have noticed that when a user clicks a hyperlink or button in a cell to open a form, the form can take up to 15 seconds to open (when it normally takes around 2 seconds to open). It seems to happen/get worse if the user moves his/her mouse over the grid after clicking the button/hyperlink (as opposed to just keeping the mouse cursor in the cell that contains the button/hyperlink).

Anyway, I am going to investigate it myself to get to the bottom of it, but I was hoping that someone here might know what's going on.

Btw, I am suppressing mouse movements. I also am disabling the grid after the button was clicked, and that "seems" to help, but I need to look into it more to know for sure.

Info:




Set_Property(grd_orders$, "OLE.SuppressMouseMoveEvent", true$)

OI: 9.4.1

OS: Windows 10

Grid:

DonBakke

Josh - are you using promoted events?

josh

yes

DonBakke

We have observed similar behavior when those same conditions are in effect. We put an extensive amount of research into this and even worked with Revelation Software to try and figure out what is going on. While no clear smoking gun has been found, there is a definite correlation between mouse movement and promoted events. The mouse movement causes an increased number of Windows messages to be fired at the Presentation Server. In turn. the Presentation Server triggers an increased number of event handlers (especially WINMSG). This floods OpenEngine and causes the whole system to slow down. I'm glad you have SuppressMouseMoveEvent set to True, but the EditTable will still track some mouse activity for other reasons. You can try setting BLOCK_EVENTS to True before launching the window and then to False after the window has been launched to see if that helps. This might create unintended issues, so just be aware of that. You might also want to analyze your promoted events and make sure you limit them to the bare minimum, especially WINMSG. We also found that a promoted CHANGED event can also slow things down, especially when a record is read.

AusMarkB

I'll be of no assistance on this whatsoever, I just dropped in to say, that's a nice looking table.

Opto_Will

All,

From my recollection BLOCK_EVENTS did provide a noticable boost in response when wrapping it around opening a form. However, we stopped using it for a couple of reasons (though we could have worked around them if pressed). I *think* these were the main reasons (below) but would have to search back through notes to be sure.....

• It would appear the BLOCK_EVENTS actually stops WIN_DEF procedure from firing as a Default in the Form.
  
• We have instances of MSGTXT popups for errors in Create events. BLOCK_EVENTS stopped the ability to see or respond to the dialog (or something to that extent) which made it appear 'hung' to the user.
  

We talked with Don about the CHANGED event (like below) but the problem was this then needed to happen for each control on the form, for each type of event you want to disable

// Disable Send_Message(@Window : "EDL1", "QUALIFY_EVENT", "CHANGED", FALSE$) // Enable Send_Message(@Window : "EDL_1", "QUALIFY_EVENT", "CHANGED", TRUE$)

Just some things to consider for an informed decision :)

josh

I think I have fixed this by just disabling the grid before new form is opened, and enabling the grid after the form opens. Since I have only noticed this happen when opening a form via the SRP grid, this seems like a decent solution.

Are you saying it happens in other contexts too?

KevinFournier

Interesting. By disable, do you mean setting the ENABLED property to 0?

BarryStevens

I found that setting BLOCK_EVENTS works for me

josh

Interesting. By disable, do you mean setting the ENABLED property to 0

Yes.