I have set up a multithreading routine in Access which opens up several Access files at the same time and executes a specific function in each file. The files act in parallel. I would like to send Debug.Print messages to the main file which initiates the multithreading.
I'm not sure if it can do this or if there is a better solution.
You have a number of processes, each working on their own part of the bigger picture.
The immediate pane of the "main" IDE belongs to that instance, in that process; you could Alt+Tab and then Alt+F11 to bring up a VBE instance in any/every instance to view that instance's Debug.Print output.
What you want is something like an ILogger implementation that writes the log entries in a dedicated database table: a DatabaseLogger, for example.
You replace Debug.Print with Logger.Log calls; that way you let the database server deal with the multiple incoming threads, and depending on the RDBMS you could even setup a job to cleanup, aggregate and/or archive the older log records. Or whatever, as long as it's not logic I need to care about in VBA code.
Writing to another VBE's immediate toolwindow involves low-level, cross-process Win32 wizardry that doesn't need to clutter up an otherwise nice & tidy VBA project. I wouldn't bother with that, there are simpler solutions.
You could create a PublicNotCreatable UserForm (not an Access Form) in the main application, and pass a reference to it, to all of the parallel apps. Add a custom method to the UserForm, like 'PrintLine(message as string), and each app can callform.PrintLine("app is running")`?
You could then have the UserForm display the output, or possibly, have the UserForm output the message to the Immediate window of the main application.
Related
This question references some events raised by the VBIDE. I'm looking for an event I can hook that is raised whenever an Access object is saved (form, querydef, module, class module, etc.).
If such an event is unavailable, I'm looking for workarounds. A project-wide save event or a code module change event would be acceptable alternatives. Perhaps there is some creative way to be notified when one of the "msys" system tables is updated and, ideally, which row.
Worst-case scenario, it looks like I can iterate through the CurrentDb.QueryDefs .LastUpdated or CurrentProject.AllForms/.AllModules/.AllReports .DateModified property and just poll it on some interval, but I would like to avoid that if possible.
There aren't any events that you can catch, but there is probably a better solution than polling the database objects.
The Database Window (that contains all of the tables, queries and other objects) will receive Windows messages when certain things happen in the User Interface. A quick look with Spy++ shows that the Database Window appears to receive a WM_ENABLE message when an object is saved. If you can trap that message using Win32, you might have the beginnings of a reliable "event".
Note that VBA UserForms can be used in Access Projects, but they don't appear in the Database Window, so that might be a problem.
Also, anything that programmatically changes/adds/deletes database objects might not trigger an automatic Database Window refresh or message.
END GAME: A user saved Workbook opens and mirrors code from a target file.
I am trying to create a simple VBA application that has an Excel front-end and an Access back-end. There will be multiple users who would have the option to save the front-end Excel piece anywhere they desire.
I would like to know the most efficient way to be able to update macros in all user instances when I need to push updates.
Essentially, I would like to mirror code from a "global" file on Workbook_open. In the past I did actually set code to open a separate workbook and run code (dim x as workbook, open, app.runmacro and etc.), But I think that is not really the most efficient way to do it.
Four possible solutions pop to mind for this (other than your option of having an intermediary workbook), there are likely others:
Treat the Workbook as purely an interface, and move the code to the
Access database and have it accept the Workbook as a parameter if
needed. The advantage would be the code could be maintained in one
place (Access), but it would have two main disadvantages. Each user
would need to have Access installed in order for it to instantiate
the application to call methods on, and it would lock in your
"interface" - that is, changes to how it calls Access macros would
still require Workbook updates.
Create a canonical Workbook and have the user Workbook version check
against the canonical Workbook when opened. If the version is
different, open the new one, move all of the data to it, delete the
old one, and save the new copy to the same filename as the old one.
The main disadvantage of this method would be ensuring that old code doesn't run might be difficult, as you would need
to take measures to prevent situations where the user could abort
the update process and still have a working copy of the old code.
Automate the VBE (see this answer for implementation details -
there are numerous resources on how to do this). Depending on how
you wanted to do this, you could either store the current modules as
files and import them, or store the code in the database itself and
query for it. The main disadvantages of this method are that the
VBE can be fickle about changing code that is actually running. I'm
not sure that I'd trust it to change it's own implementation. You
would also need to allow access to the VBE in each user's security
settings, which may pose a security threat.
Store the location of the Workbooks themselves in the database, then
push out updated copies with external code. The Workbook would
report it's filepath when opened, and if it wasn't already recorded
in the database, check to see if it was the most current version,
and then write a record for itself. This has the disadvantage of
only being able to inform the user that they don't have the current
version if they (for example) move the Workbook in Explorer and
don't open it until after your push.
Note that these are all "pull" type as opposed to "push" type solutions with the exception of the last one. Regardless of the method you use for version checking, any push solution is going to share the disadvantage of number 4 - there is no reliable way to make sure that a push catches all the invalidated versions.
I am currently writing an utility that takes two different sets of data from an excel document and sends it to two different web services. Each set of data has it's own button that sends the data to the web service. When the a button is clicked, the corresponding web service then returns data depending on the input values.
What I am trying to do is so that this utility can be distrobuted and used by a wide variety of people. What they are going to do is they are going to be synchronizing there particular cells of their own excel document to the corresponding cell in my utility. Using simple excel formulas. For example:
c:\temp\[book1.xls]sheet1'!a1
Now what I am trying to do is automatically "click" the button, or update, on my utility when the user links their cell to its corresponding cell on my utility.
I have tried the selection change event on my page. But it doesn't actually process until my utility is active, or clicked on.
Is there a way to make my utility automatically update? It would be especially awesome if somehow it did this while my utility was closed. So when the user opens it it is already filled with their information, and the outputs are correct.
The requirements:
you need to guarantee that when a user is using excel your app can collect the data. Your app may not be running at the time. You need the Worksheet_SelectionChange() event to fire automatically not just when your app is active.
Solution:
Basically in order to guarantee that the Worksheet_SelectionChange() is running all the time, and in order to guarantee that whenever the user opens an instance of excel you are able to collect and process the data/formulas entered into the particular target range address you need to wire up the selectionchange event inside of a VB.NET Excel COM Addin. There are several ways to do this, but since your using VB.NET your best off using the newest approach which is building a VSTO COM Addin.
There are numerous other questons available on how to best build a VSTO addin (some in C# some in VB.NET but all this information is exactly the same for both, just different syntax).
So you will need two projects. Your existing one, plus a Excel VSTO addin (which you can also do in VB.NET).
Now inside the selectionchange event you should make sure that your code handles the target range correctly; ie. make sure you check for non-contigious groups of ranges with a selection... A1:B1;D2:E2 and copy the data to your app. You may consider using a format such as xml to serialise the latest data from excel so that if your app is not open at the time, it can deserialise and read back the data stored for it the next time it is opened. I guess it really depends how your handling the data (i.e. is it for loading into a datagrid?) and whether you are going to do further processing and store it somewhere else later (in which case maybe you can put it straight into a database from the addin in excel).
I've created a small application that basically reads and writes to a single Excel.exe process. It's basically a timer that records the time I use on projects and then store it in an Excel sheet. This works great, however, I've noticed that if I open Excel manually, work on some sheets and whatnot, save and exit etcetc, the process my software use gets broken or something. The same thing that happens if I manually close the excel.exe process and my software doesn't "know".
So I was wondering if it's possible to protect the excel.exe process somehow? To make sure it can't be closed or tampered with in the meantime?
Let me suggest an alternative approach that does not require you to have an Excel process running all the time (after all, this also consumes a lot of system resources):
Let your application record your information. Every now and then -- for example, after a work entry has been finished or a specific time has elapsed -- open the Excel sheet, write the data, and close it again (also closing the Excel process that you are automating). This save operation should not take more than a few seconds and it will (mostly) prevent the problem you are experiencing.
In fact, since Office automation is always a bit painful, an even better way would be to output your data without requiring an Excel process. To do this, you could use
one of the third-party Excel libraries available for .net,
a CSV or HTML file, which can be opened by Excel, or
open the Excel file as a database with ADO.NET.
You cannot protect a process, but you can check the process.HasExited property to find out whether the process has terminated and take action based on that.
Add an exception handler. Either call non-throw methods if possible.
I have a routine that examines thousands of records looking for discrepancies. This can take upwards of 5 minutes to complete and although I provide a progress bar and elapsed time count, I'm not sure I want to encourage folk pressing ctrl-break to quit the report should it be taking longer than expected.
A button in the progress bar won't work as the form is non-modal, so is there any neat way of allowing users to quit in this situation?
You need DoEvents and a variable whose scope is greater than the scope of what you're running. That is, if it's just a procedure, you need a module level variable. If it's more than one module, you need a global variable. See here
Stopwatch at DDoE
Normally, the VB engine will tie up the processor until it's done. With DoEvents, however, VB allows the processor to work on whatever is next in the queue, then return to VB.
I don't think there is a way to do it like you would want it to work. VBA is a scripting language so when you start your procedure, it's gonna run until it's done. If you had another button somewhere that even WOULD let you click it while the original procedure was running, I'm not sure how you would reference that procedure and stop it.
You could do something like ask the user if they want to contine, but that would make it run even longer.
Also you could have your procedure check for a condition outside of Excel and keep running as long as it's true. Something easy might be check if a certain text file is in a folder. If you wanted the procedure to stop, open the folder and move the file. On your loop's next iteration, it wouldn't see the file and stop running. Cludgy, inefficient, and not elegant, but it would work. You could also have it check a cell, checkbox, radiobutton, basically any control in another Excel sheet running in another instance of Excel. Again cludgy.
CTRL+Break works. Accept it and move on. One neat trick about that though, is that if you password protect your code and they hit CTRL+Break, the debug option is unavailable and they will only get Continue or End.
If this is code that is run frequently, have you considered scripting something that runs it during times when a human is not using the computer? I used to run telnet screen scraping macros that would take hours to go through our widgets, but I always had them run either on a separate computer or when I wasn't there (nights/weekends).