winJs application are simple html Applications. Xaml c# provides an interface view where we can look at the design drag drop elements.
Is there a Way to Debug a winJS application like firebug or inspect element in Google Chrome. running every time in the simulator to check whether code is working or not has become a tedious Job. Any alternative please suggest.
Yes there's a kind of firebug as you mentioned But it is also known as Dom Explorer
The DOM Explorer is available only while in debug mode.
Make sure you have the script debugger selected, start debugging (F5), then go to Debug -> Windows -> DOM Explorer.
Here's a link to study the details
Dom Explorer from MSDN
Related
I need to examine the HTML of a popup, which works by injecting new HTML into the document. However, if you off-click the popup it automatically closes. Chrome's Developer Tools requires you to change focus to that window, which causes an off-click.
I have figured out a workaround that helps but is ultimately insufficient. You can right-click on the injected HTML in DevTool's Elements tab, which allows you to copy the injected HTML before the browser recognizes the off-click. This helps, but doesn't allow you to fully examine the injected HTML.
(The following solution is insufficent)
Is there a solution that allows me to fully examine the popup's HTML?
Are there ways to view live documentation for DOM commands on Browsers' devtools Console? The goal is that I want a faster way than opening a new tab, checking documentation and navigating back to the console.
Note for editing: I decided to attach this image to have the question more clarified.
What I am asking about is how to view "documentation of DOM" in console.
Unfortunately, there isn't a way to view the documentation of DOM APIs directly within the Chrome or Firefox DevTools.
There are ways to improve the workflow a bit, though. E.g. in Chrome you can install an extension called MDN-Dox, which adds a toolbar button for searching within the MDN documentation.
Alternatively, you can add MDN web docs to the installed search engines. In Chrome you do that by opening the settings > Search engine > Manage search engines > Add > entering the search engine info with "https://developer.mozilla.org/en-US/search?q=%s" as URL. See https://support.google.com/chrome/answer/95426?co=GENIE.Platform%3DDesktop&hl=en for more info.
For Firefox there's also an extension called MDN Search, which adds "mdn" as keyword to search for something on MDN web docs.
You can also add the search engine manually. One way to do that is to go to https://developer.mozilla.org/en-US/ > right-click the search field > Add a Keyword for this Search > entering the info. You may also read https://support.mozilla.org/en-US/kb/add-or-remove-search-engine-firefox.
I'm developing an office add-in using office-js (not using VSTO) and I want to access the DOM loaded in the task pane from the java script function-file used in the manifest extension points .
Yes, you can access the DOM loaded in the task pane from your JavaScript function-file. Think of it as if you have two browser windows or tabs and you want to communicate between them. Since the windows don't have access to a reference for one another, postMessage isn't a good solution. One option would be to use localStorage, which triggers an event on all same-domain pages when it changes.
Yes, you can access the DOM loaded in the task pane from your JavaScript function-file. Think of it as if you have two browser windows or tabs and you want to communicate between them. One option would be to use the postMessage() API to notify the task pane and include any information you'd like.
Edit: see my other answer: this solution isn't feasible since the window reference isn't available.
I've a legacy app that features a DND from a popup window to the main one.
It works fine in IE 8 but not in any of the newer versions of IE. The effect results in the drag ghost image being stuck in the source window and not going away after the drop had occurred.
Some debugging did in fact confirm that the 'mouseup' event does not get propagated back to the source window. What can be done to fix it? Many thanks!
ITs a bit hard to begin to answer your question without some code....
use the File>Properties menu to find out which IE security zones the two windows(domains) map too...IE uses a different security model to other browsers... drag/drop is probably not allowed between local web files (using file: protocol) and internet or intranet sites.
Have you used the Dev tool yet to debug it? If you are using showModalDialog (which normally disables context menus) you can right click on a link (a) or input element to display the context menu so you can display the debugger for showModal content page.
If possible include a link to your website or a mashup (jsfiddle) with your questions.
Problem - As the project was growing from some point on I cannot use anymore Worklight's Rich Page Editor. It looks as on the picture.
Configuration:
Eclipse Juno EE
Worklight 6.0.0.1
Project details - All pages are packed in the same HTML file. At the moment HTML file contains 6-7 pages in about 1100 lines. Compiling and all the rest works.
There should be no problems at all with that page size or number of views, so the appearance is likely tied to recent changes in the application logic itself. In your screenshot the editor has already finished loading the page into the embedded browser (otherwise you would still see a "Loading..." message in the editor's toolbar). The circular icon in the middle does not come from the editor itself but from something in that page or an associated script. In fact it looks a bit like a jQuery Mobile loading indicator to me.
One thing that may be happening here is something in the application's startup code has been added to call out to server-side logic (ex. a Worklight adapter call). Within the editor, the full preview server is not available so generally only the browser-side resources of an application will be functional. This allows you to use the editor for UI design work and then once you start hooking up to server-side features, previewing of the app would typically switch over to the Mobile Browser Simulator (Run As->Preview) or even native browser testing.
The best recommendation is to look for something in your app initialization process that's expecting data back and put in some temporary development-time mockups for such data. As an example, instead of making a service call to retrieve some JSON data just point to a test .json file in your project instead.
Could be related to this: Worklight Studio Rich Page Editor fails of WL.* call in page load
The short answer is that if you put just about any WL.* calls (even WL.Logger.*) in a page loading handler, it causes the Rich Page Editor to lock up.
If the problem is that you are calling backend resources that aren't available, then the normal timeouts and error handling in your code should keep the editor from locking up. You do have timeouts and error handling in your code, right? ;-)
If this problem can't be debugged easily, weinre (http://people.apache.org/~pmuellr/weinre/docs/latest/) works in the Rich Page Editor. You can see what is in the JavaScript console and if there are any exceptions thrown when it locks up.