• ** There has been a recent site upgrade. Please clear your browser cache to avoid issues. **
  • New forum feature - post voting and best solution

    Check out this thread for the details: https://www.access-programmers.co.uk/forums/threads/new-forum-feature-post-voting-and-best-answer.314134/

    This new feature looks great to me! :)

  • We now have 3 forum themes

    Go for the default (light) theme, Shades of Grey or Shades of Blue. I just added the Blue one.

    The thread about it is here: https://www.access-programmers.co.uk/forums/threads/new-forum-theme-shades-of-blue.314136/

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

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
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.
 

Isaac

Lifelong Learner
Local time
Today, 12:38
Joined
Mar 14, 2017
Messages
2,404
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.
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:38
Joined
Feb 19, 2002
Messages
29,747
Doesn't it occur to you that PersonA might be doing something when PersonB is trying to requery their form? And with three users there is twice the likelihood that you would clobber someone's work.

This is simply not a reasonable process. I gave you a solution that I implemented and which worked fine for EIGHT very busy people but you don't seem to think it works for even two people.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 19:38
Joined
Feb 19, 2013
Messages
12,540
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.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:38
Joined
Feb 19, 2002
Messages
29,747
I also created a task manager for a busy office. When someone takes a task off the list, the form updates the task record with the person's ID and requeries the form. That way everyone can see that someone is working on a task. If they choose it before their form is requeried, the task record shows it as being in process. When the user saves the task record, the "assigned to" is removed and the task list is requeried which removes the task from the list. Again, the task list gets requeried frequently so it doesn't matter if a new task gets added. It will be seen in a minute or two.
 

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
Thanks Isaac! It would be great to create what you suggested. Please look at my response.

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.
 

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
Doesn't it occur to you that PersonA might be doing something when PersonB is trying to requery their form? And with three users there is twice the likelihood that you would clobber someone's work.

This is simply not a reasonable process. I gave you a solution that I implemented and which worked fine for EIGHT very busy people but you don't seem to think it works for even two people.

Correct. If I find a way to implement Isaac's suggestion, I think I know how it will be possible to control the form Requery when the form is being used.

Regarding your solution in the description in post #45... If a person is working on the form on a certain PC, other forms are somehow locked until the users finish the session. Is that correct understanding?
 

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
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.

Is it File>Options>Client Settings "Refresh interval (sec):" section that you are referring to? It is set at 60 in my case.

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.

Will try it.


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.

I will first try to make a loop that Isaac suggested. I see the mouse move event as the next best choice.
 

Isaac

Lifelong Learner
Local time
Today, 12:38
Joined
Mar 14, 2017
Messages
2,404
Thanks Isaac! It would be great to create what you suggested. Please look at my response.

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.

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.
Hi @Acke
An infinite loop would be more along the lines of "Do Until 1=2" or something like that. I use them any time I want a script to run indefinitely. (Not referring to Access).
Attached is a zip file containing 2 extremely simple/rough files just to show what I mean. After unzipping them & saving them both somewhere, then change .txt to .vbs, if you open the database first, then open the Form. Then double click the VBS file to start running it. Every 5 seconds it will refresh the db form. If at any time it either can't find Access running or the form not displayed, it will display error and quit. All it does is a re-query, (which messes up which record you're working on on the form), but of course, this is just to demonstrate the concept that an external script can run invisibly and continuously and do something to an Access form...How exactly you want to resolve doing something to the user's Form while not negatively impacting their work is another story, but this script could be tweaked to do any number of different things just like Access VBA can.
What I think is "nifty" to have this in one's toolbelt is that you can run continuous code WITHOUT actually locking up Access VBA, which of course is what happens if you run a continuous loop inside Access vba. (Except for, notably, the Timer event).

Of course you can always adjust the script to stop running on some other cue, or to keep running but only try to do its thing to the form on certain conditions (like if it finds the form loaded), who knows, whatever you want.

PS .. it's surprisingly easy to learn Tableau from scratch. It's based on the premise of being a very dumbed-down, no-code drag and drop platform. Still, of course, there is simplistic usage and then more advanced usage that requires some study, but the internet is saturated with enthusiasm, support & examples. However, the license is not cheap. A big advantage it has? Hosting reports & dashboards online on Tableau Public site, for free.

Last note, Pat said something that sounded similar to an idea I often suggest to people--the simple notion of making your application involve features for assigning work and working queues. This is one of those things that your client/business partners may not actually suggest or require it, you have to suggest it to them. They're doubtless already wondering "how will we separate and assign work in this new tool?"...I usually just let them know, Hey, what we really need to do is have the database allow people to select work (in batches, even), and "assign" or "reassign" them to a user. So that work is always separated, always assigned, never conflicting. Suggesting it in contexts that seem reasonable, I've never had a response other than total enthusiasm for the idea, and away we went. Just my experience.
 

