I've been given a windows form application written in VB. For some reasons I will need to execute the second class before the form application in the first class. The form class has to be the first class in the file. I can't simply inherit the second class and call the functions, because it has already used up the only allowable inheritance. I did some research and found there is something called main procedure that determines which codes executes first? It is automatically generated for any windows form application, but I simply can't find that file. Any thoughts on that? or any other ways that I do this?
Follow Start VB.NET GUI app using Sub Main or form startup object? for better alternatives.
But if you really need to start with Main(), follow these steps.
Open application settings.
Uncheck "Enable application framework"
Set startup object to "Sub Main"
Then add a new source file (.vb) and include Main() in it
Module MainModule
Sub Main()
'Your code here
End Sub
End Module
Related
Is there a way to control which form will load first when the program starts in vb.net programmatically? Like a main method or something like that?
Yes, this is possible.
Add a public Main somewhere. (For example in a new class)
Public Shared Sub Main()
'Create and show your form here
End Sub
Then in the application settings, disable "Enable application framework" and select the Main method as the startup object.
we can add our function with this way
https://www.youtube.com/watch?v=TEYuQmia9IY
but it in c#
i want the way in vb.net
the problem in using namspacing in vb.net
thanks
In the video posted there are some critical steps missing. It seems that they are given for granted but without it you could not achieve a successful reference to your code from the Report Designer.
First: To clarify the problem between VB.NET and C#. If you want to use VB as scripting language for your report you need to set it in the Report Properties. You will find the ScriptLanguage property in the same property grid for the report where they set the reference to your application. Changing this property is not required because this property refers to the code written inside the report not the code in which you have written your app.
Second: In your VB.NET app your code that defines the function should be as this
Namespace MyFunc
Public Class Main
Public Shared Sub ShowMessage(text As String)
MessageBox.Show(text)
End Sub
End Class
End Namespace
Usually in VB.NET you don't define explicitily a namespace (everything is inside the main namespace defined in the project properties) but if you want a separate namespace there is nothing to stop you.
Third: In the Report Code Page you write
Imports WindowsFormApplication2.MyFunc
Fourth: After completing the design of your report remember to save it in the same folder where the application is created. (Usually Project\BIN\DEBUG) Otherwise the reference to your executable will fail.
Fifth: The Stimulsoft assemblies are installed in the GAC, but to be sure that they are found when you run the report don't forget to set their references to Copy Local = True when you run your app inside Visual Studio
If I create a new Console application then this compiles ok:
Module Module1
Sub Main()
Console.ReadKey()
End Sub
End Module
An alternative is this:
Imports System.Console
Module Module1
Sub Main()
ReadKey()
End Sub
End Module
What I don't now understand is, as this is a console application, why aren't these projects created in such a way that the following will compile?:
Module Module1
Sub Main()
ReadKey()
End Sub
End Module
Put another way: if it is a Console app why do I need to import the Console namespace?
Is this the same behavior as when using a winForms application I say Me.someControl? Although in that situation I can leave of the Me and it will still compile without importing a forms namespace.
EDIT
Imports System.Console
Module Module1
Sub Main()
ReadKey()
Console.ReadKey() '<<adding namespace seems a bit pointless as I still need to specify Console
End Sub
Function ReadKey() As Boolean
Return True
End Function
End Module
FURTHER EDIT
Hans has suggested further behaviour and to replicate this I have the following:
I've added a new ClassLibrary1 to the same Solution like so...
In the Console ConsoleSandpit I've got the following, with a reference to ClassLibrary1 like so...
...only problem is I'm expecting a compilation error from the above but it seems to be running ok!
System.Console is not a namespace. ReadKey is a shared method in the Console class which is in the System namespace
So, the breakdown of the following statement is:
System.Console.ReadKey()
System - Namespace
Console - Class
ReadKey - Shared method
So, when you call Console.ReadKey() (without specifying the namespace), you would normally expect to have to import System at the top of your code file. However, that is unnecessary because in VB.NET projects, you can specify a list of default namespaces that are automatically imported for all files in the project. You can modify these using the check-list of default namespaces in your project properties designer. System, among others, is automatically imported as a default namespace with all of the project templates.
As you demonstrated in your question, it is possible in VB.NET to import a class or module name. The Imports statement is not limited to just working with namespaces. However, as far as I know, there is no way to import a class name with the default namespaces option for the project (or at least not with the project properties designer, anyway).
If System.Console was a namespace, I agree that you'd expect the project template for console projects to import that namespace by default. However, since it's not a namespace at all, you wouldn't expect it to do that :)
1) You can do plenty of useful things, over many functions, inside a console application, without wanting or needing to actually interact with the Console.
2) I could easily envisage wanting to write a function called ReadKey which puts out a small prompt for one of two or three keys to be pressed - based on the user input, if its one of those keys, return it. Otherwise, indicate the error and re-prompt. Why should I have to pick a different name for this function, because my own namespace has been automatically polluted with the methods from Console?
Namespaces exist to help to separate and organize functionality. You're given options (such as the Imports statement) to hide these separations, where it makes sense for you within your application - but I wouldn't want this forced on all users.
Add a class library project to your solution and paste this code:
Module FooBar
Sub ReadKey(ByVal wait As Integer)
End Sub
End Module
And observe how your original code now suddenly fails to compile. With a seriously obtuse error message as well: "Argument not specified for parameter 'wait'". You can lose hours of your life trying to figure out why Console.ReadKey() wants a wait argument.
When I was using VB.net , I came across a very strange behaviour, I created a simple test WPF project to reproduce it. here is the details. I have a very simple class, which when an instance is created, the class will create a test.txt file
Public Class Test
Public Sub New()
Using writer As New System.IO.StreamWriter("test.txt")
writer.Write("test")
End Using
End Sub
End Class
Then in the Application.xaml.vb
Class Application
' Application-level events, such as Startup, Exit, and DispatcherUnhandledException
' can be handled in this file.
Shared tt As New Test()
End Class
I simply define a shared variable. my expectation of this are, when I start the application, the variable will be initiated, and a "test.txt" file will be created.
If the Configuration is "Debug" , everything is fine.
If the Configuration is "release", When I start press F5 in Visual Studio 2010, everything is fine as well, it worked as expected, file had been create
But When I start it without debug, press (Ctrl+F5), the variable had not been initiated, file had not been created as I expected.
I am not fully understand why this happen, Can anyone help me out?
Thanks and regards
Is this shared variable accessed somewhere? It could been removed due to compiler optimization. Try to add some code that uses the variable.
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.).