Are there MS Access equivalents to "PostEvent" and "PostFunction" in PowerBuilder?

[AEL Ventures]

Greetings! I am a seasoned PowerBuilder developer now migrating to MS Access as quickly as possible due to new development opportunities. A very powerful and useful feature in PB is support for "PostEvent" and "PostFunction" which allowed another event or function to be queued and fired after the current script was completed.



This is a different ability than simply calling a function as the last action in the current script. It ensures the current script is completed before the next event or function is executed. This has proven to be an extremely valuable ability when used strategically and I'm hopeful that similar functionality can be achieved in Access.

I have searched for quite some time with a wide variety of keywords but not found anything encouraging. Can this be done in any fashion in Access, either natively or perhaps with an API call?

[RayMilhon]

Not Exactly. However Access does have the Beforeupdate and AfterUpdate Events. these can be called at different levels. so if a form is updated or a single control is updated these Events are called.

[AEL Ventures]

Thanks for that tip! I'm looking at broader usage and not related to forms or database updates directly but really just the ability to queue a "future" event at any time when the current script concludes.

[RayMilhon]

I am not a power builder user so am unfamiliar with what you mean by current script. It sounds similar to an access Macro which performs a number of Events in sequence and can be set up to run when Access is loaded (Autoexec) Or in response to specific events within your Database. You might want to look at Macros and VBA Functions that can also be called from a macro or query.

[AEL Ventures]

I'm familiar with macros and VBA and this would actually be an option with VBA. By "current script" all I mean is the current VBA in any given event. Perhaps this will help:

Private Sub cmdTest_Click()
' (VBA Code Here)
' Now queue the s_Demo subroutine to be executed AFTER this subroutine completes all its work.
' "PostEvent" is the PowerBuilder method and I'm seeking the VBA equivalent
PostEvent s_Demo
End Sub

Private Sub s_Demo
' This subroutine will be executed after cmd_Test has COMPLETELY finished including any local objects (within cmd_Test) being set to Nothing
' (VBA Code Here)
End Sub

[RayMilhon]

What you're looking for is call.

Call s_Demo

[AEL Ventures]

Thanks for your continued input. CALL is simply the standard method of executing a subroutine (and "CALL" is optional) which is executed immediately when the call is processed.

I am seeking to post a subroutine call (place it in the queue) which will execute after and independently of the routine which includes the "PostEvent" equivalent.

[RayMilhon]

As far as I know that capability is not within access. Maybe somebody else has an idea on how you can accomplish this.

[Missinglinq]

...allowed another event or function to be queued and fired after the current script was completed...

...It ensures the current script is completed before the next event or function is executed...

It sounds to me as if this is the main point of your question, and if so, the DoEvents command may be what you're looking for.

Access is asynchronous, which is to say, if given a series of commands, it starts to execute one, moves on to the next one and starts executing it, and so forth. It doesn't wait for the first command to be completed before starting the second one, and this can cause timing problems.

An example would be a button that runs a series of Queries where all but the first Query is dependent upon the previous Query being completed before it starts to execute. The following VBA code

DoCmd.OpenQuery "QueryA"
DoCmd.OpenQuery "QueryB"
DoCmd.OpenQuery "QueryC"

will immediately run all three, not waiting for one to finish executing before starting the next one. The answer to halting the code in this type of situation is to use DoEvents.

DoCmd.OpenQuery "QueryA"
DoEvents
DoCmd.OpenQuery "QueryB"
DoEvents
DoCmd.OpenQuery "QueryC"

DoEvents returns control to Windows, allowing QueryA to complete running before starting to run QueryB. It then allows QueryB to finish running before starting QueryC.

DoEvents is an easy, safe bet when encountering what seems to be timing issues, and may do what you need if placed between each 'event.'

Linq ;0)>

[RayMilhon]

Missinglinq is right. I've used DoEvents before but not recently and it didn't occur to me.

[DepricatedZero]

It sounds to me as if this is the main point of your question, and if so, the DoEvents command may be what you're looking for.

Access is asynchronous, which is to say, if given a series of commands, it starts to execute one, moves on to the next one and starts executing it, and so forth. It doesn't wait for the first command to be completed before starting the second one, and this can cause timing problems.

How do I enable this feature? My copy of Access seems to be single-threaded and I'm about to abandon it as the platform and move to .NET/SQL

[Missinglinq]

...How do I enable this feature...

As my example showed, in Post #9, the Command needs to be inserted immediately after any Command that needs to complete executing before running the next Command in line.

...My copy of Access seems to be single-threaded...

It's not just your copy! MS Access doesn't support multi-threaded execution of VBA code.

Linq ;0)>

[AEL Ventures]

That's a good explanation of DoEvents (which I am familiar with) but still not the solution to what I'm seeking and I'm not sure how else to describe it! I just want to be able insert an event in the queue which will not be touched until the current event is completely done.

Let me try another example: while processing the code in a form Current event, the situation requires that SubRtn1 be executed AFTER the Current event and any other normal events in the event chain. To do this in PowerBuilder, I would simply "post" the execution of SubRtn1 and know with confidence that it will run after all other pending events conclude.

This may not sound that valuable but it truly was as issues like which control has focus, etc. would not be problematic because standard events would be done before the posted routine would execute.