Attachments

  • Test Refresh Form in Loop.zip
    23.4 KB · Views: 8
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:38
Joined
Feb 19, 2002
Messages
29,747
Regarding your solution in the description in post #45... If a person is working on the form on a certain PC, other forms are somehow locked until the users finish the session. Is that correct understanding?
I really don't think you can make PC2 do something to a program running in memory on PC1 no matter how hard you try. I'm positive that isn't the way the message programs work either. I would hazard a guess that those programs also work on some type of timer event to cause them to refresh.

I've described two solutions I created for what I think are similar applications. You don't like either of them. Maybe someday you will figure out how to get your code to somehow run in memory on some number of other computers. Good luck.
 

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
Hi @Acke
An infinite loop would be more along the lines of "Do Until 1=2" or something like that. I use them any time I want a script to run indefinitely. (Not referring to Access).
Attached is a zip file containing 2 extremely simple/rough files...

Thank you Isaac for the sample. I like the idea.

(I edited the post as I found a way to start the VBS from the VBA)

Last note, Pat said something that sounded similar to an idea I often suggest to people--the simple notion of making your application involve features for assigning work and working queues. This is one of those things that your client/business partners may not actually suggest or require it, you have to suggest it to them. They're doubtless already wondering "how will we separate and assign work in this new tool?"...I usually just let them know, Hey, what we really need to do is have the database allow people to select work (in batches, even), and "assign" or "reassign" them to a user. So that work is always separated, always assigned, never conflicting. Suggesting it in contexts that seem reasonable, I've never had a response other than total enthusiasm for the idea, and away we went. Just my experience.

The option to assign a task to a person is already available. There are options per person, person+person as a team and everybody (includes all the people). It that is what you meant...
 
Last edited:

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
I've described two solutions I created for what I think are similar applications. You don't like either of them. Maybe someday you will figure out how to get your code to somehow run in memory on some number of other computers. Good luck.

On the contrary. I am interested in your solution, but don't understand it from the description in your post #45. Once I resolve the issue of refreshing the form, I will have to deal with the issue of overlapping automatic requery with entering the task. It would be great if you would explain how you solved this issue. Again, if that is what you meant...

As mentioned, English is not my first language and computer English is an additional difficulty. Frases you guys use and understand on the spot, I need to read several times before I understand fully what you were trying to say.
 

Isaac

Lifelong Learner
Local time
Today, 12:38
Joined
Mar 14, 2017
Messages
2,404
Thank you Isaac for the sample. I like the idea.

(I edited the post as I found a way to start the VBS from the VBA)
Awesome. I should have mentioned, that's another wonderful aspect of the whole thing...not only can vba easily start a vbs file, it can create the file too (by the same methods I'd use to create any text file - scripting filesystemobject + textstream object) and save it. Nicely encapsulated.

The option to assign a task to a person is already available. There are options per person, person+person as a team and everybody (includes all the people). It that is what you meant...
Oh, ok. Perfect! Sorry, I missed that while trying to digest this long thread. Great, that helps.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:38
Joined
Feb 19, 2002
Messages
29,747
Which of the two situations is most like yours? If it is the task situation, you are wasting your time on this wild goose chase to run code in memory on some other machine remotely. You can do what you ask with timer events but you don't want to do that. Two or three people simply don't work fast enough for this to be such a crisis. Is the world going to come to an end because one of them chooses anything other than the most recent task on the list? This is not usually the way task list processing works anyway. Task lists are prioritized both by urgency and wait time. So the longer you've been in line, the closer you are to the top of the list. You keep moving up unless some task with a higher priority slips in ahead of you. The EIGHT people taking orders for live flowers were very busy for about 3 hours early in the morning and really were in jeopardy of selling something that had already sold out if the inventory wasn't refreshed immediately.
 

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
Awesome. I should have mentioned, that's another wonderful aspect of the whole thing...not only can vba easily start a vbs file, it can create the file too (by the same methods I'd use to create any text file - scripting filesystemobject + textstream object) and save it. Nicely encapsulated.

Thanks Isaac for pointing out the VBScript option. I was not aver it existed. It is a great trick. Opens new possibilities.

Using the VBScript file implies having another file to worry about. As the simplest solutions are the best, I tried to avoid having the VBScript file and to use form's VBA to call the procedure you kindly suggested. It worked well on the button event, mouse move event, but not on the Form Open event. And I need it to run on Form Open event.

