Are there any particular tools available for "Debugging" ExtJS script ? Especially, I findi it difficult to debug when the screen goes blank.!
Aptana Studio is optimised for Javascript development, including debug support for Firefox and IE, it even supports type-ahead on the Ext JS library (you might have to download some eclipse plugins separately).
Ext JS comes included with a debugging console (you need to add debug.js and call Ext.log("blah") to bring it up), this will provide functionality that is similar to Firebug on Firefox but not as extensive, still its useful for supplementing the poor development tools that come pre-installed with IE 8. Firebug (as Ergo mentioned here) is the most powerful of the browser-based development tools (it allows step-by-step debugging) however the latest versions of Chrome and Safari also come installed with develoment tools that are useful (but not as much as Firebug).
I find that running a debug trace throughout your application speeds up the process of finding bugs (see example below).
// Setup simple debugging tool
DebugManager = function {};
DebugManager.isEnabled = true;
DebugManager.log = function() {
if (DebugManager.isEnabled && arguments.length && console && console.log) {
try {
// Single parameter? pass it to console
if (arguments.length == 1) console.log(arguments[0])
// Multiple parameters? output raw arguments array to the console
else console.log(arguments);
} catch (e) {}
}
};
// Your function
function doSomething(myString) {
DebugManager.log("doSomething(myString)", myString);
// code for doSomething
}
You can then look up the console trace (Firebug is the best since it outputs full object information) and note the last function that executed before your code broke.
After many months of Ext JS development I have to say that Firebug + Aptana Studio combo wins hands down on other tools for development.
The Firebug Extension for Firefox is one of the best, to debug and test any web based framework. It wont necessary hand hold you, and you will need some familiarity with standard debug procedures, but is an excellent start. JSLint is another, online tool, for more advanced users.
I have found by changing my coding style, I've actually written more bug-free code. Usually when I see blank screens in IE, it has to do with trailing commas. I've started writing my ExtJS/JSON like this:
{
id: 'foo'
,name: 'bar'
,width: .60
,text : 'I am Jack\'s formatted code'
}
What this allows me to do is to move/comment/uncomment code around without having to worry about leftover commas. This coding convention has helped me greatly when it comes to refactoring other people's code as well as my own. Visually, it also becomes easier to ensure that the code is formatted properly.
I use chrome.
We can easily debug using "F12" to get the console, where it point out the line where the loading crashed, on clicking this line it goes to the cource to show the exact line of code.
Chrome's Development tool is that best so far when it comes to debugging ExtJs scripts. I've also used -
FireFox Developer Edition - This is pretty good and has lot's of tools available but for some reason I find it a little sluggish when debuggin ExtJs apps (CMD built in a single js).
IE Developer Tool - I know almost everyone hates it but sometimes we just have to live it with. (I find it not really bad). One problem is again - Very slow and hangs a lot of time while loading a big script. The whole script file is not even loaded at times - I forgot the exact figure but it's source viewer has a size/buffer/memory limit and cannot load the whole script and truncates whatever it cannot load - so you can get to your lines if the line exceeds that. This also happened in Firebug. But I've never faced such loading issues in Chrome.
Then again there are issues that happen only in certain browsers and you're stuck with debugging in that browser.
Related
I'm having some trouble with WebExtensions in Firefox. I've got some code to track downloads, and it's working in Chrome, but not in FF.
I've boiled the code down to the minimal surface that works in Chrome but not FF:
function handleChanged(delta) {
console.log(delta);
}
chrome.downloads.onChanged.addListener(handleChanged);
Whether I use chrome.* or browser.*, the behavior remains the same: it doesn't work. I've tried executing this line:
console.log(chrome.downloads.onChanged.hasListener(handleChanged));
After adding the listener, and it does log a value of true. Oddly enough, adding an onCreated listener works just fine:
function handleCreated(delta) {
console.log(delta);
}
chrome.downloads.onCreated.addListener(handleCreated);
This yields the expected object dump in the console when a download is started. Unless I'm missing something extremely obvious, I'm inclined to think this is a bug. It is not mentioned to the incompatibilities list, and it is documented by Mozilla. The thing is, I don't see anybody else asking this question online, so I'm inclined to think a bug is unlikely and I'm messing something up.
If it helps, I'm running Firefox 51.0.1 (32-bit) on Windows 7 Enterprise x64 inside of VMWare Workstation on a Windows 7 Enterprise x64 host. I'm loading the extension using the "Load Temporary Add-on" button. It's not a problem with the core manifest or add-on itself, because three other types of listeners are working just fine. The script is running as a background script.
I appreciate any guidance. Thanks!
Is there an equivalent of the browser console in AIDE? It took me trial and error to find out that it doesn't seem to support local storage (or at least the library that I'm usings implementation of it)
Should I wrap everything in one big try Catch block? I've googled and searched, I suspect I should be doing better error handling.
Here's what I ended up doing. You can share the published web app from aide when you're running it. Open it in Firefox for Android after downloading the console add-on. It's not as fully featured as a desktop version but it's close
It feels like poor form to answer ones own question, I earnt the tumbleweed badge for this so perhaps I can be forgiven!
I'm trying to debug quite a complicated module in my angular app. I've set a break point at the start of a particular method hoping I could follow it through and see where it's giving me back an error. However, it keeps bringing me into the VM scripts (VM28337, VM30559, etc). I can assume these all work as they should, so I have no interest in seeing them.
I know I can blackbox certain scripts in chrome debugger, but there seems to be an endless amount of these VM scripts. Does anyone have any suggestions on how to circumvent these scripts?
This doesn't appear to be possible in any version of Chrome at the moment. However, I create a Chromium bug to request it get added: Chromium Issue 526239
A development-time-only workaround can be to override eval in your page -
(function ()
{
var originalEval = eval;
eval =
function (script)
{
return originalEval(script + "\n//# sourceURL=blackbox-this.js");
}
}());
And then blackbox ^.*blackbox-this.js$
Same for setInterval/setTimeout when it gets a string (but that is a bad practice anyway, right? ;))
Does that work for you?
Is it possible to redirect the output of GWT.log() from the development console to a file? I need to debug a compiled GWT app and any logging or exception traces would be really nice.
GWT.log is compiled out, there is no way to get access to it when compiled to production.
On the other hand, GWT now has support for java.util.Logging, which can, when compiled in, send errors to the server for use however you want. It also can print these logging statements to a in-browser console, such as a popup or Firebug/Chrome Inspector. See http://code.google.com/webtoolkit/doc/latest/DevGuideLogging.html#Remote_Logging (and other sections on that page) for more details.
Keep in mind that unless you compile in full stack trace info, the exceptions will be very hard to read. See http://code.google.com/p/google-web-toolkit/wiki/WebModeExceptions#Emulated_Stack_Data for more info.
There is no way for a browser (without dev mode running) to write to a local file, for logging or other reasons. This is done for security reasons. Html5 might have support for some of these things, but they won't be supported in older browsers.
I have a Flash application that uses SharedObject to save and read some data locally. As it is said everywhere Flash saves the data from the shared object to disk when the application is closed. And indeed it does when I test it with the stand-alone Flash Player or all of these browsers: Firefox, Opera, Safari, Chrome, Flock... But it doesn't work when I use IE (I've tried IE6 and IE7).
Does anyone know anything about this issue? Why might it be happening... and how to get it to work?
Are you using MultipleIEs or standalone versions of the IE browsers? I've had issues with that as it seems they don't work properly when installed together.
The best way to be sure is testing your application on someone else's computer with only one version of IE installed.
EDIT: Check out the hints below:
It seems that if you install things in a special order evrything seems to work better.
Install/upgrade to IE8
Install standalone IE7
Install MultipleIEs (IE6 and below)
Also check the IE Collection (finalbuilds.edskes.net/iecollection.htm) tool instead of MultipleIEs for better results.