When encountering an error in the VBA code I am presented with two options: End or Debug. Now - perhaps after a company-wide upgrade to W10 - I experience that pressing "End" shuts down the program and pressing "debug" brings me to the code editor, but when I stop execution to correct the error, the program shuts down.
Is this new behavior a part of some security group policy?
Also, it seems as if Setwarnings is true, the code execution is simply suspended with no messagebox when encounting an error.
Thank you for your contributions. Especially that this is not a standard behavior. That led me to some findings:
1) No "Use Acces Special Keys" turns off error handling.
2) Using "frmInactiveShutDown v2.3 for MS Access from Peter's Software" (peterssoftware.com) causes the problem.
3) I had scripted me from using frmInactiveShutDown based on my network user name so I never noticed.
4) A major change in our network environment gave me another user name and I am/was thus subjected to frmInactiveShutDown.
I will refrain from trying to solve the problem in frmInactiveShutDown.
Related
Everything works without a hitch on NetBeans from starting up to writing a code and running it.
When It runs the code "successfully". It gives an exception error and won't close the Program execution from the execution tab below even though I click "cancel".
It will just keep showing my program running even though it is already ended.
Following is a few lines Log Data of exception error:
SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor org.apache.tools.ant.module.bridge.impl.BridgeImpl$PostRun
java.lang.IllegalArgumentException: Key contains code point U+0000
at java.prefs/java.util.prefs.AbstractPreferences.get(AbstractPreferences.java:296)
at org.apache.tools.ant.module.api.IntrospectedInfo$3.load(IntrospectedInfo.java:681)
at org.apache.tools.ant.module.AntSettings.getCustomDefs(AntSettings.java:119)
at org.apache.tools.ant.module.bridge.impl.BridgeImpl$PostRun.run(BridgeImpl.java:443)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
That's it. And if I keep running others programs. It will just keep stacking them in the execution tab below even though they are finished. I have to close my whole NetBeans Software. Then it will give a small pop-up box saying "Your programs are still running. Do you wish to close?" Then I will confirm it and it will close everything.
This is a annoying error!! I hope you understood the problem.
I would appreciate some help. Thanks!
we are using Sikuli with Java (Sikuli 1.1.1), but we are running into java.lang.ThreadDeath exception for a new client. In Java Configuration, we have selected mix code of Enable - hide warning and run with protections. Has anyone run into this issue before and what is the reason and possible fix?
Somewhere in the code Thread.stop() is being called.
According to the documentation don't do this! It releases all locks held by that thread may cause locked objects to be accessed in inconsistent state.
I have a complex MS Access 2013 database with tens of forms. On one of the forms, I have button with vba procedure back to it, which returns values from MS SQL(ADODB) and puts them into the textboxes.
Problem is, whenever i click this button, it steps into compile menu as if there was a breakpoint, but in fact there is no breakpoint. Of course there are no errors / MsgBoxes and If I just click F5 or F8, it goes well.
Has anyone the Idea, what may be wrong?
Phantom Breakpoints can usually be fixed by copying the line which stops the code execution into notepad. Then delete the line from the VBEditor and insert it again from the notepad.
If this doesn't work, try decompiling the database:
Open cmd and enter the following:
<full path to your database> /decompile
example:
C:\testDB.accdb /decompile
In fact you can just re-paste it from the clipboard, you don't need to use notepad. But don't paste it back into the same line. Delete the bad line.
Phantom Breakpoints don't go away with a restart.
This issue has been around for years and yet MS won't address it. Annoying!
Phantom Breakpoint strikes again :(
This showed up in such a strange way that I feel compelled to post it somewhere. This seems like the most obvious place, but I'm glad to move these comments elsewhere as appropriate.
I have an Access 2010 ACCDE giving me this same error: "Requested type library or wizard is not a VBA project" when I click a button on the main navigation form. I try an earlier version with same references and exactly the same code (in the nav form and other areas relating to the button) and it works fine. However, when I open the ACCDB used to build the "bad" ACCDE, and click the same button, I get a different error: Error 16 - "Expression too complex".
I fixed the issue by commenting out the associated VBA lines in the nav form and duplicating the uncommented code below the original lines.
The strangest part was that it wasn't until after several debugging sessions that it started behaving as the original posting above, where the it would break to the invisible breakpoint. It displayed the misleading errors above before that.
My standard practice now is to use Clear All Breakpoints (under Debug menu) after all development sessions. Hopefully that will prevent this in the future.
The phantom breakpoint thing has been an issue for a couple of versions from what I remember. Between that, and the new thing where the code window activates just by floating over it- even if you don't click in that window- I'm not sure I can endure anymore "Improvements". Hell the the program ran pretty damned good about 3 versions ago! Honestly the new "fluff" they've added - alternate colors on report lines-or other data in tables- I don't use any of that and spend more time taking off alternative line colors when I don't want it!
Fix more bugs and spend less time on new features!!!
Ghost breakpoint within referenced accdb code library!
Had a very similar problem. While starting the application it stops highlighting a line in yellow. Unfortunately the highlighted line was in a referenced accdb library for additional code which I share between different databases. The other databases still worked fine with the identical part of code. Deleting the ghost breakpoint line didn't help (references are read only anyway), so, the source of the problem should be within the code of the calling database and not where the call runs into a ghost breakpoint.
Toggle the reference then, of course with save and restart, stopped the ghost breakpoint.
Just in case there is somebody with the same problem connected to referenced code.
I'm a beginner iOS developer, and I'm trying to build a CRM system to learn the different aspects of developing.
I have a question regarding the preferred way to connect to an external SQL-server. I'm using Karl Krafts' Obj-C MySQL Connector by the way.
Right now I init the Database-controller (which in turn creates, then idles the connection to the server) object in my app delegate (didFinishLaunchingWithOptions), and that gives me some unwanted side-effects.. The screen is black a long time at startup if connection to the DB is slow, and sometimes the app is "too fast" and the query is trying to execute before the connection has been fully established - resulting in an exception being thrown.
The behavior I want (and guess is the preferred) is that the GUI loads up first, and then the initialization of the DB-controller and connection is established in a background thread - updating the GUI when the data has been acquired.
How would I achieve this? I have tried a number of different ways i've come across in my research, dispatch_queues and initing it straight from the viewDidLoad etc, but none give me the desired "GUI then data"-effect.
Also, would it be preferred to have an idling connection during the session of the program - or should each query 'connect - do its thing - disconnect'?
Regards, Christopher
Commandment One: don't do networking on the main thread - it's reserved for the UI. Else your app will have a laggy and frozen UI.
Commandment Two: instead of a lot of sequential synchronous calls, use asynchronous calls (GCD, background threads, etc.), events and callbacks. Cocoa (Touch) is designed with this in mind, so it's easy to do.
Commandment Three: if you launch something automatically, let it be launched when the app is fully ready. Let the call to the web service be the last one in application:didFinishLaunchingWithOptions:. Even better, let the user have the possibility to initiate the login via a user action, i. e. by pressing a "Login" button.
Commandment Four: read the first three Commandment again and keep them in mind. Practice them until you know them well.
It's a simple problem. Sometimes Windows will just halt everything and throws a BSOD. Game over, please reboot to play another game. Or whatever. Annoying but not extremely serious...
What I want is simple. I want to catch the BSOD when it occurs. Why? Just for some additional crash logging. It's okay that the system goes blue but when it happens, I just want to log some additional information or perform one additional action.
Is this even possible? If so, how? And what would be the limitations?
Btw, I don't want to do anything when the system recovers, I want to catch it while it happens. This to allow me one final action. (For example, flushing a file before the system goes down.)
BSOD happens due to an error in the Windows kernel or more commonly in a faulty device driver (that runs in kernel mode). There is very little you can do about it. If it is a driver problem, you can hope the vendor will fix it.
You can configure Windows to a create memory dump upon BSOD which will help you troubleshoot the problem. You can get a pretty good idea about the faulting driver by loading the dump into WinDbg and using the !analyze command.
Knowing which driver is causing the problem will let you look for a new driver, but if that doesn't fix the problem, there is little you can do about it (unless you're very good with a hex editor).
UPDATE: If you want to debug this while it is happening, you need to debug the kernel. A good place to pick up more info is the book Windows Internals by Mark Russinovich. Also, I believe there's a bit of info in the help file for WinDbg and there must be something in the device driver kit as well (but that is beyond my knowledge).
The data is stored in what's called "Minidumps".
You can then use debugging tools to explore those dumps. The process is documented here http://forums.majorgeeks.com/showthread.php?t=35246
You have two ways to figure out what happened:
The first is to upload the dmp file located under C:\Minidump***.dmp to microsoft service as they describe it : http://answers.microsoft.com/en-us/windows/wiki/windows_10-update/blue-screen-of-death-bsod/1939df35-283f-4830-a4dd-e95ee5d8669d
or use their software debugger WinDbg to read the dmp file
NB: You will find several files, you can tell the difference using the name that contain the event date.
The second way is to note the error code from the blue screen and to make a search about it in Google and Microsoft website.
The first method is more accurate and efficient.
Windows can be configured to create a crash dump on blue screens.
Here's more information:
How to read the small memory dump files that Windows creates for debugging (support.microsoft.com)