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.
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?
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.
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 basic WinForm user controls (view) whose intilization includes a presenter and model. The presenter includes calls to a wcf service. Recently an error has croped up that is very trying. Whenever I drag and drop one of these controls onto my design surface I am presented with an error that the endpoint with name "yadda" could not be found.
This same behavior occurs if I try to run the usercontrol test container. If however, I comment out the intialization, add the control to my form, save the form, go to the control and uncomment the intialization, build, and then run my app evrything works fine.
All my controls are in a Presentation project which has a reference to anothe rproject that containts the presenters and the models as well as a servic reference to my wcf service.
I am hoping someone out that encountered similar difficulties and will have some advise.
Thanks
You're configuring the WCF endpoint in your app.config file. When you are using the designer, your code is running inside of Visual Studio, so WCF is looking in Visual Studio's config file and does not find your endpoint.
Do you want to make WCF calls at design time? If you do, you'll need to configure WCF programmatically so that it works without an app.config. Here is a post that shows how to do that: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/82457a59-44f9-4efb-a814-0ed5a1ec0074
If you don't want to make the calls at design time, you can check the DesignMode on your user control, and not create the proxy in your initialization code if it's True. Note that DesignMode isn't set until after your constructor runs, so you'll need to do this work in a Load event handler or an overridden OnLoad.
Is there any reason to start a GUI program (application for Windows) written in VB.NET in the Sub Main of a module rather than directly in a form?
EDIT: The program won't take any command line parameters and it will be executed as a GUI program always.
The primary reason for using Main() in VB .NET 1.x was for adding code that needed to run before any forms were loaded. For example, you might want to detect whether an instance of your Windows Forms app was already loaded. Or you might want to intercept any unhandled exception for the AppDomain:
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf MyExceptionFilter
But the next version of VB and Visual Studio 2005 introduced a new Application model that made Main() unnecessary in most scenarios. You can now intercept the My.Application.Startup event to add code that needs to run before any forms are loaded.
Note that the code for the Startup event handler is stored in the ApplicationEvents.vb file, which is hidden by default.
You can do it either way, but you should really only keep code in the form that is directly related to the operations and user interface elements on that form. Application startup code isn't related to UI, normally concerned with splash screens, checking network connectivity, verifying a single instance only, setting up user configuration settings, and so on.
After the above items (or the appropriate initialization code for your app) are complete, Sub Main can create an instance of the main form, then show it so the user can begin interacting with your application.
This separates startup code from your form code. Later, when you're maintaining the application, you'll be glad you separated the two.
Yes, and I have done it a few times.
One reason is, that if your app is COM EXE (speaking now from a VB6 point of view) then you want to be able to detect in what context the EXE is being called (being launched or being spoken to by some other app).
For example:
Sub Main()
If App.StartMode = vbSModeAutomation Then
...
Else
...
End If
End Sub
Another is if you want your app to be able to handle any command line parameters.
For example:
Sub Main()
If App.PrevInstance Then End
If InStr(Command, "/s") > 0 Then
Form1.Show
ElseIf InStr(Command, "/p") > 0 Then
LoadPicture ("c:\windows\Zapotec.bmp")
End If
End Sub
(from one of my attempts to make a screen saver)
No, if you always want to show that form.
Yes, if you sometimes want to use your app without GUI, just using command line.
Yes, if I want to display different forms depending on some parameter (in a file, on a remote server, etc.).