I'm working within Visio 2010 and I have been using my event handlers such as
Private Sub Document_DocumentOpened(ByVal Doc As IVDocument)
'Methods being called...
End Sub
For some odd reason these will no longer work when the document is opened. Nor any other of my event handlers. It happened all of a sudden and I'm not quite sure why. I noticed that it seems that Design Mode seems to be highlighted upon loading every load, even when I turn it off and save the document.
So this leads me to believe that Design mode is automatically coming on when I load the document (but I have no such code) thus preventing my event handlers to stop working. But my event handlers don't work even when I turn off Design Mode.
Please help if you have any insight.
I was able to figure out the issue. I used
Application.EventsEnabled = False
without ever turning it back to true after my code ran. I read to always turn it back on but it slipped through the cracks and before I knew it, I deleted the nonworking code along with the Application.EventsEnabled portion. So, if you ever turn the Events Handler off, be sure to turn it back on!
Thanks to anyone that was attempting to help me! Sorry for the vague question but I didn't have much else to go off of, I had just forgotten I turned Events to false earlier.
Related
Currently I have several worksheets and plenty of values that are input or equal something. However with so many worksheets "talking" to each other, this appears to be causing issues. this occurs directly when a field is changed or button is pushed as I expect it to...
but it also happens indirectly when i'm capturing the data and writing it back to the userform with something like Form.textbox.value = range("A1") triggering the change event for the textbox.
Can someone comment if this is a code structure issue? Is there a best practice for what pieces of code should be separated?
I tried the application.enableevents = False but this does not seem to work with the user form the way i would expect. I found the link below and it seems to describe my issue to a tee but I'm not understanding what they mean by putting a public value in the "userform's module" the rest of disabling it and reenabling it makes sense
Link:
http://www.cpearson.com/excel/SuppressChangeInForms.htm
Can someone dumb this down for me or give a better option? Is this common?
Thanks,
Code after adding the public variable
Module where the information causes change event to trigger
I have code stuck.
It might be in an infinite loop.
Not sure.
Is there a way to break the program to stop at the current line of code that it is running on?
I'd like to avoid shutting down excel because I want to be able to catch where in the loop it is, and by going into the code, I will be able to tell how much processing was done. I would like to break into the code, if possible.
It is stuck on hour glass.
Ctrl+Break doesn't seem to work
Seems like the running code has hijacked all the quota that cpu is giving to excel.
If there is nothing I can do now, is there something in the future I can do to where I can more easily break into the code?
I'm thinking that an intermittent wait within a loop might be a feasible solution.
In the future, include a DoEvents inside the loop. It will run a little slower, but you will be able to use Ctrl+Break to stop it from running.
Create a progress dialog when entering the loop and include a Cancel button. Within your loop check for the Cancel signal/event. This also gives you some flexibility on how you react to the Cancel - you could stop the loop and display key information in a new dialog box (for example).
Basic steps to achieve what I have described (not necessarily the most elegant or the most re-useable, but simple enough for those of lesser experience):
create a modeless (not modal) Form with either suitable labels or a progressbar item (for
visual effect). Include a public property (Boolean) for Cancel (e.g.
boolCancel)
Place a button on form and onClick set boolCancel = True
In your main code, show the form just before your problem loop.
while in your loop you can update some label or progress bar on the
form so that you have a visual indication of whether the loop is
doing something of value or if it is now simply spinning its wheels.
How you do this depends on what your loop is doing.
Also while in your loop check your boolCancel value. If true then
display any state information you want and break from the loop.
If your loop ends normally, hide/unload the progress dialog.
I have a workbook with lots of sheets and several macros. When I enter VBA and try to write a new Sub into ThisWorkbook module, I see:
"This will reset your project, proceed anyway?"
assuming, that some project is currently running.
If I press Ctrl + L right after opening the file to check the Call Stack, it just shows nothing.
I did non run any macro myself and there's not a macro, which would handle any event (as far as I checked all sheets and modules in the project) except a little sub for saving event:
Workbook_BeforeSave (ByVal SaveAsUI As Boolean, Cancel As Boolean)
but this one AFAIK should be activated only before saving, thanks to Captain Obvious.
Another mysterious thing with this book is abnormally slow filtering for structured tables, which may be cured by turning off event handler:
Application.EnableEvents = False
Since both these facts are related to Events, I guess they might be somehow connected to each other.
Updated to include comments below.
Well, the problem still exists and I appreciate any idea that may help to locate this pesky macro running totally hidden.
Hm. Anyone with any ideas?
One way to reproduce the behavior that you describe is as follows:
1) Have a public variable which is initialized in Workbook_Open()
2) Have the option Notify Before State Loss enabled (under Tools/Options/General)
In this case when you first open the workbook and try to create a sub you see the warning about resetting the project even though no macro is currently running.
If this is the case, a simple fix (if it still bothers you) is to disable Notify Before State Loss.
On the other hand, it seems that your project has more general problems. VBA projects can become inexplicably corrupt and this might be the case here. A fix which sometimes works is to export all modules, userforms, etc., delete them, and then reimport them. Rob Bovey (a highly respected VBA guru) has written an add-in called Code Cleaner to automate the process. I haven't used it personally but it might be worth a try.
I'm having this InvalidOperationException
An error occurred creating the form. See Exception.InnerException for
details. The error is: Object reference not set to an instance of an
object.
pointing at this line of code:
Private Sub BeginningBalancesToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BeginningBalancesToolStripMenuItem.Click
inventory.MdiParent = Me <--error here
inventory.Show()
End Sub
EDIT:
Im only using drag and drop for creating controls from the toolbox. The thing here is, everything works fine until I relocated AND decided to return panel_001 to its previous location by pressing ctrl-z in the inventory.vb during design time to revert the change I made. The program runs fine without error prior to that specific panel relocation. I never edited any codes in the designer.vb and in the inventory class. I strongly believe that a piece of code wasn't properly restored at the ctrl-z action in the inventory.Designer.vb. Is this a visual studio bug?
EDIT: I tried creating a new winform and attempted to start fresh by foolishly copying & pasting all the controls and the forms' class and was no good. I assume the problem does not lie under the striked-out line above.
The Winforms designer has a knack for tripping really mystifying design-time exceptions. A side-effect from its strong WYSIWYG design, it will run some event handlers at design-time. Like Paint, making a control look the way it does at runtime. Nice, but that does come with a price. This can easily cause an exception if such an event handler was not written to operate correctly at design time. You are supposed to use the DesignMode property to keep the code safe.
Coming up with a way a Click event handler could run at design-time however requires massive amounts of imagination. That is an event that will not run at design time, the designer uses a layered window that intercepts any mouse clicks, using them for design use instead. Like selecting a control or displaying the design-time context menu.
I have actually seen the Click event of a ToolStripMenuItem run. The designer is not 100% watertight but it happened just once and I was hacking the code pretty hard. Coming up with a way that it could possibly run by using Undo is going to be difficult. Maybe you give it the Ctrl+Z shortcut, don't assume that guess is credible.
The way to deal with incomprehensible black magic like this is to just dismiss it and move on with your life. You just don't stand much of a chance to diagnose it and if you do then there's nothing you can do about it anyway because this isn't your code. Well, other than the need to use DesignMode, that may well be necessary. Not in this case. The only thing you have to watch out for is that such an exception did not destroy the InitializeComponent() method. That can happen too, you notice by controls being missing when you re-open the designer. Very unpleasant, you do need a good backup copy in source control to recover from that lossage.
OK! after giving it a few more tries, I found the answer. After the exception shows, copy exception details to clipboard and then I pasted it on Notepad. It had a lot of texts but the bottom part was the important one:
--insert wall of texts here-- in C:\Users\Ellen\Documents\Visual Studio
2008\Projects\SampleApplication\SampleApplication\Forms\inventory.Designer.vb:line
760 at CabuyaoWaterDist.inventory..ctor() InnerException:
It pointed me out to the specific line in the designer where the ctrl-z did not properly revert one of the label's caption
I found that for a couple of hours this code worked:
If KeyCode = 37 Then
Me.Text12.SetFocus
End If
Then it mysteriously stopped working. I thought it might have had something to do with processing the OnEnter subroutine (I move the cursor to the end of the text field).
However editing out the OnEnter subroutine didn't help.
The only other thing I'd done was change my input/keyboard language (to be able to type quote marks and have them appear immediately, huzzah!)
I now have this code:
On Error Resume Next
If KeyCode = 37 Then
Me.Text12.SetFocus
Me.Text12.SetFocus
End If
Which works. So I know the 50+ pages of search results for SetFocus not working which relate to it being hidden, disabled, not visible, out for tea with the vicar etc do not apply here.
I've also tried setting the focus to another control first, and liberally applied DoEvents as well, neither of which helped.
Has anyone run into anything similar or is this just a really weird Heisenbug?
You must have something else going on. Set a breakpoint on the first Me.Text12.SetFocus and watch what happens when you step through the code (F8).
I suspect that you have another process being triggered that's cancelling the first Me.Text12.SetFocus.
Another possibility is your DB as corrupted. This is something Access is prone to do, especially with lots of edits to the forms and/or reports. Go to File - Info, then click on Compact & Repair Database.
It's not a bad idea to have Access do this automatically whenever you close it. Go to File - Options - Current Database (tab), then check Compact on Close.