UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Form Display Lag, Access 2013    
 
   
SomekindaVB
post Mar 6 2018, 07:03 PM
Post#1



Posts: 264
Joined: 15-December 16



Hi all,

My issue is about getting around a display lag or delay.

So I have a form the recordset of which is query made up of a workitem table and a customer table. This is required to display some portion of the customer record along with the work item data.

I need a button that opens a customer form. No problem, except that because the original form uses a query with the same customer record the customer record is locked

And so I thought i might need to close the work item form before opening the customer record.

CODE
lngClientID = txtCustomerID.value
Application.echo = false
DoCmd.Close acForm, Me.Name
DoCmd.OpenForm "FrmCustomer", acNormal, , "[ID] = " & lngCustomerID
Application.echo = true


Yes, this releases the record and works. The problem is there is a delay from closing the form and opening the new form. This is why I put on the application.echo. This is not working however.

I also used this to lock the window, but it also doesn't work. It seems the form closing ignores any display holdings.

CODE
Public Declare Function LockWindowUpdate Lib "user32" (ByVal hwndLock As Long) As Long ' Used to lock or freeze various windows
Use: Lockwindowupdate me.hwnd


So, is there some method for freezing the windows while closing to prevent this lag?
Go to the top of the page
 
LPurvis
post Mar 7 2018, 12:47 PM
Post#2


UtterAccess Editor
Posts: 16,280
Joined: 27-June 06
From: England (North East / South Yorks)


Hi

I'd be surprised if your problem is with freezing windows. Or windows in some way misbehaving. (Though Access installations can encounter problems, this sounds like these two forms are your only problem and other actions are OK?)
You're performing two actions yes? Closing the current form and opening another form. (The reasoning for that is almost incidental, but them both being bound to the same form and both editable is a little non-standard.)

So one, the other, or both actions are taking long than you'd expect.
So does opening the new form happen quickly alone?
i.e.
DoCmd.OpenForm "FrmCustomer", acNormal, , "[ID] = " & 1234 'Or whatever valid value you want to pass as a test

and then just closing the target form, for example:
DoCmd.Close acForm, Me.Name
Msgbox "Closed"

Do each of these happen very expediently as independent actions?

Cheers

--------------------
Go to the top of the page
 
projecttoday
post Mar 7 2018, 01:45 PM
Post#3


UtterAccess VIP
Posts: 10,069
Joined: 10-February 04
From: South Charleston, WV


Instead of closing the first form, have you tried moving off the record? (Haven't tried it. Just a suggestion.)

Why do you need 2 customer forms?

--------------------
Robert Crouser
Go to the top of the page
 
SomekindaVB
post Mar 7 2018, 10:18 PM
Post#4



Posts: 264
Joined: 15-December 16



ProjectToday - they are not two customer forms. one is a work item form that displays some customer information (This is a requirement of the business I work for), and the other is a client form. Each form has its own requirements.

The workitem form is based on the a query recordset, which displays some customer information.

I can't move off the record, except by closing down the workitem form.

LPurvis - my network is very slow, and tends to slow down the loading of a form, because obviously the record set must be pulled to the local machine before it can load the form with the recordset. This is why I was trying to lock the window in the first place.
Go to the top of the page
 
projecttoday
post Mar 8 2018, 02:43 AM
Post#5


UtterAccess VIP
Posts: 10,069
Joined: 10-February 04
From: South Charleston, WV


Then don't lock the customer record on the work item form.

--------------------
Robert Crouser
Go to the top of the page
 
LPurvis
post Mar 8 2018, 10:12 AM
Post#6


UtterAccess Editor
Posts: 16,280
Joined: 27-June 06
From: England (North East / South Yorks)


Hi

>> my network is very slow, and tends to slow down the loading of a form, because obviously the record set must be pulled to the local machine before it can load the form with the recordset.
Isn't that the entire crux of your issue then?
If it's a slow network, you can't fetch data any faster than it will allow and that is the point to improve surely?

>> This is why I was trying to lock the window in the first place.
I don't see what difference that will make in the fetching of data. Having data in an form (editable or not) won't impact your efficiency when opening another form based on other data over the network, which is already slow.
Your battle seems to be entirely with the opening speed of the new form. What's open or locked or not before that isn't really relevant.
Perhaps the form is based on a query which could be more efficient? If not, then it seems more like a hardware issue?

Cheers

--------------------
Go to the top of the page
 
missinglinq
post Mar 8 2018, 10:28 AM
Post#7



Posts: 4,537
Joined: 11-November 02



QUOTE (SomekindaVB)
So I have a form the recordset of which is query made up of a workitem table and a customer table. This is required to display some portion of the customer record along with the work item data.

I need a button that opens a customer form. No problem, except that because the original form uses a query with the same customer record the customer record is locked


You shouldn't be using a Query for the Record Source of the first Form...and you don't need to in order to 'display some portion of the customer record along with the work item data!'

The Customer Form should be based on the Customer Table, and the WorkItem Form based on the WorkItem Table. You should then have the Customer Form used as a Main Form, and the WorkItem Form used as a Subform, in a traditional Main Form/Subform configuration. This would take care of the locking problem, and I suspect would take care of the slow opening problem, as well.

Linq ;0)>

--------------------
Hope this helps!

The problem with making anything foolproof...is that fools are so darn ingenious!

All posts/responses based on Access 2003/2007
Go to the top of the page
 
projecttoday
post Mar 8 2018, 10:42 AM
Post#8


UtterAccess VIP
Posts: 10,069
Joined: 10-February 04
From: South Charleston, WV


Yes, if that works. What I was thinking is that if there must be a separate work item form it would be based on the work items table and the customer info on that form that they need to see would just be displayed via code or Dlookup's. No need to bind the data/lock the table.

--------------------
Robert Crouser
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    25th September 2018 - 06:01 AM