after migration from Vaadin 7.0.3 to Vaadin 7.1.8, Vaadin client side produce Exception when mouseenter/mouseleave event over Chrome plugin (NPAPI plugin).
creation plugin object code:
Label pluginContainer = new Label("<OBJECT ID=\"chromePluginObj\" NAME=\"chromePluginObj\" WIDTH=\"100%\" HEIGHT=\"100%\" type=\"application/x-umekcc\"></OBJECT>", ContentMode.HTML);
pluginContainer.setWidth("100%");
pluginContainer.setHeight("1115px");
pluginContainer.setStyleName("htmlLabel");
addComponent(pluginContainer);
screenshot of app:
when trigger mouseenter/mouseleave on plugin object:
also when i open window (vaadin window) or make other UI changes, vaadin ?recreate? my object, and browser send NPP_Destroy event to NPAPI plugin, and its destroy:
Maybe there is a possibility to specify Vaadin not recreate my NPAPI plugin object?
also apologize for my bad English))
This kind of problem can be caused by a corrupted widgetset. Flush your webapp's VAADIN directory, then recompile the widgetset. If this doesn't help: recompile the widgetset without the pretty option instead of obfuscate to get more information about where in the JavaScript code the clientside exception occurrs.
Related
I have a question about ract-router 2.0 migration in my React app.
I removed every mixin and calls to this.props.history, like explained in the migration guide, but I still have warnings about it in the console :
Warning: [react-router] props.history and context.history are deprecated. Please use context.router
Actually, I found out in the debugger there is one warning for each nested component on the current page : RouterContext, App, and Posts
Any idea where it could come from ?
There's a bug with RC4 and the React DevTools that come from the dev tools attempting to inspect all the props and context. This will be fixed in the new RC.
You can disable this warning by going to /node_modules/react-router/lib/RouterUtils.js and commenting out lines 28-30.
I'm using MVVM Light and everything is fine except when launching my Windows Phone 8.1 WinRT app as a Share Target.
When I try to assign MainViewModel viewModel = ServiceLocator.Current.GetInstance<MainViewModel>(); I get an exception for ServiceLocator.Current.
Exception Message: ServiceLocationProvider must be set.
Do I need to do something extra in App.xaml.cs OnShareTargetActivated event to insure the Locator is running?
UPDATE:
A ShareTarget page needs to be thought of as a small extension of your app. It seems that not all of the app's resources are loaded (including app-wide resources in App.xaml). So I just created a new instance of MainViewModel in the share page's constructor, loaded only the things I need for the share to complete, save the information and call ShareOperation.ReportCompleted. This returns the user back to the app that is sharing.
I still haven't found a good solution for getting other resources in my ViewModel, but this works for now.
This indicates that the following line has not been executed:
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
This line will instruct the ServiceLocator class to use the SimpleIoc.Default instance as its ServiceLocator.Current. When you run your app as a Share target, the initialization is slightly different and probably the ViewModelLocator doesn't get initialized. You need to find a good location to perform the initialization before you use the ServiceLocator.
Cheers
Laurent
I know that AngularJS by default catches all application exceptions and then logs them to the console. That makes the 'Pause on uncaught exceptions' button in Chrome (which I use a lot) useless.
Many times I encounter small javascript errors in my code (like accessing members on undefined variables) and I'm really used to pausing on the exception and inspecting the situation.
The only solution I have by now is either to put a breakpoint on the code which is triggering the error (impractical) or to use the 'Pause on all exceptions' button, but I have to continue on all errors generated by default by jQuery, Angular and other frameworks, and that's also very nasty.
I also tried overwriting the $exceptionHandler service, and put a breakpoint in it, but I don't have access from the call stack in the function that generated the error.
So, is it possible to use the 'Pause on uncaught exceptions' with AngularJS apps?
According to the Angular docs,
https://docs.angularjs.org/api/ng/service/$exceptionHandler
This example will override the normal action of $exceptionHandler, to
make angular exceptions fail hard when they happen, instead of just
logging to the console.
angular.module('exceptionOverride', []).factory('$exceptionHandler', function() {
return function(exception, cause) {
exception.message += ' (caused by "' + cause + '")';
throw exception;
};
});
This will cause them to be handled by the browser dev tools, which will allow pause on caught exceptions, usage of source maps for nice stack traces, etc.
Presumably you don't want this to happen in production, and also don't want to have to add/remove this code continuously during development. We solve this secondary problem by having a 'dev' module which adds to and overrides our production code during development. For example:
In dev.html:
<html ng-app="devApp">
...
In dev.js:
angular.module('devApp', ['mainApp'])
.factory('$exceptionHandler', ...)
The "Skip stepping through sources" is no longer available in Chrome, but - there is a new option - you can right click any script in sources/sources and choose 'Blackbox script'. Then you can turn on 'Pause on Caught Exceptions' without worrying about jQuery and other errors. Personally I use it always on jquery.js and angular.js.
You can enable Skip stepping through sources with particular names in DevTools and set it to something like this:
(jquery|angular|diigolet)
I'm getting compile time error when linker option = "SDK Only" with "Failed to resolve Android.App.Fragment" message. It's all started when I added Google Maps support with FragmentActivity to my MonoDroid application.
With Linker option = "None" everything works just fine except of the fact that .apk became huge (~30mb instead of 7mb when link SDK Only enabled)
Error details:
The "LinkAssemblies" task failed unexpectedly.
Mono.Cecil.ResolutionException: Failed to resolve Android.App.Fragment
at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference)
at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference)
at Mono.Linker.Steps.MarkStep.InitializeType(TypeDefinition type)
at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly)
at Mono.Linker.Steps.MarkStep.Initialize()
at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
at Mono.Linker.Pipeline.Process(LinkContext context)
at MonoDroid.Tuner.Linker.Process(LinkerOptions options, LinkContext& context)
at Xamarin.Android.Tasks.LinkAssemblies.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()
I found a lot of similar problems (1, 2, 3) and the only proposed solution was to disable linker which is not the case for my app.
How can I diagnose and fix the issue?
TIA!
Are you referencing Mono.Android.Support.v4 classes everywhere?
I've been struggling with the same issue on and off for a while now. Currently, I have had success in switching to the Alpha channel of Xamarin Updates and using the alpha builds of Xamarin.Android and Xamarin Studio. Running those alphas, I have been able to make release builds with Linking enabled with no issues. Hope that helps!
Eventually GooglePlayServices Xamarin Component has been updated to 12.0.1 and not it could used without any errors even with "SDK Only" linker flag. You can use it right from component store without any bindings pre-compilation.
I'm trying to add an event listener to my air application that would prevent the "ActionScript error" window from appearing, so I can handle the error within my application.
I was able to find a little information about this from adobe. I'm just not sure what I should be listening for.
It depends quite a lot on what error is thrown, and why.
Your best bet is to carefully read the ActionScript documentation and add listeners to react to all of the errors that have explicit ErrorEvents (such as IOErrorEvent and SecurityErrorEvent). Those are usually related to network and/or file access, and security issues.
For most other errors, there is the try {} catch() {} finally {} statements. This tutorial might be a good place to start.
And if all else fails, there's UncaughtErrorEvent.
But you should really be using that one as a last resort, not as a magic bullet - the best error handling is a) trying to prevent errors from being thrown in the first place (make sure all variables are properly initialized, test for null, etc.), and b) handling expected runtime errors by catching them explicitly, in order to keep the application running and stable.
You have a couple options. As you know, exception handling is not always possible for certain asynchronous operations.
First off, you need to know what object is responsible for the asynchronous operation that is causing the error. The most sensible approach would be to add the necessary error event handlers to this object.
For instance, a URLLoader performs asynchronous operations; and it's failure can only be handled by adding error event listeners. For example:
var loader: URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, completeHandler);
loader.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
Another 'catch-all' option is to take advanage of the new UncaughtErrorEvent feature of Flash Player 10.1. For this to work, you need to attach the uncaught error handler to the loader of the main application; this will catch everything! For example:
loader.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, loaderErrorHandler);
private function loaderErrorHandler(e:UncaughtErrorEvent):void {
if(event.error is Error) {
// handle error from embedded SWF
}
// suppress error dialog
e.preventDefault();
}
The last option may not be the best approach as it promotes the swallowing of exceptions instead of addressing and handling the problem properly; nevertheless it can be useful in certain unique circumstances (embedding SWFs).
The window won't appear if you're running the standard version of Flash Player.
It will manifest only as a dialog box on the debugger versions of the
browser plug-ins and stand-alone players, as a message in the output
panel in the authoring player, and as an entry in the log file for
Adobe Flex Builder 3. It will not manifest at all in the release
versions of Flash Player or AIR.
Source : here.