Go Back   Access World Forums > Microsoft Access Discussion > Modules & VBA

 
Reply
 
Thread Tools Rate Thread Display Modes
Old 06-03-2019, 01:38 AM   #16
sonic8
AWF VIP
 
Join Date: Oct 2015
Posts: 292
Thanks: 52
Thanked 87 Times in 80 Posts
sonic8 will become famous soon enough
Re: DLL with callback problem

Quote:
Originally Posted by nonlinearly View Post
Just read my previous response
I did already. - I don't see how it is relevant to my comment.


Sure, there are components available for other languages, like the FileSystemWatcher for .Net, which already includes the synchronization of its worker threads back to the UI thread. If you use one of those, I'm quite confident that you will not experience Access crashing when handling its events.


If you don't use such a component, it's your responsibility to take care of synchronization. - If this is just "confirming your question", then you should now act upon this confirmation.

__________________
A professional Access developer tool:
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
sonic8 is offline   Reply With Quote
Old 06-03-2019, 04:54 AM   #17
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 15,079
Thanks: 100
Thanked 1,891 Times in 1,727 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
Re: DLL with callback problem

OK, I stand corrected - but the research that I did, including going deep into my Win32API books, didn't show me anything useful. You found something that I could not find, probably because you and I asked Google different questions. But I stand on the comment that what you want is unusual enough that knowledge of it is uncommon.

My comments on VBA being pseudo-compiled and then interpreted are your answer to why you have trouble in that environment. And I did suggest that truly compiled languages might be better suited to what you wanted to do. Which seems consistent with your remarks in post #14.
__________________
I'm a certified grandpa (3 times now) and proud of it.
Retired over one year and survived being home all day with the wife. She must really love me.
If I have helped you, please either click the thanks or click the scales.
The_Doc_Man is offline   Reply With Quote
Old 06-03-2019, 06:04 AM   #18
nonlinearly
Newly Registered User
 
Join Date: Jun 2012
Posts: 21
Thanks: 3
Thanked 0 Times in 0 Posts
nonlinearly is on a distinguished road
Re: DLL with callback problem

Quote:
Originally Posted by The_Doc_Man View Post
OK, I stand corrected - but the research that I did, including going deep into my Win32API books, didn't show me anything useful. You found something that I could not find, probably because you and I asked Google different questions. But I stand on the comment that what you want is unusual enough that knowledge of it is uncommon.
A simple example from Microsoft ready to be compiled and run:

https://docs.microsoft.com/en-us/win...-notifications

nonlinearly is offline   Reply With Quote
Old 06-03-2019, 10:24 AM   #19
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 15,079
Thanks: 100
Thanked 1,891 Times in 1,727 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
Re: DLL with callback problem

OK, researched it a bit more. Thanks for the link. And for the record, this doesn't tell you that an arbitrary file was changed. It tells you that a directory was changed and you have to work a bit more to work out what file in that directory actually changed. But it is an interesting technique.

Technically, this notifies you of a change if and only if the program making the change closes the file, in which case you could set up your "wait handle" to wait for FILE_NOTIFY_CHANGE_LAST_WRITE (change last write date on any file). So that means it is only going to tell you about this change after the fact. If there is a delay, you don't find out right away until the change is actually committed.

Of course, since you can't interfere with the file while another program has it open, that is about as close to "real-time" as you are going to get. But let me ask this: Once you know that file X has been updated, how much time do you have before you must start working on it? Milliseconds? Seconds? Tens of seconds?

Because it seems to me that if you were willing to go to this trouble to write C++ code, you could have built a C++ main program that waits for the file and when appropriately triggered, it launches something. Which COULD be an instance of your database with a Macro (using command-line X:macro-name) to run the code to process your file once it has been updated. Having Access wait for something is not what Access wants to do, but having a stub to launch Access might be just as good if you don't mind the implied slower response of a couple of seconds before it responds.
__________________
I'm a certified grandpa (3 times now) and proud of it.
Retired over one year and survived being home all day with the wife. She must really love me.
If I have helped you, please either click the thanks or click the scales.
The_Doc_Man is offline   Reply With Quote
Old 06-04-2019, 03:19 AM   #20
nonlinearly
Newly Registered User
 
Join Date: Jun 2012
Posts: 21
Thanks: 3
Thanked 0 Times in 0 Posts
nonlinearly is on a distinguished road
Re: DLL with callback problem

