I have an application in vb.net that I'm testing out in Windows 10 and I seem to be getting an error (Images below). This app works flawlessly in Windows 7, and it actually works without any issues in Windows 10, the problem is, when I exit the application is when I get the error.
The way it's structured, is if I run it from IDE, i first see a Login Windows where user logs in and then goes to MENU. If it's run in our environment, user does not have to log in, so the log in form never appears, it goes directly to MENU.
Everything works great, until I go to EXIT Application, where it gets all messy, this is the code from EXIT button...
Dim Answer as Integer
Answer = MsgBox("Are you sure you wish to Close the application ?", MsgBoxStyle.YesNo)
If answer = vbYes Then
End
End If
These are the errors I get:
First I get this error, clicking on CLOSE PROGRAM closes it completely, if I click debug I get the below windows....
With the 2nd error it shows that I actually have VS2010 and VS2012, and it lets me debug. The issue is, the source code is in TFS, and it just so happens that I can't access the TFS from my windows 10 machine, (only from Win 7). So I can't debug it. But is there a reason why this is happening only in windows 10?
I even went as far as doing Me.Close() before END to make srue that the form is closed. And again, it works fine in Win 7, but win 10 it gives me the same problems.
Using "End" to close a program can be problematic; the comments and answer to this SO question explain why that is. As for the second issue that popped up once using Application.Exit(), that is a simple case of your program referencing multiple assemblies that have function calls with the same name. In this case, both the explicitly imported Microsoft.Office.Interop.Excel and implicitly imported System.Windows.Forms have "Application.Exit()" members. Since you have explicitly imported Excel, the compiler goes with that one when it's forced to decide which Exit() to use, which throws an error because of the context it's being used and doesn't actually close the program. To rectify that, all you have to do is explicitly tell the compiler which Exit() you want to use by replacing
Application.Exit()
with
System.Windows.Forms.Application.Exit()
Related
So, I have an MS Access front-end that I'm compiling to an ACCDE, which I want to distribute. When running it from an ACCDB file, everything works fine. I have a welcome form with links to a bunch of different forms. Some I call with DoCmd.OpenForm, with others I create an instance of the form with Set frm = New Form_Name, and then show it with frm.SetFocus and frm.Visible. While testing and developing a number of different things, opening forms hasn't been a problem for what feels like an eternity.
But then I compiled the ACCDE, and for some reason, opening forms has stopped working. While the welcome form miraculously works just fine, opening any other forms from that welcome form generates an error 3000 with a description which is something along the lines of "reserved error (-3034); there is no message for this error" (might not be 100% accurate since I'm translating from German). This is regardless of if I call it with DoCmd.OpenForm or create a new instance.
Here's the weird part: this only ever happens once for every form after compiling. That means, if I launch the form again after the error, even after closing the front-end entirely, then it works. I've checked over and over again and there are no variables being used, so there isn't the chance of some variable being uninitialized. Now, I could just execute every form on the ACCDE file after compiling it, but that seems like a ridiculous workaround. Plus, it doesn't make any sense, either, since I'm not storing any data in the front-end.
And oddly enough, this happens with all forms except the welcome form. The welcome form is launched by a macro, but I've ruled that out, since some of the forms that I launch from the welcome form used to be launched with macros, and I had the same problem there. The biggest difference between the welcome form and the other forms is that the welcome form is an unbound form.
Oddly enough, Google has not led me to any people with the same problem. Has anyone else ever had this problem or know what could be causing it? This isn't only happening on my computer, in fact, I was alerted to the problem after I had distributed an alpha version of the front-end. I'm using Access on office 365, version 1908, in case it makes a difference.
I have a button click event in an Access form that sometimes opens the VBA editor with the 'On Error...' line highlighted as if it is in debug mode. I can F5 to continue the rest of the procedure and it works fine.
It doesn't happen everytime. It seems random except there seems to be a pattern that it happens on the first click of this button right after the file is opened. Not everytime though.
Any thoughts on this or previous experience with the same thing happening and subsequent solution? What might be causing this? It's a terrible user experience.
Well, before running any code (hold down shift key during startup to prevent any code from running).
Now, ctrl-g (jump to VBA IDE). Now from tools. Choose
debug->Clear all Breakpoints
Like this:
Now, open up any code module - hit enter key to "dirty" the code. Now choose debug->Compile (first menu option). It will say Compile "my app name".
Make sure the code compiles. If it does not, then stray break points can still exist.
Next up, you need to check/change the default behavior for a error.
While STILL in VBA editor/IDE
From menu bar choose tools->options. The default is "Break on Unhandled errors"
If you have break on ALL Errors? Well then code that even assumed to trap or even on-error resume next code it BLOW UP and stop. Often developers will say try for existence in a collection, and we error tap to "mean" the element is not in that list. However, the THIS assumes that the default Error trapping setting was not change.
So, double, and then triple check this setting. You can develop for years, and even have some code ASSUME to error out. But that years of development code assumed the default (break on unhandled Errors. If you have break on all errors, then your are toast, and you find all kinds of breaking of code. (the idea of that option is to LET you debug code with error handling without having to disable errors. And with say on-error resume next, you in effect can't debug parts of code anymore.
Now, if above steps don't fix your issues?
Then the next step is to de-compile your application. This will remove the compiled (binary) part of the application. Once you do this, then you do a full re-compile.
To de-compile, you can't do this from the IDE, and you have to use a FULL qualified path to your existing version of access. Say like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE"
"c:\MyCoolApp\Invoice.accDB" /decompile
Now, when you run above, you REALLY must not let any startup forms or code run. (hold down shift key. Now exit access/application. Now re-launch (and again no code to run on startup).
Now, at this point I high recommend a Compact+ Repair (and AGAIN no startup or code to run). So even on the C+R, you have to hold down shift key.
If you during the decomp, start application, then C+R allow ANY code to run, then you have to start over again at the first decompile step.
Ok, now you done the C+R. Now ctrl-g, and now debug-compile.
I was working on a Windows app today, when my errors were no longer being displayed as they usually would. Instead, the debugger just jumps out of the method. The output window makes a note of the exception, but the usual popup trace does not appear.
It works in other projects, and I have put Dim i as Integer = "A" as my first line to try and raise an error, but it just exits the sub on that line.
Any ideas how I get it back?
There is a bug in the interaction between the debugger and the 64-bit version of Windows 7 that strikes in the Load event. An exception is trapped and swallowed by Windows, the debugger never gets a chance to detect that it was unhandled. The only thing you'll see is a "first chance" notification in the Output window. The Load event handler will immediately terminate and your program keeps running as though nothing happened, assuming that it didn't bypass a critical piece of initialization code. This bug has been around for a long time and is well known to Microsoft, apparently it is difficult to fix.
You can work around this bug with Project + Properties, Compile tab, scroll down, Advanced Compile Options button. Change the Target CPU setting to "AnyCPU". Another way to trap it is with Debug + Exceptions, tick the Thrown checkbox on CLR Exceptions. Yet another workaround is to put initialization code in the constructor instead of OnLoad() or the Load event. You only really need Load when you need to know the actual size of the window.
This bug will only strike when you debug. It won't happen on your user's machine.
UPDATE: I expanded a great deal on this mishap in this post.
Under the Debug->Exceptions check that the Common Language Runtime exceptions are checked.
Has your .suo file been deleted by any chance (this is the file that stores your personal state of the solution, your settings, what is expanded / collapsed). You will only really spot this if you suddenly noticed that you had to hit "collapse all" because it had forgotten, it will recreate this when you open the solution, but will do it with default settings.
If so, hit CTRL + ALT + E and re-tick the break on exceptions tick boxes for CLR exceptions.
When an exception is thrown in my app, I expect the debugger to stop running and enter debugging mode, but it does not. Instead, I just get a message in the Immediate Window ('A first chance exception ...'), and the program keeps on running like if nothing happened. However, the sub (in which the exception was thrown) is exited, so statements after the exception are not executed. Since this sub makes the initialization of my program, running becomes very unstable.
How can I tell the debugger to stop execution when an exception is thrown?
(I use VB 2010, and did not change any setting of the debugger.)
UPDATE:
Thanks for the quick answer. Unfortunately, I still can't get it the way I'd like.
On the 'Advenced compile options' page I don't have 'Target CPU'. Maybe it's that I have only VB Express?
If I tick the 'Thrown' checkbox in Debug > Exceptions, execution stops even if I have a catch for that exception, and I don't want that.
Until now I used VB 2008 on 32 bit, and everything worked fine, but since I moved to 2010 64 bit I just can't get it right. Any suggestions?
Debug + Exceptions, tick the Thrown checkbox for "Common Language Runtime Exceptions". The debugger will now stop on the first chance notification.
The usual cause is a catch statement in your code, maybe the VB.NET On Error statement. Or a bug in the 64-bit debugger's interaction with Windows Forms. After it breaks, use Debug + Windows + Call stack and check if the form's Load event handler is on the call stack. The bug causes unhandled exceptions to be swallowed without a diagnostic.
To work around that, use Project + Properties, Compile tab, scroll down, Advanced Compile Options. Change the Target CPU setting to "x86". This is the default setting for VS2010 projects btw. You'll now use the 32-bit debugger, it doesn't have this problem. And you can use Edit + Continue.
I know this is an old thread but I hope it may help others..
I was facing a very similar problem at startup of my forms.
I put my code in "shown event", instead of "load event" and it is SOLVED !
I mean I get exceptions as expected, and my codes do not exit silently.
I know they are different events but for me it didn't make any change.
BTW, my env: VB.net Express 2010 on Win7 64 bit
To get the Target CPU option you must have expert settings selected in VS2010 express. Go to Tool|Options and check expert settings.
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?