When an object is created in the .Designer.vb file from the Windows Form Designer, is a Dispose() call generated automatically for each object or must this be done manually?
Specifically, I have an object that uses unmanaged resources (by calling ShowDialog(), requiring a call to Dispose()) that is created in the Windows Form Designer. Do I still need to call Dispose() on that object?
Note: It is advised not to call Dispose() more than once on the same object.
While I dont know the answer, let me tell you how you can get the answer and learn a neat trick for designing components for winforms (might work for others but haven't tried).
Assuming you have a project that already references your component, create a new project and set the "Start External Program" to "C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" (change this based on your version of visual studio, this is from 2005)
Run this project, which will then run another instance of VS. You have now opened VS in debug mode. Now open your project you are using to build/test your component (from the second instance of VS), set a break-point and test it. You should be able to see it hit your break-point in the dispose code.
This is great for testing VS Add-ins and designer components.
This was one of those questions where the answer is "because that is the way it works", but then you realize you don't actually know how it is implemented. So I spent a few moments to dig up the details.
Anything that is a Control (button, textbox, whatever) that is added to the Controls collection is disposed for you automatically. This implementation is inherited all the way back from the Control class itself.
Anything that is a non-graphical Component (like a Timer for example) that is added to the auto-generated components object in the MyForm.Designer.vb file is also disposed for you. In this case, components object, while implementing the System.ComponentModel.IContainer interface, will be an instance of System.ComponentModel.Container that handles the actual Dispose.
Related
Goal
I have a main application that generates numbers for the company. I will be using this number generation in my main application and in an AutoCAD plugin. That being said, I created a class library (DLL) that will be utilized in both places. This prevents me from making modifications in both places if ever I need to. I just open the DLL, make the changes and rebuild.
The information is stored in DataTables and I want to use my main applications' DataTables as a reference in my DLL class library.
Current Situation
When I edit an item from my main application, I use the DLL to prompt the edit window (this is what is used in my application and my AutoCAD plugin). Once the user is done, they save the changes. The only issue is, the DataTables in my main application are not modified, only those in the DLL. Therefore I do not see the changes replicated.
From my main application, I call the Dll.Initializer.InitializeDataTables() to load the information in my DataTables. This is the same code I utilize in my main application load as well, I know this isn't the way to go. This is why I'm looking to some sort of reference between the DataTables.
Public Class Initializer
Public Shared Sub InitializeDataTables()
'The following Loads information in the DataTables
clsPlatform.LoadPlatform()
clsState.LoadStates()
clsEmploye.LoadEmploye()
clsClient.LoadClient()
clsArticle.LoadArticle()
clsLayout.LoadLayout()
clsCountry.LoadCountries()
clsOffice.LoadOffices()
clsProgramVariable.FillAppEngs()
myApplicationEngineers = clsProgramVariable.GetAppEngs()
End Sub
End Class
How can I reference the DataTables so when a change is done in the DLL, I can see it replicate in my main application?
I just upgraded from VS 2005 to VS 2012. This is a new issue that I do not understand. I am using the default "Form1" class the VS automatically creates. I added a button to open a file open dialog and when I click the button I get this error:
Current thread must be set to single thread apartment (STA) mode before OLE calls can be >made. Ensure that your Main function has STAThreadAttribute marked on it. This exception >is only raised if a debugger is attached to the process.
I have added " to Public Class Form1:
<STAThread()> Public Class Form1
But I get this...
Attribute 'STAThreadAttribute' cannot be applied to 'Form1' because the attribute is not >valid on this declaration type.
I have searched but get some info telling me that I need to set the entry point (Form1 I believe) to be Single Thread Attribute but the above code does not work.
How?
The <STAThread()> attribute cannot be added to classes like your form. It only works when it is applied to the Main function, which is the entry point of your application.
But VB.NET hides this function from you because it is rare that one needs to mess with Main in a WinForms application. It is just needed to get the plumbing set up for your app, which the compiler can manage for you. This is controlled by the "Application Framework" checkbox in the project options. If this is checked, the compiler automatically generates the Main function and the required plumbing. You can disable this option, but it makes life quite a bit harder for the average WinForms developer because you'll have to write and maintain your own Main function.
The real question here is why this is a problem at all. The compiler-generated Main function for a WinForms application is always going to have the STAThread attribute applied to it. That is just how the WinForms framework is designed to run. If that is not happening, then there is something badly wrong with your project. I would recommend scrapping it and starting over letting Visual Studio create a new WinForms project from one of the built-in templates. Everything should Just Work™.
The other option, of course, is that you're trying to display the OpenFileDialog on a separate thread (other than your main UI thread). But from your description in the question (adding a button to the form to display the dialog), it doesn't sound like this is the case. Regardless, the solution is not to do that. For example, if you're using a BackgroundWorker to do work on a non-UI thread in order to keep the UI responsive, that's great, but you'll want to do all of the UI stuff like showing an OpenFileDialog on the main UI thread before invoking the BackgroundWorker. There is a way to set a particular thread's apartment state using the SetApartmentState function, but I really don't recommend showing an OpenFileDialog on a background thread.
I have replicated this issue in both Project 2010 and 2013.
I developed a VSTO addin, using Visual Studio 2010. In this addin, I have exposed a COMVisible method.
I also have a different (non .NET) application, which then instantiates the Project COM object, searches for my addin and calls the method that I marked as COMVisible.
This causes Project to open a "new" Project file and write something to it.
This non-.NET application, after calling the COM method in my addin, stops execution (without closing MS Project).
I then close the newly created Project (not MS Project, just the file). Everything is fine; however, when I try to close MS Project, it hangs indefinitely. In the Task Manager, it is still shown as "Running" and clicking on the MS Project window brings up a "Switch To", "Retry", "Cancel" dialog, informing me that some other application is busy...
Surprisingly, if I choose to NOT close the newly created Project file, and simply close the MS Project window, it closes normally.
What might be going on here?
Ok, after much investigation, I found the answer to the problem. Basically the COM class exposed from my VSTO Addin needs to inherit "StandardOleMarshalObject".
The reason for this is because the COM method in my Addin was accessing the Project Object Model on a secondary thread (the thread of the calling application). This is a big no no. Deriving from that class marshals all call on that secondary thread to the primary UI thread, thus fixing the problem.
Trying to get it to behave like C#, where there is a Program class with a static Main method.
However, in the project properties, I cannot set Program.vb to be the startup object, only the forms (it is a forms application).
Am I missing something?
I am using the VS2010 and the latest VB.
Uncheck Enable Application Framework in Project Properties.
You need to switch off “Application Framework” on the main page of the project settings.
The application framework provides its own entry point which sets up a few things that are subsequently used (e.g. application events, single instance checks etc.) and then just displays the main form using System.Windows.Forms.Application.Run. That’s why you can only supply the main form, not a custom entry point method.
In C# adding event handler methods is very easy. You just type "object.event +=" and then press tab twice.
Is there anything like this for VB projects?
Note: This is for dynamically created controls or controls that are not declared WithEvents.
You can select the object and the event in the top of the coding window and VB will automatically create the method for handling the event and hooking it up in the designer file. Besides from this there is no such feature available not with Visual Studio nor Resharper.
The C# development team added support for this, but for some reason the VB guys haven't gotten around to it yet, nor has I seen any third party addons doing anything like it.