It looks as if there is no other option but the script if I want to use your loop trick on form open event. Is this correct?
 

Isaac

Lifelong Learner
Local time
Today, 12:38
Joined
Mar 14, 2017
Messages
2,404
How did it not work on form open event? Can you be more descriptive?
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 14:38
Joined
Feb 28, 2001
Messages
18,026
I understand that English is not your first language, so I will try to make this clear. Please review your answers in your post #41 of this thread.

Your answers to question #1 and question #9 simply cannot both be correct. If you have only two PCs, you cannot enter data fast enough. Or at least that is how it appears from my side of the screen. With only two people doing data entry, nobody will have a backlog. Therefore, I continue to feel that some information is missing. I am not accusing you of any kind of lying. But I continue to believe we have mis-communicated.

@Pat Hartman - regarding messaging apps, which you mentioned in passing, they usually work based on using WinSock methods to establish a network channel to a chat partner (or chat room). Their events are network I/O completion events, usually. They definitely are NOT using SMB in the "file" sense - though I believe if you can specify the intended recipient as a UNC network device, SMB WILL act as a file-oriented comm link, where the unit of transmission is a text line, with or without attachments.
 

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
How did it not work on form open event? Can you be more descriptive?

Sorry, Isaac. I was testing your solution in the time gaps during the workday with lots of distractions. When writing the post #55 I was under wrong impression that the code worked if called from the VBS but not if from the VBA. The code is not working regardels if it is called from the VBS or from the VBA. Therefore, please discard the post #55.

The description:
If on open, load, resize, activate, current, the form does not open.

Open event - form doesn't open at all. Have to reset the code (hitting the square buton in the VBA of the form) to reclame control of the access.
Load event - the form opens only after I reset the code. After reset, the form opens and runs the code well.
Resize event - the same as on Load event, only all happens quicker.
Activate - when Pop up and Modal are "yes", the form opens but the code doesn't run. When Pop and modal are set to "no", the form acts the same as in case of Load or Resize.
Current - the same as on Load..., but canceling the code is messier.

The above is for the VBS. The loop never runs if called from the VBA in cases of open, load... If the code is called from the VBA, the form opens after reset, but the loop doesn't run.

If the code is called any other way (button click, mouse move...) it works perfectly. That is for both VBA and VBS.

To start the VBS I use:
Code:
Option Compare Database
Option Explicit
Const PROCESS_QUERY_INFORMATION = &H400
Const SYNCHRONIZE = &H100000
Const INFINITE = &HFFFFFFFF

Const STILL_ACTIVE = &H103&

Const glrcErrFileNotFound = 53

