One of the tasks for my current project is trying to find the source of the following console error:
I have looked through all the references to the window object as well as the luma.gl library but can't seem to find where the issue is originating. It doesn't seem to break anything but is more of an annoyance when debugging as it pops up over 20 times in a row whenever the page is refreshed. Here are the versions of Deck.gl and Luma.gl from package.json:
Just want to know if anyone has encountered this before and how you might have fixed it. Thank you.
I have eliminated all calls to the window object within the project to no avail and have looked through polyfill-context.js inside the #luma.gl library with no luck either.
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
I am trying to solve an issue in my application which is abruptly crashing whenever the application use 'MIngliu' font. In order to solving and finding that bug I tried to dedug the WinCE6.0 OS kernel, and found in the output window that "DEBUGCHK" macro is failing in fontfile.cpp. But the problem is that fontfile.cpp is not available with us.So please suggest what can be done inorder to fix that issue if it is a part of kernel..Here I am also attaching the snapshot of the output window of visual studio.The last line of the window is showing the error..
I'm in a tight spot with this error...
I have a DataGrid with some data. Based on some other parameters defined by the user, my application loads data in the background.
So far, everything worked fine. However, I've stumbled upon the following error today:
Error HRESULT E_FAIL has been returned from a call to a COM component.
This error appeared completely out of the blue; I was using my application and then, suddenly, this appeared when I selected a new row. It consistently appears for a specific row with specific application parameters, and so far hasn't appeared in any other case.
The error doesn't come with a StackTrace (which is null) and neither with an InnerException.
As such, I'm a bit bewildered and don't quite know what to do. I can't post the entire application here, and that error gives me absolutely nothing to go on. It does, however, cause the entire application to stop working (when no debugger is attached the application just "vanishes").
What should I do with this?
PS. The application is an Azure Silverlight application, but this happens regardless if I run it on the Dev. fabric or if it's online. But my gut tells me it's an issue with Silverlight itself, and not with Azure.
When trying to restore a version of a document in my document based application, I get an error:
kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList(). Compensating...
kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged.
and the document remains unchanged. Also, when this happens, I get a message as soon as I start editing the document telling me:
The document [...] could not be autosaved. The file has been changed by another application.
I think these two problems may be related.
I don't know what to do or "check" because versions just works without any implementation needed; I'm actually confused, because Apple says that I just need to enable autosave in order to restore/revert using versions. Does anyone know what can be causing that error?
Thanks.
I've ran into all of your issues, causing me much pain.
I've gotten that error message regarding kCGErrorFailure... before as well when browsing versions. I've just ignored it mostly as it seems harmless to me. TextEdit seems to spit out this message as well. (Looks like an Apple bug)
For the "document remains unchanged", check here: Restoring from versions browser on OSX lion not working... ideas? (in short, your code for updating your document's UI is probably not being called for the document that is being reverted) (Looks undocumented to me)
For autosaving issues, check here: http://www.cocoabuilder.com/archive/cocoa/306217-how-to-implement-autosaving-browsing-versions-reverting-to-last-saved-in-lion.html (in short, use the file wrapper methods instead for reading and writing). (Looks like an Apple bug)
As well as returning YES to autosavesInPlace: your document needs to at least call updateChangeCount: passing NSChangeDone whenever it changes, so that it "knows" that there are changes to be autosaved.