Deleting menu item results index error ("source not found") - vb.net

In VB.Net 2010, whenever I delete a menu item on a Windows Form (a Mainmenu1 object), an exception is thrown at run-time suggesting that there is an index value missing -- essentially a "source not found" error. Do I need to go into the Mainmenu1 object on the bottom of the Form at design time and do something? (BTW, I have also tried deleting the source code for the menu item, and then the menu item, and the exception is still thrown).
Basically, something is occurring that is not allowing me to simply delete a menu item, and get a successful run thereafter.

I had this problem. The simple fix is to restore the menu by clicking undo. Then run the code to make sure it still works. When you have done this, CLOSE visual studio. Then open VS and load your project. Delete the item from the menu and run the project. Everything should be fine

I think you need to specify whether you were trying to delete the menu or menu item during run time, or during design time.
You said, an exception, indicating an index value was missing, thrown at run time. I think it might be depending on how you deleted the menu item. You didn't mention how you deleted the menu item.
Normally, when you choose a menu item from a menu at design time, and press the Delete key, it disappeared. And, the program still works fine.
And, another possibility, is that your form window designer and the background designer code is not properly synced.
You might know that, every .NET form objects, have their background designer code, which serves as a schema for everything on the form.
When you add a button onto the form, the Visual Studio add a line of code in the designer code file (normally if your form name is form1, the designer code file is form1.designer.vb or cs or whatever). When you change the background colour of the button, designer code file add a line of code to set the button's background colour.
So, you see, in your case, when you delete the menu item, your designer code file probably didn't successfully remove the code relating to that menu item. So, it throws an exception at run time.
Maybe, it's because of your Visual Studio installation.
So, my suggestion is, you should try debugging the project, line by line, by running the project with F6 or F11 (sorry, I don't remember the exact key, but you can find it in the Debug menu).
I hope I made a good sense for your problem!

Related

VB.net ContextMenu is not Updating

I have a project I converted from VS 2008 to VS 2015 and I am having an issue with the context menu's items not updating their text when the program runs. For instance, I have an item named "Quick Dig" and I need to change it to "Quick Hitch". It shows up fine on the context menu and in the properties of the context menu, but when I run the program it still shows "Quick Dig". Similarly, when I try and add items to the context menu, the new items do not show up either. They show up fine in the context menu and in the properties, but again, when I run the program, it doesn't have them included.
How can I get the context menu to update the new text and also include the additions I am making? Nothing I have tried has helped...

VB.net: Remove ToolStripPanel/ToolStripContentPanel

While working on a project VB.net project in Visual Studio 2013 Community, i accidently inserted the ToolStripPanel/ToolStripContentPanel controls combination.
Unfortunately however, I now cannot delete it. Can anyone advise as to how to go about doing this? There must surely be a way. Unfortunately, I cant just hit Undo either as the project has been saved since.
Copy the MenuStrip (Default name MenuStrip1) to another form in your project. Go back to the problem form. Right-click the ToolStripPanel, click Select, and then hit delete. This will delete everything. Copy MenuStrip1 back to the problem form, and your original menu should show up. You may have to add the 'Handles' clause back in to any menu events. For example, if you have an event procedure named 'MnuFileOpen_Click' you may have to reinsert 'Handles mnuFileOpen.Click.

main.vb, main.designer.vb and missing Form Designer

I have been working with "visual basic.net" on a "windows forms" application. While manipulating controls and adding event handlers I noticed the resultant code was being generated within a file named 'main.designer.vb'. However, if I look in the solution explorer for my project there is no 'main.designer.vb' file, just 'main.vb'.
This is not a colossal problem as it runs properly. However, having closed the 'form designer' window I now cannot reopen it! 'main.vb' has no option to 'view in form designer'.
Any advice on this?
Would it be possible to copy the contents of 'main.designer.vb' in to 'main.vb' and delete 'main.designer.vb' entirely? If I did this, the next time I manipulated the form would the code be added to 'main.vb' or would a new 'main.designer.vb' be created?
I seem to have sorted out the problem.
'main.vb' was completely empty. All the code I had generated and written directly was inside 'main.designer.vb'. However, once I made a class definition within 'main.vb':
Public Class main
End Class
and then cut/pasted all my custom event handler code and subroutines from 'main.designer.vb' to THAT class - all was well. 'main.vb' now shows the correct form icon and FINALLY offers the correct 'view designer' context menu option.
I am not sure why it happened in the first place though.
Look in the Solution Explorer in Visual Studio. In the toolbar in this window is a button called "Show all files". Click it.
Then every file in the projects folder is actually shown in the solution explorer. Expand the treenodes for the form and you will see the designer.vb.
There are also buttons for switching between code-view and designer view. Just remember to select the form in the solution explorer for the buttons to show the correct form in the designer.

Changing form name causes error message "Error accessing the system registry"

I am programming the On_Click method for the button labeled "View" in the first printscreen below. The method will load a form with data corresponding with the specific address id in the row containing the "View" button. This code worked perfectly when pointing to a target form called "Addresses". However, when I decided to rename the form "Address", I started receiving the following error message when clicking on the view button:
I did some research on the web about this error message, which lead me to try to delete any outdated references in the VBA editor. But when I clicked on Tools-->References in the VBA editor, I got the following error message:
It seems that MS Access' entries in the system registry might have been corrupted. But I am not certain of this because the documentation of this on the web is sparse and inconsistent.
Here is a link to the database on a file sharing site: http://jmp.sh/b/9Uyx6J2YzWbs8zPq2h6g
If the problem is in the database, you can recreate the problem by opening the form "Main" and clicking on the button "View" for the record shown in the printscreen above, or for other records.
Can anyone show me how to get past this error message?
my advices?
You could rename your Forms!....SourceObject to "Address" instead of "Addresses"
You could copy/paste the form, delete the original, and retry
You could install a decent debugging tool like MZ-Tools for VBA, that will help you manage your errors. Check the details here
EDIT: I used to get similar bugs years ago, when I was writing specific form event procedures. As we decided to switch to a model where forms did not need to be debbuged anymore (check this here), we stopped getting this kind of message. And I think I forgot the trick we used to solve this kind of error. If I were you:
I'd try to open another access database and import all objects ...
I'd put aside/cancel the faulty onClick procedure
And I'd install MZ Tools because otherwise VBA debugging is a nightmare ...
Since access was not liking the command button in each record of the continuous form, I choose to put the view button's logic in the on click event of a text box in each row, which I configured as enabled but locked. This produces a separate link from each record of the continuous form to a unique detail page with more of the chosen record's data.
This solution works perfectly, and is enabling me to move on with my other coding.
However, it would be nice if someone else were able to show how to get the command button solution to work.

Form sent to back on interaction with menu item

I've got two forms, one being frmMain and the other being frmDatasets. The idea is that frmDatasets is used to manage the application's datasets (it's a program for comparing sorting algorithms).
I have a MenuStrip on frmDatasets with a few items. I just decided to change the Add Dataset item to a drop-down menu with options for loading one from file, or generating one according to certain parameters. All well and good; just add the items, swap some icons around, and change the event handler's signature to handle the right Click event.
Except when I run the program, clicking on the Add Datasets top-level item for the first time sends frmDatasets to the back, displaying an inactive frmMain. Clicking the item again shows the dropdown menu as usual.
If I instead click another top-level menu item, that works just fine. But then simply hovering my mouse over the Add Dataset item causes the 'send to back' thing to happen.
I say "send to back", but it's really just putting it behind frmMain. It remains in front of other windows like Visual Studio and Firefox.
Anyone know what on Earth is going on with this form?
EDIT: If I show frmDatasets as a modal dialog, it stops the whole "sending to back" thing, but I still have to click the menu item twice before it shows the list.
EDIT2: Overriding the onClick event to call mnuAddDatasetDropDown.ShowDropDown removes the double-click issue, but it's only a solution if I keep the form as a modal dialog. Still gets sent to back. Overriding mouseEnter doesn't do anything to solve it.
Setting the TopMost property of frmDatasets from its Design view to 'true' fixed all of the problems I was having. No insight as to what was going on, unfortunately, but if anyone else is having this problem then hopefully it'll work for them too.