Control a from on another Access file, on another PC (1 Viewer)

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
I think it would help if you explained why you are doing this. My first instinct was that you wanted to bring up a message on the other machine. Now it appears you want to take control of the other app in order to requery a form if it is open.

What does this other PC do? Who's looking at it? Who's controlling it? Who opened the app originally?

I suspect the answer is it can't be done unless you can jump through the hoops outlined by Doc

The forms that needs to be updated are showing tasks. Tasks are listed in continuous form. When a person on either PC enters new task/delets old task...., the form on the other PC needs to refresh and show current updated information.

Next step will be to include the chat to the same form.

For both tasks, I need instant reaction updated on the remote PC.

Both fEnd applications are opened by the user in the morning and remain opened all the time.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
I am keen to understand why using a timer will circumvent all the issues that Doc raised?

I was hoping the code to refresh the form on the remote PC would be simple. Something similar to the code I listed.

Action active only when necessary and immediately stopped after the task is completed, seems to me as a slicker solution then having the timer runs all the time.

Also, I did the timer several years ago. If I remember correctly, the application was glitchy when the timer was triggering the event.

Certainly, in case there is no relatively simple solution the timer will be used.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 11:01
Joined
Feb 19, 2013
Messages
16,553
The forms that needs to be updated are showing tasks. Tasks are listed in continuous form. When a person on either PC enters new task/delets old task
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
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
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.

Hope this clarifies.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:01
Joined
Feb 28, 2001
Messages
26,996
I hope this is not the only way to avoid using the timer.

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.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:01
Joined
Feb 28, 2001
Messages
26,996
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.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 07:01
Joined
Feb 19, 2002
Messages
42,970
So far, you have been reluctant to tell us what problem you are trying to solve. You have asked us to make YOUR solution work but we don't agree that that is even an actual solution. Why would someone on PC2 want to force something to happen in an open database on another PC?

I once had what might be a similar problem with a wholesale florist. There were 8 people selling on the phone. Their manual method had everyone working in one large room and was to have everyone update on a white board grid what they sold so that the others would know what was still in inventory. Of course this wasn't 100% and so sometimes they "sold" something that wasn't in stock which made customers unhappy. In the Access application I developed for them, they always saw the inventory live but also had the problem that it might be slightly out of date. I gave them a refresh button to force a refresh and I also decreased the wait time for an automatic refresh. Given that they were all in touch with how their inventory moved, that was sufficient.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
Thanks The_Doc_Man. You've been very helpful.

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.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 07:01
Joined
Feb 19, 2002
Messages
42,970
Tried the timer. When set to refresh every second, the form quivers.
That is only one of the reasons I don't like timer events. I guess your actual requirements are still a secret. I'll let Doc attempt to help you.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
... I guess your actual requirements are still a secret. I'll let Doc attempt to help you.

In the previous response to Doc I explained in detail what are the requirements. Thank you for your attention in any case.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:01
Joined
Feb 28, 2001
Messages
26,996
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.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:01
Joined
Feb 28, 2001
Messages
26,996
Rereading this thread, I have another question: Physically, how far apart are the two PCs?

Both PCs are on the same location with full network access all the time they are active.

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.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 11:01
Joined
Feb 19, 2013
Messages
16,553
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.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
Rereading this thread, I have another question: Physically, how far apart are the two PCs?

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.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
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.

A new task is being created in the unbound field on the main form and is triggered on "After Update" event. So, no worries there.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:01
Joined
Feb 28, 2001
Messages
26,996
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.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
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.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:01
Joined
Feb 28, 2001
Messages
26,996
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.
 

Acke

Registered User.
Local time
Today, 12:01
Joined
Jul 1, 2006
Messages
158
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.

Good suggestion.

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.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 11:01
Joined
Feb 19, 2013
Messages
16,553
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?
 

Users who are viewing this thread

Top Bottom