Quote:
Originally Posted by The_Doc_Man View Post
... this doesn't tell you that an arbitrary file was changed. It tells you that a directory was changed and you have to work a bit more to work out what file in that directory actually changed. But it is an interesting technique.
The directory has only one text file. Τhe file we are interested in.
Quote:
Originally Posted by The_Doc_Man View Post
Technically, this notifies you of a change if and only if the program making the change closes the file, in which case you could set up your "wait handle" to wait for FILE_NOTIFY_CHANGE_LAST_WRITE (change last write date on any file).
The link is an example. It doesn't mean that I use it as is. Of course I have changed the wait handle to FILE_NOTIFY_CHANGE_LAST_WRITE.
Quote:
Originally Posted by The_Doc_Man View Post
So that means it is only going to tell you about this change after the fact. If there is a delay, you don't find out right away until the change is actually committed.Of course, since you can't interfere with the file while another program has it open, that is about as close to "real-time" as you are going to get.
There is no delay. The program that changes the contents of the text file close the file immediately after the changes.
Quote:
Originally Posted by The_Doc_Man View Post
But let me ask this: Once you know that file X has been updated, how much time do you have before you must start working on it? Milliseconds? Seconds? Tens of seconds?
zero time... or in the worst case Milliseconds... or as soon as possible
Quote:
Originally Posted by The_Doc_Man View Post
Because it seems to me that if you were willing to go to this trouble to write C++ code, you could have built a C++ main program that waits for the file and when appropriately triggered, it launches something. Which COULD be an instance of your database with a Macro (using command-line X:macro-name) to run the code to process your file once it has been updated. Having Access wait for something is not what Access wants to do, but having a stub to launch Access might be just as good if you don't mind the implied slower response of a couple of seconds before it responds.
This has nothing to do with our business requirements. We can not change the way we do business due to the inability of software to face a situation.

Thanks for your analysis but has nothing (or little) to do with the problem I have already described. The problem is how can I use this code to a separate thread with a callback to vba that uses UI elements of MS Access Form without crash. I had just removed the details not to mislead someone.

I think that the only way is to make a COM component that is more robust when we have to deal with communication between different applications that maybe have been written in different technologies (like mine) but I don't know how to make a COM component.

Last edited by nonlinearly; 06-04-2019 at 03:25 AM.
nonlinearly is offline   Reply With Quote
Old 06-04-2019, 05:28 AM   #21
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 15,079
Thanks: 100
Thanked 1,891 Times in 1,727 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
Re: DLL with callback problem

Quote:
I don't know how to make a COM component.
I have not seen anything on that topic either. Sorry I can't offer you anything useful.
__________________
I'm a certified grandpa (3 times now) and proud of it.
Retired over one year and survived being home all day with the wife. She must really love me.
If I have helped you, please either click the thanks or click the scales.
The_Doc_Man is offline   Reply With Quote
The Following User Says Thank You to The_Doc_Man For This Useful Post:
nonlinearly (06-04-2019)
Old 06-04-2019, 09:04 AM   #22
sonic8
AWF VIP
 
Join Date: Oct 2015
Posts: 292
Thanks: 52
Thanked 87 Times in 80 Posts
sonic8 will become famous soon enough
Re: DLL with callback problem

Quote:
Originally Posted by nonlinearly View Post
The problem is how can I use this code to a separate thread with a callback to vba that uses UI elements of MS Access Form without crash. I had just removed the details not to mislead someone.

(As mentioned before, my knowledge of C/C++ is limited to almost nothing.)
So, as it appears, there is no (simple) mechanism in C/C++ to invoke a method on another thread.



If I had to make things work the way you want them to be, I would ...
  • Create and open a hidden form in Access,
  • Pass the forms window handle into your C/C++ method,
  • Subclass the the form's window proc in the DLL code,
  • (maybe, instead of the previous 3 steps, just create a window in the DLL)
  • Start your worker threads,
  • If any worker thread wants to raise an event, it posts a message to the forms message queue,
  • The form's window proc handles the message and invokes the callback function.
I guess, this is how updating the UI is supposed to work in a multi threading environment, unless there are more sophisticated mechanisms available.

Please note, using a window message queue is polling by design, as is the example you posted.

__________________
A professional Access developer tool:
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
sonic8 is offline   Reply With Quote
Old 06-11-2019, 07:50 AM   #23
sonic8
AWF VIP
 
Join Date: Oct 2015
Posts: 292
Thanks: 52
Thanked 87 Times in 80 Posts
sonic8 will become famous soon enough
Re: DLL with callback problem

The topic of multithreading with VBA was on my list for quite a while.This thread finally pushed me to record a video on that topic. - It's not really a solution to the issues raised here, but it covers several sidelines touched by this this thread.

So, I think is justified to post a link here:Multithreading with VBA?
__________________
A professional Access developer tool:
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
sonic8 is offline   Reply With Quote
Old 06-11-2019, 11:41 AM   #24
The_Doc_Man
Happy Retired Curmudgeon
 
Join Date: Feb 2001
Location: Suburban New Orleans, LA, USA
Posts: 15,079
Thanks: 100
Thanked 1,891 Times in 1,727 Posts
The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold The_Doc_Man is a splendid one to behold
Re: DLL with callback problem

Watched the video. One issue stood out. The difference between hard compile and pseudo-code compile is razor thin from the compiler viewpoint but not even close from the execution viewpoint. VBA does not produce executable code.

https://analystcave.com/vba-compiler-add-in-to-vb-net/

