I am developing an excel sheet which has lots of ActiveX elements in it.
I am not using UserForm and all the data is loaded when an activeX button is pressed.
At this point a hidden excel app is created where various actions are performed.
This new app is then combined with other data etc etc.. based on what the user is doing on the front-end with the provided ActiveX controls.
My problem comes when the "project is reset", where all the objects are released from memory and everything.
If this was a user form I would have implemented "on terminate" event where I would close hidden all workbooks that I have used, basically clean after myself.
However this is not a userform and there is no way to detect when the "project is reset"(as far as I know) so the hidden excel app that I've created remain open but nothing points to it.
If I go to the task manager i see various "EXCEL.EXE" and the number of those is basically the number of times I have run the tool.
So, is there any way for me to detect when VBA is about to "stop the project" in the same was as there is "terminate" for user forms so I can delete unsused stuff and reset elements in the spreadsheet?
Thank you!
I have found that there is no corresponding event to catch this.
Best way to handle this is to create a hidden userform object which will "hold" all global variables and objects that I define. I can then implement a UserForm_Deactivate event to catch when the form is exiting and clean up after myself.
Related
I decided to "tweak" an existing database to further manage multiple sources of income.
I copied the working database and created a "modification copy", just in case I messed things up horribly.
In the modified version, I have a button on a form (in fact, two different buttons with similar macro properties, just directed to do the same function to different reports.
The properties are your standard macro with an openreport, and a "where" condition.
Here's the problem. The macro has worked in the past, and continues to work on my "pre-modification" operating database.
On the modified database, after ensuring all the parameter elements are entered correctly, I can change the "view" to report view, and the macro seems to work just fine until I close the database.
As soon as I open the database, the buttons produce an error. See pic below.
The only way I seem to be able to resolve this odd button macro issue is by going into design view and adding a new button. I've discovered...I don't even need to embed a macro, just adding a new button seems to renew the macro operation...until I close and reopen the database. Then, I have to add a new button again to get the open database's macro to operate.
I can delete the new button added, and still have the macro buttons work, until I close and open the tweaked database.
I have zero VBA coding knowledge. I use Access's macro building tools and typically have to visit sites like this if I need to learn a new "trick" to get my database and it's various tools to do something.
I recently explored with the "subform" that can be seen above in the open form pic with the error message. My guess is that maybe that subform is somehow causing my macros to continuously fail???
Thanks for any help!
My company creates workbooks for clients that contain ActiveX controls (in most cases we need the extra functionality as compared to Form Controls). When we create them, they work fine on our end, but when we zip them up and send them to our clients, they open the WB and the ActiveX controls are no longer ActiveX controls, if you right click it, it behaves like a picture.
I feel like this is due to the MS ActiveX debacle. I have had them run the Fix It and making sure all the MS Office components were closed, and had them reboot, but still nothing.
I am pulling out my hair, and have asked on other forums if anyone else has had this issue, and what they have done to fix it. Thanks in advance.
Could you please check in client system whether macros and active x controls are enabled in Trust center setting?
https://support.office.microsoft.com/en-us/article/Enable-or-disable-macros-in-Office-documents-7b4fdd2e-174f-47e2-9611-9efe4f860b12?CorrelationId=fe6a4d24-f4d9-4c6b-afa0-40d2828ad22e&ui=en-US&rs=en-US&ad=US
use above link if needed.
Try closing excel and deleting the .EXD files from your computer.
Source: http://www.mrexcel.com/forum/excel-questions/296750-command-button-turned-into-image.html
While saving the Excel document, save it as "Macro enabled workbook".xlsm
In my case, the worksheet prompts a non responsive error sometimes. When I reopen it, Excel repairs it and turns all active X check boxes (sometimes drop down list and command buttons) into images. It happened many times and I had to spend a lot of my time recreating them and liking to cells.
I experienced a similar problem when Excel repaired a file; this may be similar to what's happening with the Zipped file. FormControl Buttons don't appear to have the same problems but I see you want to keep the additional functionality of the ActiveX Control.
You may be able to make use of the code I created by inserting one Form Control button that runs the Sub RepairMissingButtons() that your clients can press to restore the images to CommandButtons. This currently fixes buttons for any selected sheets, so you'd want to first identify which sheets need to be selected (or add a form control button on each sheet that needs the repair done).
You'd need to modify the Sub CreateButton() to meet your needs (currently requires hard-coding the Caption, BackColor and any other ActiveX properties that may have been lost by the button being converted to an image):
Reverse Excel ActiveX command buttons erroneously converted to images after corrupted file repair
Having this problem, activex controls sometimes change to pictures.
Many places around the internet the answer is: Use form controls, well as far as I can tell form controls don't actually do anything useful.
Even Microsoft's support site says, recommend using form controls, how can that be the answer. being able to interact with VBA is as far as I can tell the only reason to use Microsoft applications instead of free ones.
Similar to Errors when calling certain Excel VBA macros from C#, I want to implement an error handler that will catch VBA errors and return gracefully.
Basically, I'm opening up an arbitrary macro workbook in Excel, and if the macro fails (i.e. you get a VBA error dialog with "end" and "debug" buttons), I want my application to handle it internally instead of using the VBA's dialogs. This is primarily so that a buggy book won't freeze processing (I'm using a queue of sorts to process multiple workbooks).
I already know about the DisplayAlerts=False property, and On Error Resume Next inserted into each routine, but I don't want to need to inject this into everything (especially since some of these workbooks may already modify the mentioned settings and reset them mid-routine!)
My best idea so far is to write up some sort of process watcher that looks for windows titled "Microsoft Visual Basic" and sendkey an "E" (to click the end button).
I've read in a few places that there's a property called Application.BreakOnVBAError that can be set to False, but it doesn't seem to exist in the interop assembly.
With the help of pinvoke.net and MWinAPI, I've been able to enumerate all of the windows created under Excel's process ID, which I can then drill down into to discover the elements of the dialog (if it's a dialog such as the Microsoft Visual Basic dialog).
Since it's an automated instance, the main window is hidden so the only thing that should show up are message boxes and the VBA error box, which I can then send keyboard input messages to to End the script when necessary.
Of course, this method never hits the "Debug" button so I should never see the VBE windows, but just in case I handle that too.
Source code available upon request?
I need to update an Access VBA app with around 30 forms in it.
I have to amend a screen that seems to have been set up right at the start of the app, it uses a lot of SQL tables. Is there an way of finding my way to the start of the code?
I come from a procedural coding background and I am unused to code that doesn't have a start and an end; I also know a bit of VB, some ASP, some .Net and general computing.
When something "automagically" happens upon opening an Access database, it is almost always because
A "startup form" has been specified. (In Access_2010 that's done in File > Options > Current Database > Display Form.) ...or...
The database has a Macro named AutoExec which is automatically run when the database is opened (unless you bypass it by holding the [Shift] key down while opening).
In addition to #Gord's answer, there's a few things you need to know. I'm going to give you the quick & dirty version.
First, there's 2 types of code in Access. VBA & macros. Sometimes what's called a macro, is really VBA.
In Access, a macro is a set of instructions to do something to the database. It's very limited in what it can do. These are often used by novices who don't know how to program in VBA.
VBA is the real powerhouse behind the scenes. It can do everything a macro can do, but a whole lot more.
Access uses an Event-Driven / Object-Oriented (at least close enough for this discussion) interface. Do a Google search on those meanings. But very quickly, the listbox on a form is an object. It has properties (like width), methods (add an item), and events (click on an item).
To see the code, for macros look to to your navigation window to your left. For VBA (modules), look to the same window, or just press Alt-F11. VBA can be used standalone in a module, or behind the scenes of a form or report.
Once you get the hang of it, you'll find Access to be a handy RAD tool for small projects.
Good luck.
It appears that you already have found the form that opens when the app starts (if not, check out Gord Thompson's answer).
The first things that happen when an Access Form opens (the "start of the code", as you called it) are the Load and Open events.
If there is any code in this form that is connected to these events, then it's in the Form_Load() and Form_Open() functions in the code of the form.
First of all, thank you for your time and assistance in reviewing this!...
I'm trying to upgrade an Excel VBA workbook to a VSTO Excel Add-in in VB.NET using VS 2010. In the original (i.e.- VBA) version I have a modeless UserForm (called frmMain) that floats on top and is visible at all times while the user is still within the Excel application, but is not visible if the user moves to another window outside of Excel.
For example, within Excel the user can click on any worksheet tab, select any cell, etc. and the UserForm is still visible. This is exactly how I'd like it.
The problem is, that in the new VSTO add-in, I can not get the Windows form to mimic this same behavior.
I use frmMain.Show() to show the form as a modeless form, but the moment the user clicks an Excel worksheet (i.e.- activates a worksheet) the form becomes hidden behind the worksheet.
I can manually Alt-Tab to bring the form back into view, but I need it to always remain in view - floating on top of the Excel worksheets so long as the user hasn't left the Excel application.
I tried various things, including setting the form to TopMost, however, that causes the form to be TopMost everywhere - including outside of Excel. Worse than that, if the user does anything that would normally result in Excel's launching a dialog box (e.g.- closing an open workbook, raising the alert "Do you want to save the changes...") the alert dialog box itself is hidden and inaccessible behind the frmMain form (since the frmMain is TopMost).
How can I get my form to behave in the desired way (i.e.- the same way it did in VBA)?
Thanks!!!
Rob
You should take a look at Custom Task Panes which can be docked or floated within the Excel application. You could also look into the COM interfaces for a lower level connection (see related SO Post) - although Task Panes are really what this type of behavior was intended for.
This method might work (worked for me):
Create a worksheet_selectionChange event handler inside your form class
Put these lines in this event handler:
Dim FormHandle As IntPtr = Me.Handle
Me.Visible = False
Me.Show(NativeWindow.FromHandle(FormHandle))