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.
Related
I am getting a little desperate here: Almost every time I try to use the Firefox browser tools (FF 66.0.3 on Mac, but has been the same in previous versions) to inspect an element, when selecting any page element to show its code in the inspector, the inspector switches to the javascript debugger, marks an error in the jquery.min.js file (complete first line of three) and causes the browser to hang, i.e. I can still scroll the window, but more or less nothing else (for example no reload, no clicking a link would work etc.)
The debugger shows Error: Permission denied to access property "nodeName". I am doing nothing special, I just use the inspector and try to select any element on the page.
The crazy thing is that this happens on most websites, even here on Stackoverflow, so I suppose some particular browser setting must cause this.
I know this is a vague description and therefore a bit off-topic, but I'd be very grateful for any hints how I could fix this.
You most probably have the "Pause on exceptions" and "Pause on caught exceptions" options set to on:
These will cause the debugger to pause javascript execution whenever an exception is thrown, even though the exception has been caught e.g by a try catch block, like many test codes use.
You can un-toggle these to enjoy a more natural experience or click the play icon to resume the javascript.
I have written a code for Web page. The process requires me to click on a weblink which opens up a new window, then perform some operations on the browser window. Then I close the new browser. This is repeated multiple times in the code. All the elements on all the browser windows are normally identifiable using the object spy. However, intermittently during run time when a new browser window opens up the elements on the page are not getting recognized (hence it throws errors). When i go into the debug mode and try using the object spy the maximum identification i can capture is Browser(<>).Page(<>). Nothing in the page is getting recognized.
Now if i close this browser and reopen it and check again, the elements on the page are getting captured by the object spy and i can continue with my script execution. Sometimes I have to close and reopen multiple times for it to work.
Is there any way to handle this scenario. check for object identifications on the run time maybe. Dunno if it this is any relevant but i am not making use of the OR in my project.
Thanks in advance.
This sounds like a bug in UFT and you should contact HP's support.
A workaround if you know where the problem is probable to appear is to add Browser("<name>").RefreshWebSupport. This is an undocumented feature of UFT that sometimes helps in cases like this.
I am making a windows phone 8 application and in the designer view in both blend and VS I get "Unable to determine application identity call" error as a dialog box.
From what I read on stack this is propably because of the Isolated Storage is getting run and the designer can't handle it.
I am wondering is there away I can get some line numbers or something where the errors are happening instead of having to manually go through the code?
By the time you see this message box it is already too late, the exception was caught and handled. You have to catch it when the exception is raised. Which is not so easy to do at design time.
One technique that's worth a shot is to use a debugger to debug Visual Studio itself. Start it again and use Tools + Attach to Process. Locate the first devenv.exe in the list of processes and select it. Set the Attach to: setting to "Managed (v4.5, v4.0)" and click OK. Let it trundle to find the PDBs (takes a while). Debug + Exceptions, tick the Thrown checkbox for CLR exceptions.
Switch back to the original instance of VS and do whatever you did before to trigger the error. The 2nd instance will break in when the exception is thrown. Which some luck you'll see your code on the Call Stack window. If the debugger doesn't break then repeat the exercise but attach to XDesProc.exe, the XAML designer. Good luck with it.
Isn't this
Unable to determine application identity of the caller?
or
Getting Unable to determine application identity of the caller Error
are the same topic????
Don't know, just asking...
Sorry for any inconvenience..
Just answered in my basic question.
I'm afraid, i don't know how to get exact string number, just keep in mind that Designer cant have an access to the IsolatedStorage and check all places where you're working with IsolatedStorage. Basically, what you need to do is to add to all constructors a lines
if (ViewModelBase.IsInDesignModeStatic)
return;
If you're working with MVVM Light, or
if (System.ComponentModel.DesignerProperties.IsInDesignTool)
return;
which is pretty the same but without MVVM Light.
Also, i edited my answer there.
The only error I ever get is SIGABRT in main. This is getting incredibly frustrating as I have to guess what line caused the error and why.
This is a far cry from visual studio's informative error messages. It's basically like sending off an entire novel to an editor and the only notes you get back are: "There is a problem somewhere in your book. There may be many or just one and they are either gramatical or to do with spelling."
I just don't know how anyone can work like this. What am I doing wrong? Surely I'm missing something essential.
Write some NSLog() into your code and you'll see it in the console. It's a great help to narrow down a crash.
if you have encountered memory problems (aka – your app crashes for no apparent reason because you attempted to use an object that you deallocated to soon) setting NSZombieEnabled = YES can help you diagnose the problem.
Normally, when your app crashes in this way and you look at the log it tells you nothing (thanks Apple!). However, if you select your executable (under Executables in Xcode), hit the info button (round blue thing at the top), select arguments and put this in the bottom screen NSZombieEnabled = YES the log will give you more information.
Now, if your app crashes the log will have an indication of the object you attempted to access that has already been deallocated. Not forget to turn it off before you deploy it – you don’t want a bunch of nszombies running around your clients phones…
http://howtomakeiphoneapps.com/nszombie-and-xcode-oh-my/27/
I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.