VBA pseudo-compiles code but since it is not Intel "86" family code, it cannot be executed in the strict sense of just putting the starting address in the hardware PC register (the ultimate GOTO). It can only be processed by a pseudo-code simulator, emulator, or interpreter depending on the specifics. (And yes, those three methods ARE different.) I don't claim to know which of those three options actually applies in the case of VBA, but speed tests clearly show that loops are not true-executed. They are pseudo-executed. This is the basis for many claims about the preference for running SQL vs. VBA, because at least SQL's underlying code is true-compiled. A recordset loop, though it has to do essentially a similar thing, isn't true-compiled.

The VBA execution environment is processing the instructions in sequence. If a hardware interrupt occurs, it occurs in the VBA processor's code and the address to which the interrupt returns would be inside the VBA processor, not the pseudo-code. It is interesting that as long as you don't leave the raw computational environment, you can parallel-process stuff like strings - probably because the string paradigms are re-entrant. I suspect this is because the O/S also uses the string library and thus it would HAVE to be re-entrant to be worth a damn. And I have no idea how it knows that you have pseudo-code as the target of your AddressOf in the CreateThread call. But apparently it does.

The video is absolutely correct that you can write true-compiled .DLL code to be RE-ENTRANT (thus able to be called from multiple threads in parallel). If you don't write it re-entrantly, you can trip over your own feet, usually due to the "improperly shared resource" issue. This ties in with a discussion I held a long time ago about whether VBA was truly object-oriented. You point out that if you diddle with an object, things go south quickly. That implies that the COM objects were not written re-entrantly and thus are not fully object-oriented either. I'm going out on a limb here to say that part of the problem is that you don't get a new copy of the code for NEW class object methods. If you did, the code would indeed be re-entrant. Instead, I think the Access environment shares the same compiled code among all instantiations of the same class. THIS IS A GUESS based on observed behavior!

It is equally interesting that you can write recursive code in VBA as long as you only use locally defined variables inside the routine - because all of the local variables go on the program stack in a context block. Recursive code is necessarily also re-entrant.

By the way, the reason for having issues with your earlier code in a 2016 environment might be explained in this article:

https://docs.microsoft.com/en-us/off...tions-overview

Something has changed between then and now, probably related to the difference between 32-bit and 64-bit code. Is there a chance that your original code was Ac2007, not Ac2010? Because it appears that the code compatibility change occurred with the release of Ac2010.
__________________
I'm a certified grandpa (3 times now) and proud of it.
Retired over one year and survived being home all day with the wife. She must really love me.
If I have helped you, please either click the thanks or click the scales.
The_Doc_Man is offline   Reply With Quote
Old 06-16-2019, 01:26 AM   #25
sonic8
AWF VIP
 
Join Date: Oct 2015
Posts: 292
Thanks: 52
Thanked 87 Times in 80 Posts
sonic8 will become famous soon enough
Re: DLL with callback problem

@The_Doc_Man: Thank you very much for these insights and valuable additional information.

I've got the gut feeling that you missed something in your remarks regarding pseudo-code and the implications of the VBA runtime executing the code instead of the code itself being executable. - I cannot put the finger to it. I have to admit; my knowledge of these low-level mechanisms is insufficient to discuss these matters.

Quote:
Originally Posted by The_Doc_Man View Post
I'm going out on a limb here to say that part of the problem is that you don't get a new copy of the code for NEW class object methods. If you did, the code would indeed be re-entrant.
No, that is not the case. Class instances are isolated from each other and the code of class modules is re-entrant (if you wrote it that way). It works to use multiple class instances in a single threaded environment, and it works as well with multiple instances in a multithreaded environment. I said in the video that you shouldn’t touch classes because that significantly increases the risk of Access/VBA crashing, but not because the instances aren’t isolated/re-entrant in general.

Quote:
Originally Posted by The_Doc_Man View Post
Something has changed between then and now, probably related to the difference between 32-bit and 64-bit code. Is there a chance that your original code was Ac2007, not Ac2010?
No chance whatsoever. I actually wrote the code in Access 2016 originally and noticed that it was crashing left, right, and centre. I was about to scrap the whole project when I ran the code in Access 2010 and noticed it runs there without crashing.

__________________
A professional Access developer tool:
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
sonic8 is offline   Reply With Quote
Reply

Tags
api , callback function , dll , threading

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
can't run callback function 'onribbonload' Bechert Modules & VBA 1 11-28-2014 09:34 AM
Access Ribbon Callback msadiqrajani Modules & VBA 1 05-11-2011 02:22 AM
Setting a Callback!!!!!!!! Dazzle Forms 4 06-23-2008 03:09 AM
Callback function not displaying data ray147 Modules & VBA 0 12-13-2005 05:58 AM
Balloon Callback charityg Forms 3 06-01-2001 06:47 AM




All times are GMT -8. The time now is 06:43 AM.


Microsoft Access Help
General
Tables
Queries
Forms
Reports
Macros
Modules & VBA
Theory & Practice
Access FAQs
Code Repository
Sample Databases
Video Tutorials

Featured Forum post


Sponsored Links


Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
(c) copyright 2017 Access World