Private Declare Function OpenProcess Lib "kernel32" _
(ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As Long
Private Declare Function GetExitCodeProcess Lib "kernel32" _
(ByVal hProcess As Long, lpExitCode As Long) As Long

Sub RunApp(strCommand As String, intMode As VbAppWinStyle)

   ' Run an application, returning immediately to
   ' the caller. Just presented as a parallel for
   ' ahtRunAppWait

   Dim hInstance As Long
   On Error GoTo ahtRunApp_Err
   hInstance = Shell(strCommand, intMode)
 
ahtRunApp_Exit:
   Exit Sub
 
ahtRunApp_Err:
   Select Case Err.Number
      Case glrcErrFileNotFound
         MsgBox "Unable to find '" & strCommand & "'"
      Case Else
         MsgBox Err.Description
   End Select
   Resume ahtRunApp_Exit
End Sub

Sub RunAppWait(strCommand As String, intMode As VbAppWinStyle)
   ' Run an application, waiting for its completion
   ' before returning to the caller.

   Dim hInstance As Long
   Dim hProcess As Long
   Dim lngRetval As Long
   Dim lngExitCode As Long

   On Error GoTo ahtRunAppWait_Err
   ' Start up the application.
   hInstance = Shell(strCommand, intMode)
   hProcess = OpenProcess(PROCESS_QUERY_INFORMATION Or SYNCHRONIZE, _
      True, hInstance)
   Do
      ' Attempt to retrieve the exit code, which will
      ' not exist until the application has quit.
      lngRetval = GetExitCodeProcess(hProcess, lngExitCode)
      DoEvents
   Loop Until lngExitCode <> STILL_ACTIVE
 
ahtRunAppWait_Exit:
   Exit Sub

ahtRunAppWait_Err:
   Select Case Err.Number
      Case glrcErrFileNotFound
         MsgBox "Unable to find '" & strCommand & "'"
      Case Else
         MsgBox Err.Description
   End Select
   Resume ahtRunAppWait_Exit
End Sub

To initiate it:
Code:
RunAppWait "cscript ""D:\DATA\Access\Test Refresh Form in Loop\Test Refresh Form in Loop.vbs""", vbHide

Is there a way to initate the loop with any event on the form start (Open, Load, Resize, Activate, Current)?
 
Last edited:

Acke

Registered User.
Local time
Today, 20:38
Joined
Jul 1, 2006
Messages
156
I understand that English is not your first language, so I will try to make this clear. Please review your answers in your post #41 of this thread.

Your answers to question #1 and question #9 simply cannot both be correct. If you have only two PCs, you cannot enter data fast enough. Or at least that is how it appears from my side of the screen. With only two people doing data entry, nobody will have a backlog. Therefore, I continue to feel that some information is missing. I am not accusing you of any kind of lying. But I continue to believe we have mis-communicated.


It is great that you are not accusing me of lying. As much as the support I am receiving on this forum is valuable, nothing is worth taking the offense. It is great that we can run the civilized conversation. I agree that there is a lot of misunderstanding.

If by "backlog" (one of the words I am not sure I understand fully) you refer to delay in the appearance of information between PCs, then, as mentioned in the answer to question #9, the delay is insignificant in the case of tasks. We can wait even a full minute before the task appears on the other computer. The speed of refreshments will be important later, with the chat. With the chat, the refreshments need to be instant if you want to run a meaningful conversation.

Further, we are using a timer now for the tasks. The speed of refreshment is more than satisfactory with the timer. I want to replace the timer, not because of speed, but due to other setbacks this function implies, as explained in previous posts.

I hope I understood your comments well this time and that the answer is appropriate. If not, please rephrase the question and I will be happy to respond.

@Pat Hartman - regarding messaging apps, which you mentioned in passing, they usually work based on using WinSock methods to establish a network channel to a chat partner (or chat room). Their events are network I/O completion events, usually. They definitely are NOT using SMB in the "file" sense - though I believe if you can specify the intended recipient as a UNC network device, SMB WILL act as a file-oriented comm link, where the unit of transmission is a text line, with or without attachments.

You are correct. It is complex for me and it will take some time to understand it and evaluate if that method will be used. But surely is intriguing.

At the moment, I am enthusiastic to get running the loop Isaac suggested. It seems like the simplest and most efficient solution.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 14:38
Joined
Feb 28, 2001
Messages
18,026
The normal way chat programs operate like this involves use of a Windows network socket (commonly named as "Winsock" when you see it in articles on the web). I don't know how far you want to go with this, but here is the problem you face.

As you say, that task list can be updated / requeried / refreshed fairly slowly with no harm to your task management procedures. However, a chat application is not nearly so forgiving with regard to speed. And there is your issue. IF you want to write this using all Access / VBA then you need events to drive things - and the Access environment will not provide you with any. You must take action yourself to DO something that will then trigger a usable sequence of events.

Remember that we are not writing a MAIN module when we write event code. We are writing subroutines for which Access itself is the MAIN module. We cannot see the internals of Access code so we cannot tell exactly how to get Access to cooperate - if we ever could anyway.

Most Access events are RESPONSIVE events, not spontaneous events. Timers are the exception. You want to avoid timers. The sad truth is that without them, in an otherwise quiet system where you are waiting for action, there will be no usable events AT ALL until someone touches a mouse or keyboard to DO something. Access is PASSIVE except for the timer. It is the nature of that interface.

We have had a few cases where someone struggled to "split" the attention of Access to do multiple things at once, but another sad truth for your project is that the Access front-end and back-end are single-threaded. Yes, multiple events can theoretically fire - but Access uses event queues to process your events in linear order because, so far as we know, there is only a single thread for the code processor that executes VBA for you. In practical terms, this means that if you are updating a form, you are not (in the same app at the same time) updating a chat window. This event behavior is often described as "linearized." Due to the Gigahertz speed of computers, it all LOOKS like it is simultaneous - but it is not.

If you wrote code that could listen for a Winsock connection, that code would have to enter an I/O wait state inside your code, which would then lock up that part of the code from ever doing anything else until you get a connection. That is because Access won't listen for you. YOU have to set up your listener to passively wait for a message. This listener with a pending socket READ operation might even prevent you from shutting down your PC - which happens if any I/O device still has pending requests.

That chat is a tricky piece of code. This is why I suggested earlier that you might wish to seek a separate commercial chat app. Not because I doubt your tenacity or skills - but because in engineering terms, this is an expensive bit of work. Time is money and this would be a very difficult app to get right if you limit yourself to Access.
 

Users who are viewing this thread

Top Bottom