I'm using a com object from jscript.dll
IActiveScriptSite is implemented, so when there is an error, OnScriptError is triggerd.
That works fine, but on some desktops, the error is not triggered, the script just stops executing when the error occurs.
I guess there's a setting on windows, maybe on iexplore, but i just can't find it.
Related
So i tried to get the following tool/script running but now after getting the script itself to run it comes with an error. Basically that error seems to only occur when i use the "start" command. i was able to set the download-path, time and add the streamer etc.
https://github.com/Instinctlol/automatic-twitch-recorder
(Cmd) start
Daemon is started.
(Cmd) error:concurrent.futures:exception calling callback for <Future at 0x1a83e838390 state=finished raised AttributeError>
I am a beginner in programming tyia
some insight of the error what its caused by and what it means
I am currently trying to setup code analysis for a legacy WPF application. As part of this I am running FxCop 10.0 but I'm receiving errors for some of my DLLs, all of which build successfully.
The error that I'm getting is:
When I get this it is usually on a get or set property, there doesn't seem to be anything obvious as to why this is happening. I can't seem to be able to recreate this in a sample application. An example of a section of code causing this error within a set is:
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Normal, new Action(() =>
{
OnPropertyChanged("MyProperty");
}));
In the above code, if I remove the Dispatcher code FxCop successfully analyses the code, however leaving it in causes an error to be thrown. There are other instances of similar code working fine. Does anyone have any idea as to what could be causing this error?
Have been searching for a solution to this problem for days with no luck so I decided to post here and hope someone can help me. What makes it even harder is that I can't replicate this problem on my computer very consistently. Sometimes I will get the error but most of the time I won't.
Basically what is happening is I am creating an IE object which my program then controls for a long period of time. What is happening is, if a user exits the program it calls oIE.Quit() then closes the program. This should close internet explorer and all processes associated with it.
But, the iexplorer process doesn't end up closing. Then when the user tries to run the program again we get this error "System.Runtime.InteropServices.COMException (0x80004005): Creating an instance of the COM component with CLSID {0002DF01-0000-0000-C000-000000000046} from the IClassFactory failed due to the following error: 80004005.".
To fix this we simply close the any iexplorer.exe processes that are open and it will let us create our ie object again. This happens also if the program crashes and they try to restart it.
I am not sure what is causing this or if I am missing something that has to do with com objects. But I am simply stuck.
Here is some code although plugging in this code likely won't reproduce any errors:
'create ie object
oIE = New SHDocVw.InternetExplorer
oIE.Navigate("http://www.google.com")
oIE.Visible = False
oIE.Silent = True
'kill ie object
oIE.Quit()
The exception you get is hopeless, that's E_FAIL, "Unspecified error". There isn't any obvious reason why this would fail, starting another instance of IE when your program starts back up shouldn't be a problem. Well, short from those ghost instances of IE that keep running forever. I would guess that you got this exception for the same reason that IE didn't quit when you called Quit() the last time.
Do consider the kind of mishap you'll create when your program aborts and doesn't get around to cleanly shutting down IE. Using Environment.Exit() would be quite unhealthy for example. Or any other kind of nasty kaboom that doesn't let the finalizer thread run at termination. Maybe that has already happened many times before, now IE just refuses to create any more instances? How many instances do you have to kill when you need to get it going again?
The much better mousetrap here is to run IE in-process in your own program rather than out-of-process with SHDocVw. So that when your program terminates, it takes IE with it. It is also much more efficient, there's a lot of overhead involved in making out-of-process COM server calls.
You do this by using WebBrowser in your program.
If I have a main procedure with error handling that calls other procedures without error handling, should errors roll up to the main procedure?
What if the procedures without error handling use functions without error handling?
Should everything roll up to the main procedure's error handling?
Yes, unhandled errors will roll up the stack. If you have no error-handling in your main routine (or in the current event-handling routine), then the error will roll up to VBA itself, which will either cause your program to abort, or reset the VBA environment within the host applicaton. (you don't want that).
I can think of two apparent exceptions to this: one illusory and one real:
1) If VBA is entered through an unanticipated event-path, instead of though the main routine, it may appear that your Main-routines error-handler is being bypassed by the error-return, but in reality, it's another thread, so when it rolls-up from an event-handler, it goes to VBA independently of your Main routine's main-thread.
2) The VBA error-handling cannot catch ALL errors, in particular, most FATAL errors cannot be caught by it and crash (and reset) the whole VBA environment. "Stack Overflow" errors are an example.
Procedure A with error-handling will catch all errors. Procedure B with no error-handling will catch none.
If A calls B and B has an error, it will roll up and be caught in A's handler.
If B calls A and B has an error, there won't be any handling.
If B calls A and A has an error, A will catch it.
Whether it's a function or a procedure makes no difference. However it's worth noting that a class module won't handle errors locally, but passes them back up the stack to the first non-class module.
I'm not sure what you mean by "should," but where you want an error caught can depend on what you want to do with the error. For example, if a certain error requires you to make a small tweak on a string and then resume where you were, then you want very local handling. In other cases, simplicity might call for top-level handling.
Errors not locally handled will always* get trapped by the up-the-stack error handler if the error trapping option is set to "Break on Unhandled Errors". You'll find this setting in the IDE under Tools Options.
If it's set to "Break on All Errors", no error handler (neither local or up-the-stack) will be called. If it's set to "Break in Class Module", no out-of-class error handler will be called for in-class error.
Note that this option change the line on which the debugger stops: when an unhandled error occurs in a class module, the debugger stops on the line calling the class with "Break on Unhandled Errors" or on the offending line in the class with "Break in Class Module".
In Access, this option can be read programmatically with Application.GetOption("Error Trapping") and Application.SetOption("Error Trapping").
*As RBarryYoung has written, the most fatal errors (like stack overflow errors) won't be caught by any VBA error-handling.
I have some VB.NET code that creates a TransactionScope instance:
LoggingUtility.LogDebug("UpdateCallTable", "SatComCallDataImporter", "About to associate call data with contracts")
Using ts = New TransactionScope()
LoggingUtility.LogDebug("UpdateCallTable", "SatComCallDataImporter", "Getting all unimported SatCom calls")
My application is throwing an exception on the call to the creation of a new TransactionScope, with "Object reference not set to an instance of an object.". The exception isn't thrown on my development machine or my test machine; only on the customers production machine, and I have no idea why. I've placed debug lines immediately before and after this line so I'm positive it is this line causing the problem.
A have used TransactionScopes throughout the application and this is the only place throwing the exception on the client machine.
"About to associate call data with contracts" gets written to the log and the next log entry is the "Object reference not set to an instance of an object".
Code works fine if I move it out of a transaction.
I've been struggling with this for 4 days now and have got no closer.
Perhaps you have an issue with MSDTC?
I'd lean more towards a coding error though, because the TransactionScope object should be initialised and non null, but it will be indicating an error.
Perhaps showing us the code might help us further?
UPDATE: I've had experience with logging engines failing to log the line before an exception, which is sometimes caused by release mode reordering, or the routine doesn't flush actively and the app crashes nastily before it can complete.
I would suggest placing a logging line directly after you using() statement to assert that the TransactionScope is not null. Given the way you have used the code, it is IMPOSSIBLE for the result of that code to return null, the constructor must throw an exception if the constructor fails, otherwise you have a non null transaction scope.
Perhaps a little more code and this test might help some more?