This is an IDE question for Visual Basic 2008 Express Edition. It might be a bug in the IDE, or maybe it's my fault somehow?
My main form is named frmMain and in my application's properties I have set frmMain as my startup object. All of that seems like what a lot of software engineers do.
But while debugging I hit Ctrl + Break, as I have done for years, and I get an behavior in the IDE that I wasn't expecting. Upon doing so, I get the green background text and the green arrow indicating in a tooltip:
This is the next statement to execute when this thread returns from the current function.
Even if I didn't have the designer document open, it automatically opens frmMain.Designer.vb in the editor and hihglights line in green. The line is of course: Partial Class frmMain which is line 2 of the file. (Yes, it's highlighting the second line of the designer-generated code.)
frmMain seems to have fully loaded and it's my startup object. As far as I know, there shouldn't be a "next statement to execute" at all because code should be idle. I don't want to see the Designer.vb document... I want to edit my own code.
What's causing this? Even though my form is behaving just fine, could there somehow be an unfinished aspect of loading the form such that it is "not returning" from a function?
The Visual Basic compiler will add an entry point in your form. The entry point is the standard main function or "shared sub main", which in turn contains the code "application.run(new form)". Since this is compiler generated code there is no source location, so the Visual Basic editor highlights the class definition.
The clue to this is in the call stack. Notice the Main().
Shared Sub Main()
Application.Run(new frmMain)
End Sub
I found the answer on my own:
I checked the "Enable application framework" checkbox in the solution's properties, and all is well!
I believe this issue arose when I was working on experimental code in which I had desired to make Sub Main my startup object. I had cleared the checkbox because doing so is necessary to use Sub Main.
When the experiment didn't pan out I reset the startup object back to frmMain, and my app worked fine. However I had not re-checked the box. I hadn't noticed the change in the IDE behavior for several days (when I needed the more standard behavior) so I had not observed any correlation.
Although checking that box is definitely the solution, it's still not exactly clear to me is what the heck this box actually does, other than cause me to spend a lot of time on StackOverflow.com! ;-)
To others who encounter a similar situation, I'm now quite confident that my settings were not corrupt, and if you're using the Express edition, please don't be mislead by MS documentation which may lead you to believe it's the "Just My Code" option. This option cannot be changed in the Express versions. (But it's not because you can't turn it on -- It's because you can't turn it OFF in Express!)
Thanks to everyone for your efforts.
I'm going to guess that it is trying to show you the equivalent of:
Application.Run(new frmMain)
This is the code that gets generated to startup your form. But in VB.NET this code gets burried. Create a Main() function and change your startup type to that with this line in it and repeat the process. You'll see it highlight Application.Run. That is the method that contains your Windows message pump loop.
Related
I’m working on a project in access with a series of existing modules. There’s amain module that runs the whole thing, but often there are errors and to troubleshoot sometimes i want to pick a specific subroutine and run that by itself. The problem is, sometimes when i click run>run sub/userform sometimes it gives me a list of subroutines to pick from and sometimes it just runs the whole thing and i can never tell which it’s going to do before i click it. Does anyone know why this could happen? Is it where I’m putting my cursor or something?
Ok, now this works?
well, any code in a code module? You can place your cursor in that code, or even in the debug window, just type in the name of the routine. So, F5 to run the code, or you can as noted even call the code in the routine from the debug window.
eg:
Call MyTestSub("John")
Or if the routine does not have any parameters, then just type into the debug window this:
MyTestSub
HOWEVER!!!
If you open code for a form? Then you can't use F5 to run that code, and if you do, then your get that prompt. The reason for this is rather complex, but a "form" represents what we call a "class object". And you can't just "run" such code, you a have to first create a instance of that class. And even more complex?
Well in theory, you can actually ahve the SAME form open 5 times!!! (and have 5 instances of the form running! So F5, or even just typing in the sub name DOES NOT work for a class module, and that includes code inside of the form.
So, how to debug such code? Well, in most cases, you have to launch the form, and then in code behind, set a break-point. Now go click the button, or whatever.
You can also in theory call + run the code in a form, and you would do it this way:
Call Forms("Test").Mytest
but, the form would have to be open. So, you can't just run code inside of a class module, or forms code module. They are "special" and work different from a standard code module. As a result, F5 to run such code does not work. In fact, the form has to be loaded first. But, even then, hitting F5 inside of forms code modules does not work. You can put in break points, and single step code (and often form events can make that debug process quite a challenge).
I'm having this InvalidOperationException
An error occurred creating the form. See Exception.InnerException for
details. The error is: Object reference not set to an instance of an
object.
pointing at this line of code:
Private Sub BeginningBalancesToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BeginningBalancesToolStripMenuItem.Click
inventory.MdiParent = Me <--error here
inventory.Show()
End Sub
EDIT:
Im only using drag and drop for creating controls from the toolbox. The thing here is, everything works fine until I relocated AND decided to return panel_001 to its previous location by pressing ctrl-z in the inventory.vb during design time to revert the change I made. The program runs fine without error prior to that specific panel relocation. I never edited any codes in the designer.vb and in the inventory class. I strongly believe that a piece of code wasn't properly restored at the ctrl-z action in the inventory.Designer.vb. Is this a visual studio bug?
EDIT: I tried creating a new winform and attempted to start fresh by foolishly copying & pasting all the controls and the forms' class and was no good. I assume the problem does not lie under the striked-out line above.
The Winforms designer has a knack for tripping really mystifying design-time exceptions. A side-effect from its strong WYSIWYG design, it will run some event handlers at design-time. Like Paint, making a control look the way it does at runtime. Nice, but that does come with a price. This can easily cause an exception if such an event handler was not written to operate correctly at design time. You are supposed to use the DesignMode property to keep the code safe.
Coming up with a way a Click event handler could run at design-time however requires massive amounts of imagination. That is an event that will not run at design time, the designer uses a layered window that intercepts any mouse clicks, using them for design use instead. Like selecting a control or displaying the design-time context menu.
I have actually seen the Click event of a ToolStripMenuItem run. The designer is not 100% watertight but it happened just once and I was hacking the code pretty hard. Coming up with a way that it could possibly run by using Undo is going to be difficult. Maybe you give it the Ctrl+Z shortcut, don't assume that guess is credible.
The way to deal with incomprehensible black magic like this is to just dismiss it and move on with your life. You just don't stand much of a chance to diagnose it and if you do then there's nothing you can do about it anyway because this isn't your code. Well, other than the need to use DesignMode, that may well be necessary. Not in this case. The only thing you have to watch out for is that such an exception did not destroy the InitializeComponent() method. That can happen too, you notice by controls being missing when you re-open the designer. Very unpleasant, you do need a good backup copy in source control to recover from that lossage.
OK! after giving it a few more tries, I found the answer. After the exception shows, copy exception details to clipboard and then I pasted it on Notepad. It had a lot of texts but the bottom part was the important one:
--insert wall of texts here-- in C:\Users\Ellen\Documents\Visual Studio
2008\Projects\SampleApplication\SampleApplication\Forms\inventory.Designer.vb:line
760 at CabuyaoWaterDist.inventory..ctor() InnerException:
It pointed me out to the specific line in the designer where the ctrl-z did not properly revert one of the label's caption
I have a vb.net Windows Forms application using Visual Studio 2010. At design time my buttons look like this:
at run time they seem to revert to a Windows classic style:
It only happens for this project which I took over from a developer who left. I want them to look like they do at design time. I'm stumped. Any ideas?
If the app starts from a Sub Main rather than a main form (See Project -> Properties -> StartUp Object) it might be missing this:
Public Sub Main()
' probably missing:
Application.EnableVisualStyles()
Application.Run(New Form1)
End Sub
When starting from a Main sub, be sure that EnableVisualStyles() is invoked very early in the procedure before any UI Objects are created.
If it starts from a main form, go to the same Project properties and be sure that both Enable application framework and Enable XP Visual Styles are checked.
If it still doesnt work, turn on Show All Files in Solution Explorer and open Application.myApp under My Project. Make sure this setting is true:
<EnableVisualStyles>true</EnableVisualStyles>
This file/setting should be managed by VS, so if it is not being updated to match the IDE, you might have other issues.
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 a program where I need to do some initial work before calling the form, so I disabled the Application Framework setting and wrote my own Main function with a call to Application.Run(myForm) when it's time to run the form.
Everything was working fine, no problems, but now I have need of some other service before opening the form. Rather than add all that code to this program, it has all been moved into its own executable. This second program can edit files that the first program will use, so I need the first program to wait so that it will read up those changes (should they be made). I suppose could just as easily use the Shell function, but for various reasons I'm creating my own Process object and calling it/waiting on it through that.
Anyway, I make this call to the second program some time before the Application.Run call. The first program waits its turn, and I can interact with the second program successfully, no trouble at all. But when it's done, the window for the first program is hidden behind any other windows that are on the screen. This doesn't happen in XP, only in Vista (and maybe 7, but I haven't confirmed yet). I've already tried manually forcing the form to appear in front, minimize then maximize, get focus, etc, but nothing brings it to the front unless the user manually clicks on it with the mouse.
What am I doing wrong? Why does this behavior occur? I know it has something to do with waiting for the executable to finish, because if I don't force the first program to wait everything is fine (other than it not waiting). I can circumvent the issue by calling the second program in the Load event of the form, but then I have to read the file a second time to catch the changes instead of reading it once, and it also looks bad because the form is being drawn really slowly while the second program is sitting there.
If anyone has any input, I'd appreciate it.
This isn't really an answer to why you're experiencing this behaviour, but a simple workaround would be to temporarily set the form's TopMost property to True in the load event. Then, depending on how intrusive you want that to be, you could either reset it under a short timer or wait for say the MouseEnter event to fire.
There are another topic in this site about that, but I not got the link. This problem seems be a bug into .NET framework. The API below (VB.NET example) works for me in windows XP and 8.1. Don't tested in other versions of Windows.
<Runtime.InteropServices.DllImport("user32")> _
Public Shared Function SetForegroundWindow(hwnd As IntPtr) As Integer
End Function
Private Sub Form_Load(sender As Object, e As EventArgs) Handles Me.Load
SetForegroundWindow(Handle)
End Sub