I'm using the Ribbon control located on CodePlex, and following the tutorial located here . Once I add the reference, and the proper code in the designer I get this error when I try to view the form:
Exception of type 'System.ComponentModel.Design.ExceptionCollection' was thrown
And I cant figure out what I'm doing wrong. Anyone worked with this control and know how to resolve this issue?
Interesting; I just ran into this same issue with one of my own forms; which is how I found your relevant and recent question.
Here's how I solved it:
Open two instances of Visual Studio. Open the same project in both.
In one instance, goto Debug->Exceptions and enable all the 'Thrown' options to stop at first chance exceptions. This will stop the debugger when the exception is generated.
In the same instance, select Debug->Attach to Process, select devenv.exe.
In the other instance, open the form to cause the exception
With any luck the first instance should stop somewhere that yields a more relevant exception.
In my case it turned out to be something that I should have conditioned with:
if (!DesignMode)
{
// Do something that should only happen at runtime
}
Don't forget turn turn off all those 'Thrown' options later.
A workaround for me was:
Right-click on the form and 'View Code'
Keep the code loaded in the editor and then attempt to view the designer again.
This feels very glitchy and I cannot confirm whether it's a problem with my code (as I'm working on an entirely new codebase) or whether it's a VS2012 bug. If I find out, I will report back.
Since the solution outlined by pilotcam didn't work for me, I took a different approach:
Make a SVN commit for the file.
Open the “*.designer.cs” file of the form that shows the error in source view.
Remove larger blocks of form element declarations.
Fix all compilation errors with ReSharper (i.e. ensure that nothing is red anymore on the side-indicator).
Save the file. No need to compile.
Open the Windows Forms Designer of the form.
If the error still shows up, do a SVN revert to go back to the initial state.
Repeat steps 2 to 7 until the error does not show up anymore.
Now you’ve encircled the erroneous child control that causes the error.
Repeat steps 2 to 7 with a smaller amount of controls you remove, until you have only one control left.
In my case it was a user control inside a group control inside a tab control, so I first identified the tab control, then the group control and then the user control.
You could isolate the user control inside a new form to further investigate. In my case it was rather easy; I put checks for design mode around most of the functions inside my control to ensure the code only gets executed if the control is not in design mode.
This fixed my error.
I had the same issue and none of the above answers solved the problem.
At the end, emptying the "bin" folder and rebuild has worked for me.
Let me add two more cases when such exception can happen, along with when control tries to do something that is not allowed under design mode:
When it's impossible to compile the user control.
When designer code contains multiple similar (or identical) lines with initialization of same controls or properties, this can easily happen on merge.
All that cases produce same extremely meaningful error message, and in this particular two debugging of Visual Studio won't help, so I just ended up with bisecting my designer code.
[ReadOnly(true)]
[Browsable(false)]
Above all properties worked for me
Related
I'm having an issue with tool I developed in excel for one of our offices. It is a big enough file with couple of macros in it, but it works smooth day to day.
However every few days file will through error 'Can't find project or library' and file will crash. I know the standard guides are that when this error appears, it is to go to vba>tools>referneces and uncheck the missing library, however this is not the case in here. Simply when this happens file crashes and restarts and if it will happen once, every other attempt to open back the file will result in same error in crash. I mean file can be absolutely fine, you will save it, go back to it and error happens. So I always have to recover the file which absolutely destroys it, however I can at least recover from it information uploaded there by the users and copy it into the template.
So 2 questions I have is what is causing this to happen? Both myself and the other office are using the same version of excel so compatibility should not be an issue.
2 questions is is there anything that can be done to prevent this error from happening.
I have exactly this problem. As stated, once the error occurs, it it results in a permanent "unfixable" loop. I use powerquery and linked data and this appears to randomly "damage" the file as described - most frequently when excel crashes for some reason.
I have found either of the following to work:
- Open the file on a different computer that is not on the LAN. This
appears to be a key requirement.
- Open the file with "Excel Online"
In each case, simply open the file and save it with a new name. Move the new file back to the work PC and it will once more open perfectly.
On rare occasions (if powerquery is in use), it is necessary to "refresh all" data connections before saving the new file.
As a bonus, the new file is often smaller than the original.
This worked for me:
In VB go to Tools » References
1) Uncheck the library "Crystal Analysis Common Controls 1.0". Or any library.
Just leave these 5 references:
1) Visual Basic For Applications (This is the library that defines the VBA language.)
2) Microsoft Excel Object Library (This defines all of the elements of Excel.)
3) OLE Automation (This specifies the types for linking and embedding documents and for automation of other applications and the "plumbing" of the COM system that Excel uses to communicate with the outside world.)
4) Microsoft Office (This defines things that are common to all Office programs such as Command Bars and Command Bar controls.)
5) Microsoft Forms 2.0 This is required if you are using a User Form. This library defines things like the user form and the controls that you can place on a form.
Then Save.
I've had similar nasty issues.
First thing to do is use the CodeCleaner a free utility from AppsPro
This will export your modules and then re-import them, because internally they get a lot of binary "lint" which can cause problem.
Second thing to suggest is start breaking up your code base. So start removing modules to see which module is the offender. Horrible I know but how can you tell otherwise where the problem is.
Third suggestion is to always fully qualify your functions. So instead of Len(sMyString) write VBA.Len(sMyString) that helps prevent false negative compile errors.
Let me say at outset that I'm using old technology by today's standards! This happens in MFC on Visual Studio 2005 and running under WinXP. (If it 'aint broke.... ;-) )
I have a dialog based app which has a CTabCtrl with two tabs. Each contains a CListCtrl. These work perfectly under normal circumstances. They populate correctly and show and hide as they should. When I first open the application the display selection is correct. If I then minimize the dialog and restore, the CList Ctrl does not show, the tab is blank. It is the only control which has this problem. Another CListCtrl outside of the CTabCtrl does show up correctly. If I then swap tabs and back again, the other tab shows up then the first appears as normal.
This does not happen if I access any other part of the dialog before minimising, it is only when minimising is the absolute first action I take. It also happens with the CListCtrl I have in the other tab if I set this tab to be selected on startup in OnInitDialog where I set up the CTabCtrl.
I have actually solved the effect of this problem by adding into my OnSysCommand(...) the following:
if ((nID & 0xFFF0) == SC_RESTORE)
{
m_ctrlReadList.Invalidate();
}
but it bugs me that I'm adding code to solve a problem which only happens in such odd circumstances. I can't help thinking that there is something I have missed in the setup which is leading to this behaviour. Can anyone offer any explanation as to what is causing it in the first place?
My explanation is based on the facts of what I have found but this has been a learning experience for me so apologies if I get some of it a little confused, I'm still letting it settle in my mind.
Along with this problem I found another which turned out to be relevant. From the nature of the program I'm writing, my CListCtrls needed fixed width headers. Now that turned out to be another thing I couldn't set up! I just needed to prevent the user from grabbing and resizing the header's dividers or double clicking them to autosize, and of course there is functionality in the CListCtrl based on its child CHeaderCtrl to set this up isn't there? Well apparently not. LVS_EX_HEADERDRAGDROP for example isn't the way.
So I explored trying to capture messages which would allow me to myself, and what do you know, I couldn't! I could trap a few but not the ones I needed. I was looking for HDN_BEGINTRACK and HDN_DIVIDERDBLCLICK. (We won't go into the fact that you HAVE TO deal with both A and W versions of those separately!) The CHeaderCtrl is a child of the CListCtrl but it sends its messages back to the CDialog as the CListCtrl's parent. I tried there using both my list's and 0 as ID which headers apparently use. Many of them just plain didn't appear there at all.
So I created my own CListCtrl class inheriting from CListCtrl, overrode OnNotify and they turned up there. I simply prevented CListCtrl::On Notify from being called for those messages and it worked, no resize functionality at all.
I also played with the Z-order too which could have been relevant. I didn't explain earlier but this and another list are on two tabs, exactly aligned over each other. Selecting the tabs HIDEs and SHOWs each of the lists in turn. The other list had no display problems even when I changed the default display in OnInitDialog to show it at start up.
It was under the problematic one. So changing the Z-order in OnInitDialog where I set them up - did nothing! And to rub it in that second list was also unresizeable by default just as I wanted and I couldn't find out why. Their Properties listed exactly the same and there was nowhere in the code where any different aspect was set manually for either, they were effectively theoretically identical, but practically not so. So frustrating!!!
And the upshot of it is that now that the header resize issue is solved my display problem has vanished too! It looks to me and to a few others out there too who report similar symptoms as myself as though the CListCtrl is another one of the slightly flaky ones and needs a little massaging to get the best out of it.
I hope that makes sense to those of you out there who know this control well. I was surprised how simple the solution was, but it also surprised me that the diagnostic process was so difficult. It may of course come down to the ageing system I work within. Nowadays I do this only for fun and the expense of updating VS from 2005 for occasional use is not a high priority. I am sure that some of the symptoms will not show under other build and run environments but it may be worth having the issue and my solution on record somewhere for Google to find for others.
This has been happening increasingly, when I have a sheets.add or sheets.delete in excel VBA. After searching and searching I finally found the official Microsoft support page on it. My question is, does anyone know why I could have stepped through this code just fine over and over, and then all of a sudden it starts doing what Microsoft says it would always do, and is there a way to fix it?
Sub foo()
Sheets.add
debug.print "sheet added" 'breakpoint here
End sub
It's as simple as that. You won't be able to recreate it, because the issue I'm asking about is the fact that it doesn't happen at first. It works just fine over and over then randomly presents the error described in the linked Microsoft support page.
Check if Microsoft Visual Basic for Applications Extensibility is being referenced in the project.
You can check that in the Tools/References Menu on the Visual Basic window of the project.
Referencing Visual Basic for Applications Extensibility prevents the program having its execution suspended:
Excel helps says specifically:
A change was made programmatically to the project using the extensibility (add-in) object model. This prevents the program from having execution suspended. You can continue running, or end execution, but can't suspend execution.
You are unable to step through code when making changes to the project (dynamically eg using InsertLine etc). the code can be run but not stepped through.
Deleting certain objects including ActiveX objects actually changes the VB project. It took me some time to realize that the following line of code prevented the VBE from entering break mode:
Excel.ActiveSheet.DrawingObjects.Delete
If you can identify the code causing the issue, and the order of operations isn't important, move it to the end of your script.
Here are a few suggestions which are not fool-proof,
Firstly, verify that the error does not occur if a breakpoint is not set.
If it doesn't, try a few other things:
From the VBE Debug menu, "Compile VBA Project", it's worth a shot.
Delete the line entirely. Run the code. Then put the line back in and try again with the breakpoint.
Add a DoEvents statement after the Sheets.Add
Use a MsgBox instead of a breakpoint on a Debug.Print. With the message box displayed, attempt to manually break using ctrl+fn+End. (At this point, "breaking" isn't necessary but it would be interesting to see whether you can break this way)
Put a breakpoint on Sheets.Add instead; practically speaking, there's no reason to put the breakpoint on a Print statement if you can just put it on the preceding line.
Are there any Addins? If so, disable all of them and re-enable one at a time, testing to see which one may contribute to the error.
Yet another Excel/VBA glitch.
When it happens to me when I click a button running a macro:
I first try to directly run the macro from VBE,
if it fails, then I put a breakpoint at the first instruction of the macro,
if it still fails, I try both,
or, after clicking the button and breaking on the first breakpoint, I do a single step (SHIFT F8) and then I can let debug run freely as usual (F5).
And so far I don't get this error anymore.
Probably not foolproof either but worth a try.
Ran into the same issue, and (as far as I can tell) the only relevant answer here is Answer 5 (i.e. the one provided by Chrisb).
I've been working with vba for (too many) years now, and never encountered this until I had a project that needed vba to delete ActiveX controls. In my case, the 'ActiveX controls' were a spurious result of data copied in from a web page.
Additionally, there appears to be a way around the issue. Using the following code (versus, e.g. deleting the ActiveX as a shape), seems to circumvent the issue:
On Error Resume Next
ActiveSheet.OLEObjects.Visible = True
ActiveSheet.OLEObjects.Delete
On Error GoTo 0
I say 'appears' and 'seems' above as implementing the above solved the issue for me. However, before I implemented same, I had made other code changes and I have not yet fully regression tested for all possible other reasons the problem was resolved. :)
This has happened to me multiple times and this solution works for me.
Run a different macro within the same VBA project.
Then go back and run the same macro that is causing the pop-up message to appear. The message should no longer appear.
I have been using the above tool and Excel 2013 with mixed success. The good news is that it eventually works, the bad being that when it doesn't the following horrible things happen when modifications inside of the Editor are made:
modules with callback code revert to their state before the callbacks were added (ie, the code is lost!). This seems to happen even when there are no errors. This is frustrating!
custom tabs and context menus just don't show up if there is a conflict. For example specifying a callback to getLabel in xaml when there is also a label attribute specified. Of course this is my bad but it wouldn't hurt if the tool would catch this for me.
Question
Is the Editor the state of the art for customizing the ribbon and adding context menus. I realize the price is right but would gladly pay for a smoother and more reliable dev experience
The CustomUI editor doesn't affect modules in the workbook - but if you do make changes to the workbook while it's opened in the UI editor, then yes you may lose changes.
Also, you can set Excel to warn you of UI errors which will at least assist you in working out why your tabs/controls aren't appearing.
The problem Rory described (losing your changes) has bitten me many times, even when I am fully aware of why it happens (I may just forget I made changes externally).
Due to that and many other limitations I saw in the Custom UI Editor, I decided to create my own editor based on the original:
https://github.com/fernandreu/office-ribbonx-editor
For this particular issue, what I did was to implement a "reload on save" feature, which reloads the entire contents of an Office file (spreadsheets, VBA modules, etc.) right before the custom UI files are saved, hence preventing any accidental loss. I hope you might find this useful to prevent any future frustration!
Disclaimer: I am (obviously) the author of the tool above
From what I can see on the web, this is a fairly common complaint, but answers seem to be rarer. The problem is this:
We have a number of Excel VBA apps which work perfectly on a number of users' machines. However on one machine they stop on certain lines of code. It is always the same lines, but those lines seem to have nothing in common with one another.
If you press F5 (run) after the halt, the app continues, so it's almost like a break point has been added. We've tried selecting 'remove all breaks' from the menu and even adding a break and removing it again.
We've had this issue with single apps before and we've 'bodged' it by cutting code out of modules, compiling and then pasting it back in etc.
The problem now seems to relate to Excel itself rather than a single .xls, so we're a little unsure how to manage this.
Any help would be gratefully received :)
Thanks,
Philip Whittington
I have found a 2nd solution.
Press "Debug" button in the popup.
Press Ctrl+Pause|Break twice.
Hit the play button to continue.
Save the file after completion.
One solution is here:
The solution for this problem is to add the line of code
“Application.EnableCancelKey = xlDisabled” in the first line of your
macro.. This will fix the problem and you will be able to execute the macro
successfully without getting the error message “Code execution has been interrupted”.
But, after I inserted this line of code, I was not able to use Ctrl+Break any more. So it works but not greatly.
This problem comes from a strange quirk within Office/Windows.
After developing the same piece of VBA code and running it hundreds of times (literally) over the last couple days I ran into this problem just now. The only thing that has been different is that just prior to experiencing this perplexing problem I accidentally ended the execution of the VBA code with an unorthodox method.
I cleaned out all temp files, rebooted, etc... When I ran the code again after all of this I still got the issue - before I entered the first loop. It makes sense that "press "Debug" button in the popup, then press twice [Ctrl+Break] and after this can continue without stops" because something in the combination of Office/Windows has not released the execution. It is stuck.
The redundant Ctrl+Break action probably resolves the lingering execution.
I found hitting ctrl+break while the macro wasn't running fixed the problem.
I would try the usual remedial things:
- Run Rob Bovey's VBA Code Cleaner on your VBA Code
- remove all addins on the users PC, particularly COM and .NET addins
- Delete all the users .EXD files (MSoft Update incompatibilities)
- Run Excel Detect & Repair on the users system
- check the size of the user's .xlb file (should be 20-30K)
- Reboot then delete all the users Temp files
I have came across this issue few times during the development of one complex Excel VBA app. Sometimes Excel started to break VBA object quite randomly. And the only remedy was to reboot machine. After reboot, Excel usually started to act normally.
Soon I have found out that possible solution to this issue is to hit CTRL+Break once when macro is NOT running. Maybe this can help to you too.
Thanks to everyone for their input. This problem got solved by choosing REPAIR in Control Panel. I guess this explicitly re-registers some of Office's native COM components and does stuff that REINSTALL doesn't. I expect the latter just goes through a checklist and sometimes accepts what's there if it's already installed, maybe. I then had a separate issue with registering my own .NET dll for COM interop on the user's machine (despite this also working on other machines) though I think this was my error rather than Microsoft. Thanks again, I really appreciate it.
I have had this problem also using excel 2007 with a foobar.xlsm (macro enabled ) workbook which would get the "Code execution has been interrupted" by simply trying to close the workbook on the red X in the right corner with no macros running at all, or any "initialize" form, workbook, or workheet macros either. The options I got were "End" or "Continue", Debug was always greyed out. I did as a previous poster suggested Control Panel->Programs and Features-> right click "Microsoft Office Proffesional 2007" (in my case) ->change->repair.
This resolved the problem for me.
I might add this happened soon after a MS update and I also found an addin in Excel called "Team Foundation" from Microsoft which I certainly didnt install voluntarily
I would like to add more details to Stan's answer #2 for below reasons:
I faced this issue myself more than dozen times and depending on project conditions, I chose between stan's voodoo magic answer #1 or #2. When I kept on facing it again, I become more inquistive that why it happens in first place.
I'd like to add answer for Mac users too.
There are limitations with both these possible answers:
if the code is protected (and you don't know password) then answer #1 won't help.
if the code is unprotected then answer #2 won't let you debug the code.
It may happen due to any of the below reasons:
Operating system not allocating system resources to the Excel process. (Solution: One needs to just start the operating system - success rate is very low but has known to work many times)
P-code is the intermediate code that was used in Visual Basic (before .NET) and hence it is still used in the VBA. It enabled a more compact executable at the expense of slower execution. Why I am talking about p-code? Because it gets corrupted sometimes between multiple executions and large files or just due to installation of the software (Excel) went corrupt somewhere. When p-code corrupts. the code execution keeps getting interrupted. Solution: In these cases, it is assumed that your code has started to corrupt and chances in future are that your Excel workbook also get corrupt giving you messages like "excel file corrupted and cannot be opened". Hence, as a quick solution, you can rely on answer #1 or answer #2 as per your requirements. However, never ignore the signs of corruption. It's better to copy your code modules in notepad, delete the modules, save & close the workbook, close the excel. Now, re-open the workbook and start creating new modules with the code copied earlier to notepad.
Mac users, try any of the below option and of them will definitely work depending on your system architecture i.e. OS and Office version
Ctrl + Pause
Ctrl + ScrLk
Esc + Esc (Press twice consecutively)
You will be put into break mode using the above key combinations as the macro suspends execution immediately finishing the current task. This is replacement of Step 2.
Solution: To overcome the limitation of using answer #1 and answer #2, I use xlErrorHandler along with Resume statement in the Error Handler if the error code is 18. Then, the interrupt is sent to the running procedure as an error, trappable by an error handler set up with an On Error GoTo statement. The trappable error code is 18. The current procedure is interrupted, and the user can debug or end the procedure. Microsoft gives caution that do not use this if your error handler has resume statement else your error handler always returns to the same statement. That's exactly we want in unwanted meaningless interruptions of code execution.
My current reputation does not yet allow to post this as a comment.
Stans solution to enter the debug mode, press twice Ctrl+Break, play on, save did solve my problem, but I have two unexpected twists:
My project struture is password protected, so in order to get into the Debug Mode I had to first enter Developer mode, click on the project structure and enter the password.
My project is a template file (.xmtl). I opened the file via double click which opens it as .xml with a "1" at the end of the previous file name. I fixed the bug as by Stans instruction and saved it as that ...1.xml file. When I then opened the template again, this time as template, and wanted to apply the same bug fix to that file, the bug was gone! I did not change this file and still no bug at executing the Macro. This means to me that the bug is not actually in the file, but in a (hidden) setting in Excel.
If it's a phantom breakpoint:
1 Delete the offending line of code
2 Run the code again
3 Repaste the line
I found this laughably simple solution after spending a couple days wading through all the answers here and elsewhere. I figured, if I link it to my original question it might help some other poor chap, since the question it's on is VBA break execution when there's no break key on keyboard and this is more applicable.
Link to original answer
I faced the same issue today. Resolved it with these steps.
Create a new module
Move the procedure that is causing the issue to this new module.
Save project
Run macro again.
This time, the code execution will run till completion without any intermediate stops.