In that case, if no one is sitting at the other PC then it doesn't matter about it being requeried until the user returns to the PC and their focus is on the form. So you can use another event such as click event on a control (not suggesting a refresh button) to requery the form.
I have a form which every time the user selects something from the menu, it checks a table in the backend for new messages for example and if new, displays them in a message box. To prevent overuse, once checked, it doesn't check again for 10 minutes since the last time it was checked
In that case, if no one is sitting at the other PC then it doesn't matter about it being requeried until the user returns to the PC and their focus is on the form. So you can use another event such as click event on a control (not suggesting a refresh button) to requery the form
There are two persons each sitting on their own PC. When person 1 enters a task on the PC1, person 2 should see that task immediately on the PC2.
As mentioned, the next step will be to build the chat. Again a similar event will be required. Immediate update on the PC remote to the PC the message was typed at.
Unfortunately, Access in Windows context is event-driven. You click on something ("Click event"). You open a form (form-related events). You close something (closure events). Because of the event-driven nature of the process, you have a limited number of choices. You have to supply an event. The Timer event is far and above the easiest way to do this. If this remote PC is sitting there, idle other than however that 2nd FE was launched, there is no event that could drive anything.
Access does not normally "see" the Windows internal scheduler events, device-driver events, and network events. Even if you had a network connection between the two FE files, you would have to consider that since that network connection isn't a command channel, you would have to monitor it as the source of a driving event to trigger that .Requery you wanted. Which means you would have to look into Windows network services to establish a connection between the two systems and would have to create a form as a framework for the event. Because events require a framework or context in order to even be "fired."
IF you found how to establish a cross-network comm link between the two FE files, then you would establish a "hidden" (perhaps minimized) form as the host for the remote PC's connection. This form could then sit passively in the background of the remote PC until you sent a signal from the local FE. Then, the code you showed us earlier that you said works for the local case could run on the remote PC - where in relative terms, IT would be local. From an engineering standpoint, this is the next-easiest thing to do what you wanted. But by comparison, that timer HAS to look a lot easier - to understand AND to implement.
Our posts crossed. You are using an all-Access solution, but there are third-party chat-window apps that would allow you to do this without nearly so much work. Unless your site domain admin is objecting. In which case, why would they NOT object to what YOU are building, which is or includes a chat app.
Our posts crossed. You are using an all-Access solution, but there are third-party chat-window apps that would allow you to do this without nearly so much work. Unless your site domain admin is objecting. In which case, why would they NOT object to what YOU are building, which is or includes a chat app.
The software is being used in my company and I am adapting it for myself. So, the domain admin will not object to anything .
Forms listing tasks are already built. The reason why I want to build the chat in addition to the tasks is that all existing chat applications I found so far are not having the functions I need. For example, I want to be able to one-click add a chat message to the tasks list. Also have other ideas to increase the efficiency of our daily routines which implicate the chat and tasks applications to be a part of the existing software.
Tried the timer. When set to refresh every second, the form quivers.
I found this access application that looks as if it could match the requirements. I will give it a try in the next few days.
Let's talk "practicality." Who GIVES a rat's patootie if you only run the refresh every 5 or 10 seconds? Do you really type THAT fast? I'm serious. Just because I can make Windows use its crystal clock to return a time of day to microsecond resolution, do I really need that for a board where someone else is typing inputs at human speed? (OK, there's perhaps a bit of hyperbole there.)
I'm a touch-typist and amateur novelist so I am highly practiced at typing. My best speed in High School was just above 80 wpm (no errors) on an Underwood manual typewriter. On an electric, I can maintain 60 wpm without breaking a sweat and still compose content in between sentences. But are you that fast for the data you are entering? If someone else is looking at the updated information, they will probably take longer than that to read and comprehend the new entry, particularly if it involves detailed tasks. Fast-reading a cheap detective novel is child's play. Fast-reading anything technical is a guaranteed low-comprehension scenario.
Another reason to consider a slower interrupt rate (clock rate) is that it might be POSSIBLE to send one character at a time from your PC designated as "local" but if you have to edit the contents like backspacing or using cursor-mode editing with mouse and keyboard, do you want everyone to see every frimpin' little keystroke and correction? Personally, I would wait until you had a confirmed entry that has been committed into the DB. THEN I would post it.
I am absolutely NOT telling you to forget about doing this with Access - but I am suggesting that blazing speed might not be appropriate or necessary. So if you don't like the appearance with one-second timers, use slower timers and recognize the human factor in the process. I'm sure you can slow the timers down to a point where the flicker isn't that big of a deal.
Believe it or not, this came to me while I was showering and looked at a wide reflection. (I will spare everyone's dignity by not telling WHAT was being reflected.)
If the two displays are close enough, drop the "remote PC" and instead get a bit of "desktop extender" software that allows you to have an overly wide desktop. That would let you have your continuous form off the edge of the local PC in favor of the forms you need for your data input. BUT link up a second display to the local PC, run a long video cable to it perhaps, and adjust IT so that your continuous form is on-screen but your work area is off-screen. Then the two screens are local to each other and your "refresh other form" code would work, with the driving event being the AfterUpdate event of the form in your working area. Remember I said you needed events to get anything done. That would be the perfect event because it would be the event that tells your system you have something to save - and to show.
my thought is if the user on PC2 is halfway through entering a new task and you come along and requery the form, fir a new entry, chances are they will lose their work, at the very least it will be interupted.
So perhaps have a separate form to display the list with a timer and an input form for inserts/deletes and edits.
The same street address, but separate office spaces. Also, tasks (and later chat) need to go back and forth between remote computers. So, thanks Doc for the effort , but the setup you suggested is not a solution in this case.
my thought is if the user on PC2 is halfway through entering a new task and you come along and requery the form, fir a new entry, chances are they will lose their work, at the very least it will be interupted.
So perhaps have a separate form to display the list with a timer and an input form for inserts/deletes and edits.
Now in reading your post #34, I am confused again on where this remote display is located. Users (plural) will work on remote computers (plural) according to that post. But you previously talked about one (singular) remote computer for this displayed form that needs a requery. I get the impression that I'm trying to analyze the wrong problem, one that really isn't yours. I'm not about to abandon you but I don't feel we have a good picture of the physical distribution and number of computers, as well as where this particular "remote form" is located.
I used the timer as it was the last resort from the beginning.
Solved the flickering by the condition. The form's timer is set to 1 sec., but the me.Requery action is carried out only if the condition is met. (I have a "scrapbook" table with several number and text fields that I use for different needs. The id on that table filters the row for values that are needed at some point, in this case, to determine whether the form should run me.requery action or not. Condition is set once any change to the task is made (new task, task deletion, change of date, change of peron responsible for the task...), on any of the PCs. The condition is being returned to the start value by the form after the form finished me.Requery action.
Both frontend DBs are copies of the same file, just with different file names. Listed codes are the same on both copies. Table "Tasks" contains tasks infomation, table "Scrapbook" contains condition information.
The code to set the condition is a part of the main form. The code to Requery the tasks and to return conditions to start values is part of the subform.
Code to set condition to updateable (1 updateable, 0 not updatable):
Code:
PrivateSub newTaskfrmField_AfterUpdate()
Dim DB as Database
Dim rst as Recordset
Dim rs as Recordset
Set db = CurrentDb
set rst = db.OpenRecordset ("Tasks", dbOpenDynaset)
rst.addNew
rst!Person = optPerson ' unbound option group on the main form - select person responsible'
rst!Date = ctrDate ' unbound date field on the main form - select date'
rst!TaskDscrp = newTaskfrmField ' unbound text field where user types task desription'
rst!Priority = optPriority ' unbound opt group to set the priority'
rst.update
rst.close
subformDataInput ' Function to input data into the subform'
if ComputerName = "PC1" then ' according to computer name, condition to apropriate field is being set'
Set rs = db.OpenRecordset ("SELECT * FROM tblScrapbook WHERE Id = 11", dbOpenDynaset)
rs.edit
rs!numericField2 = 1 'set condition to updatable for the form on the PC2
rs.update
rs.close
db.close
end if
if ComputerName = "PC2" then ' according to computer name, condition to apropriate field is being set'
Set db = CurrentDb
Set rs = db.OpenRecordset ("SELECT * FROM tblScrapbook WHERE Id = 11", dbOpenDynaset)
rs.edit
rs!numericField1 = 1 'set condition to updatable for the form on the PC1
rs.update
rs.close
end if
db.close
The code to Requery the form and return condition values to start values (subform timer is set to "1000" - 1 sec.):
Code:
Dim db as Database
Dim rs as Recordset
Set db = CurrentDb
set rs = db.OpenRecordset("SELECT * FROM tblScrapbook WHERE ID = 11", dbOpenDynaset)
rs.edit
if ComputerName = "PC1" and RS!numericField1 = 1 then
me.Requery
rs!numericField1 = 0
end if
if ComputerName = "PC2" and rs!numericField2 = 1 then
me.Requery
rs!numericField2 = 0
end if
rs.update
rs.close
db.close
The setbacks with using the timer function on day one are:
editing the code while the timer-form is active is annoying
some events between forms overlap. For example Docmd.GotoControl "frmField" on a certain form could not be done if timer-form is active. And the tasks form is active all the time.
I knew there were strong reasons to avoid using the timer. Now I remember what the reasons are.
I will do my best to return to the original idea to find a way to refresh the remote form without using the timer. My hopes are with the chat file I mentioned several posts earlier. The chat application must have remote computers, file-to-file communication problem solved.
Re-reading again, I have to say that your descriptions were very vague, which is why we are all over the place. I'm not going to jump all over your stuff because we get this a lot. But I have to say that we might have made faster progress with better descriptions.
According to post #24, you are not looking at a single central annunciator so much as you really want every user's system to be the "remote" system here. You phrased this to look different than subsequent descriptions have painted it. Still not going to give up here, but I am going to randomly ruminate for a moment.
If you want this display to be an element on every machine for which someone is running your app, your local displays can be driven by the other actions your users take. Windows and Access need events. You've got them but aren't necessarily thinking about them.
Let's say that your user Jack takes up a task. In the act of doing so, he will have to do something that provides an event. What you need to do can be automatic enough that the simple act of changing focus would trigger a subroutine to force the .Requery to this form on Jack's PC, though I am not actually suggesting the GotFocus and LostFocus events. They occur too often and would be just as annoying as your rapid Timer event.
Meanwhile, Margot just got up for a "potty break" and doesn't care whether her display updates or not. And neither should you care. She ISN'T providing events at the moment. But when she gets back, she can hit a TAB key or click the mouse somewhere, change which screen she is examining... doesn't specifically matter. The ONLY time that you DO care is if you hit a dry patch and nobody has anything to do, at which point you run out of usable events. This is where you might have a timer event with a 10-second interval.
You WERE using a Timer event already. So you know how to put code under event routines. The events you need to use might be the form's "Enter" and "Exit" events as a way to trigger the .Requery of your form.
Personally, I would write a subroutine in a general module that you could call from multiple events. In this context, you would know the correct name of the form to get a .Requery when needed. It would be simple to write code to test for that form to be open and to open it if not. Then test for the last time you triggered a .Requery. Then do a DLookup on the DMax of some date and time in the task list table. Compare the last entry to the last update (which can go in the general module's declaration area). Then and ONLY then, if newer entries exist than the last screen update, perform your .Requery.
You might have to do a short analysis of work habits to know "form touch" patterns so you could pick the right forms for these events. But your user work patterns could be the source of all the events you need in order to drive your list of activities. I think you need to spend a little analysis time but it will help you tremendously if you do.
Re-reading again, I have to say that your descriptions were very vague, which is why we are all over the place. I'm not going to jump all over your stuff because we get this a lot. But I have to say that we might have made faster progress with better descriptions.
First of all, Doc, I honestly appreciate your dedication to this case. I don't know if that is usual approach on the forum or not, but I am very grateful for the attention. Regarding the vague descriptions, please note that English is my second language and computer-English is an additional challenge. I am sorry to take away the focus and lose everybody's time.
Personally, I would write a subroutine in a general module that you could call from multiple events. In this context, you would know the correct name of the form to get a .Requery when needed. It would be simple to write code to test for that form to be open and to open it if not. Then test for the last time you triggered a .Requery. Then do a DLookup on the DMax of some date and time in the task list table. Compare the last entry to the last update (which can go in the general module's declaration area). Then and ONLY then, if newer entries exist than the last screen update, perform your .Requery.
Our communication overlapped again. I listed my timer solution in the previous post. But also listed confirmed reasons why I wanted to avoid using the timer in the first place. If there is no better solution, we will have to live with the timer.
the reason for using the timer is because it creates an event when there otherwise would not be one. My point is users are creating events all the time unless they are not using the computer, in which case why does it matter of the form is requeried or not? and as indicated in post #23 I use one of these user generated events to check if a condition has changed and if so, does something. It is just a case of finding the right event.
I agree with Doc, the picture you paint of your actual situation changes with each post. So perhaps answer these questions to clarify what you actually have
1. How many PC's are you talking about?
2. Is this going to change in the future? if so in what way?
3. Does each PC needs to refresh all the other PC's?
4. Typically how frequently is a new task added/amended/deleted?
5. Are all the PC's on the same version of access/windows
6. Is the form that needs to be refreshed simply for display - or do users interact with it in any way (such as scrolling when there are more tasks than can be displayed)
7. You have a separate form for data input in respect of tasks?
8. For context what is the corporate environment? manufacturing? call centre? help desk? trading desk? something else?
9. Why is it so important that other PC's are updated instantly, regardless of whether that form is actually open or anyone using the PC?
I agree with Doc, the picture you paint of your actual situation changes with each post. So perhaps answer these questions to clarify what you actually have
I was trying to make things simple by keeping information on a minimum. Let's change that....
1. How many PC's are you talking about? Two PC's
2. Is this going to change in the future? if so in what way? Unlikely, but it could come up to 3 PC's.
3. Does each PC needs to refresh all the other PC's? Yes
4. Typically how frequently is a new task added/amended/deleted? Depending on a weekday and period of the day, but let's say in the peak - one action per minute. It is not that frequent as much as it is important for a person to see the task immediately in some cases, and if possible, to alert the user that there are new tasks if the task form is not active.
5. Are all the PC's on the same version of access/windows Win7 and Win8. Both running Access 2010.
6. Is the form that needs to be refreshed simply for display - or do users interact with it in any way (such as scrolling when there are more tasks than can be displayed) There are main form and subform. The main form with unbound fields and buttons to filter the tasks. Subform - continuous form that is scrollable, but users can also enter the text field to edit task description, use the right-click menu to change task date, priority, and person in charge of the task. So, users do interact with the form.
7. You have a separate form for data input in respect of tasks? No. The same form to enter, amend, delete, and view data.
8. For context what is the corporate environment? manufacturing? call centre? help desk? trading desk? something else? The wholesale, but the small company where there is a lot of multitasking. Tasks are not that frequent but are significant, important, and usually require an immediate response.
9. Why is it so important that other PC's are updated instantly, regardless of whether that form is actually open or anyone using the PC? Because of the frequency of the overall activity. At peaks, there are a lot of incoming phone calls, emails, couriers coming in for orders... It is necessary to have a tool to efficiently and quickly communicate the tasks. The tricky part is passing on the task as usually when one person is free to talk, the other is not. The tasks get missed. It is not only significant to pass the information quickly, but also to make sure the user does not miss the new task during peaks. When saying immediately, it does not have to be instant in cases of tasks., Even a full minute to refresh data would be more than enough for tasks. But for the later part of the project - for the chat - immediate form requery would be necessary.
The timing is also important. Couriers are coming for collections at the agreed hour and the orders must be prepared and ready in time.
The chat incorporated into the main software is significant. We are trying to put as much information in one place as possible. Information is coming via email, landline, mobile, Viber, WhatsApp, sms... Having the tasks and the main inside-company chat in one place would significantly reduce chances for error. One-click adding tasks from chat, one-click adding order/delivery tasks and similar is a tool we are trying to produce.
In short, creating tasks and chat tool to communicate information quickly and efficiently during peaks, when there is a lot of multitasking going on.
Please let me know if there is more information you think would help you work out the solution.
You might consider using a portion of the main form's real estate to display a subform, and use a timer event in the subform. Maybe that will limit, or corral, the overall flickering. You might also consider using a different piece of software, such as Tableau, or something that is known to contain dynamically refreshed dashboard type capabilities.
Getting a bit creative, you could also experiment with creating a VBScript in the background which runs in a loop on the "message receiver's" PC, it would use Access automation to continually GetObject of the currently open Access app and refresh a form. That way, there is no flicker from the Access-driven Timer event. It would run invisibly and imperceptibly in the background.
If I were you, and given that the primary way people solve this is by a form timer or refresh/requery events/actions, and if (like you) I felt that there was some undesirable side effect from the timer, I would probably experiment with this option. It would only take a few moments to attempt, and might be a bit fun.
My advice would be to continue evaluating your options from the standpoint of what can be done on the message receiver's PC. I tend to agree with the general direction this thread has gone, which is, going at it from the other route probably isn't going to lead anywhere, it's just not how software design is done, with very rare exceptions and mostly having to do with Tech Support or remote I.T. security/management.
thank you for the clarification. Presumably the answer to Q6 would include entering new tasks. I agree with Isaac, have a subform with a timer event which can show messages such as 'New task added', 'Task X reassigned'.
Not tried it in your type of environment but if the message 'box' is a single memo/long text field in the back end which users can append to - that should refresh based on the refresh interval set in File>Options>Client Settings. Make it rich text and you can add formatting for colour/bold/highlight etc. It works for me with two apps connected to the same BE
Put it on your main form as a bound subform. if the data changes, the form control is refreshed immediately but it does not generate an event, so you might still need a timer event to draw the other users attention to it. Store the message in a form public variable in the timer event (perhaps 30 secs), compare with the current message and if different draw the users attention however you see fit (msgbox, flashing banner, whatever). If the user has noticed the update, they could simply click on the memo control as acknowledgement which would update the form public variable.
Point is it is a single field, not a series of message records
Pat agrees with me (post #33) about requerying the form. Use a user generated event which is outside of data entry/editing (other than the current event perhaps). Could be a mouse move event for example (even the click event on the message box above)- again the code would check if anything has changed before requerying.
You might consider using a portion of the main form's real estate to display a subform, and use a timer event in the subform. Maybe that will limit, or corral, the overall flickering. You might also consider using a different piece of software, such as Tableau, or something that is known to contain dynamically refreshed dashboard type capabilities.
The flickering is solved as described in post #37, but the bad side of using the timer is a setback. Never used Tableau. Not sure how difficult would be to learn Tableau from scratch.
Getting a bit creative, you could also experiment with creating a VBScript in the background which runs in a loop on the "message receiver's" PC, it would use Access automation to continually GetObject of the currently open Access app and refresh a form. That way, there is no flicker from the Access-driven Timer event. It would run invisibly and imperceptibly in the background.
If I were you, and given that the primary way people solve this is by a form timer or refresh/requery events/actions, and if (like you) I felt that there was some undesirable side effect from the timer, I would probably experiment with this option. It would only take a few moments to attempt, and might be a bit fun.
Sounds very interesting. Tried to make a non-stop loop in the subform containing the tasks, but it did not work. I guess it needs to be done in a way different from what I understand.
I made it like this:
Code:
Private Sub Form_Open(Cancel As Integer)
Dim varNumber as Long
varNumber = 0
Do While varNumber = 1
me.Requery
Loop
End Sub
What should be done differently to make this work? I would be very happy to test this suggestion.
.
