I am running into the DOM exception (title) and have no clue how to resolve it. This is the same exception from this other stackoverflow post. As per the solution in the other post, I tried moving the createElement call into the connectedCallback hook, but I am still seeing the exception.
Simplest code that produces the exception is:
connectedCallback() {
document.createElement('toggle-switch');
}
where toggle-switch is a custom element I defined earlier. Any clues as to why this is still happening / how I can get this resolved will be greatly appreciated!
Oops. Totally my mistake. I did have some DOM manipulation in the constructor of toggle-switch. I accidentally added .innerHTML on the element instead of it's shadowroot.
Related
In my code, I have this workflow:
When user wants to see some things, add Sprites using 'DataVizCore.addViewables()'
Use 'viewer.addEventListener(DataVizCore.MOUSE_CLICK, onDotClick)' to show info bubble
When user wants to show other things, call 'DataVizCore.removeAllViewables()' to clear Sprites
Repeat from step 1
This sequence works OK except in one situation.
If a sprite was selected (by clicking on it) before removeAllViewables() is called, I don't get MOUSE_CLICK event for newly added Sprites. In browser console, I see following error is thrown.
CustomViewables.js:318 Uncaught TypeError: Cannot read property 'style' of undefined at ViewableData.getViewableUV (developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/DataVisualization/DataVisualization.js:454)
As a workaround, I added 'event.hasStopped = true' to click event handler to prevent Sprite getting selected internally. That seems to work.
This seems like a bug in DataVizExtension to me. Or, my workflow is wrong?
Thanks
Bandu
Bandu. Thanks for the detailed steps to reproduce this issue. I tried with v7.46.0 version of the DataVisualization.js (latest as of my message) but was not seeing the same issue. I'd be curious if you are using this same version of the Forge Viewer (you can figure that out by looking at the viewer3D.js fetched under the Network tab of Chrome DevTools).
Setting event.hasStopped = true works because it internally avoided the code path calls into getViewableUV that threw the exception, but the flag is meant for other use cases (e.g. overriding default sprite selection behavior).
In any case, I've just tweaked our internal code to make use-cases like yours more robust. The changes will be released with the upcoming v7.47.0. Thank you for your feedback 🙂
I have recently discovered that my ScrollPane class code hinting is completely missing. Nevertheless, some basic functions such as setStyle and source can be found in item list, and are still working. The problem starts when trying to customize the ScrollPane with such functions as horizontalScrollPolicy, at which point the compiler returns an error such as 'call to a possibly undefined method'. Help >_<
I have figured this out after some time. It appears that the code snippet that is being used throughout various sources does not work. Instead I use myScrollPane.horizontalScrollPolicy = "on";
I'm a AS3 developer but I'm not sure how can I trace this kind of messages in firebug as an info messsages.
I know that for an error I just need to inherit for an error but I'm not sure how can I trace this kind of messages.
This code:
trace("Hola")
will show "Hola" in Firebug, but I want the fancy Info icon at the beginning also the background of the line is blue.
Thanks for your help.
you can try https://addons.mozilla.org/en-US/firefox/addon/flashbug/
years ago I've used http://www.sephiroth.it/firefox/flashtracer/ not sure if anyone uses it still.
The trick is to use Debug version of flash player
In the case where you don't want to install the Flash Debug player (performance?), rather than using trace, route it to a Debug method that traces and logs to the console:
import flash.external.ExternalInterface;
var debug:Boolean = true;
function log(msg:String):void {
if ( debug ) {
trace(msg);
ExternalInterface.call('console.log',msg);
}
}
log('Hello World');
You should be able to throw that in a frame. If you're using class definitions, you'll have to interpret that code block as snippets.
Also note that in a browser that doesn't have console.log (like IE7) this will throw an error, so maybe you should test for console.log first and store the result in a global.
Notice the debug variable. When you want to turn debug logging off, just set debug to false. This is an overly simplified idea, but provides the basic concept.
Another way enhance this concept is to include a debug "window" if you will... really just a scrollable text box on top of everything else. This is helpful when dealing with devices that do not support logging, debug versions of flash or are just difficult to debug, e.g. mobile and AIR.
I'm going to try to describe the issue as clear as possible:
The document class (Main.as) loads a SWF file and places it on the stage.
The SWF already has a child instance on its stage with a defined class of its own (Child.as).
If I import the SWF child's class (Child.as) in the document class (Main.as) with the sole purpose of accessing a static property, then the child's instance on the stage goes crazy (i.e. runs in a loop) without throwing any error or warning at compilation or run-time.
Note: The import of the child class alone doesn't do anything (probably because it is discarded for not being used), but actually mentioning the class anywhere in the public document class triggers the weird behavior of the child instance on the stage.
Just to make myself clear, the child instance works just fine, without any problems as long as I do not use its class in any way in the document class.
My question: Do you have any idea what would make the child instance on the stage behave as if an error occurred even if there's no error or warning messages? Or a possible workaround?
Try not importing the class and getting it through (once the swf is loaded)
myLoader.contentLoaderInfo.applicationDomain.getDefinition("Child").STATIC_PROPERTY
I agree, it is not a very nice answer but a work-around. I'd be glad if someone found a real answer to this question.
I added exception handling for the pages, now I want to do it for the panels.
I found http://apache-wicket.1842946.n4.nabble.com/ExceptionHandling-in-Panels-td3311271.html and http://apache-wicket.1842946.n4.nabble.com/newbie-best-practice-for-not-rendering-component-td1871632.html, but the answers are not satisfying as I realized that there is no built-in support in Wicket for exception handling for panels as there is for pages. And choosing between a fragment with the panel markup and an error fragment is not the robust support I'm looking for.
Since most of the exceptions in my web app can rise in the section of the logic where the components are added and models are used, I thought of placing that part of the logic in the constructor, so when an error occurs, I could catch it and then show the error panel I want. Something like:
try{
add(new MyPanel(panelId, model));
}catch (Exception e){
add(new ErrorPanel(panelId, e));
...
}
But I get warnings when resolving properties in the constructor by using the getString() method.
So, my questions are:
- Is there any online example where this has been solved? Or any idea about that?
- If using the getString() in the constructor throws that type of warnings, what would the best practice then?
- I I can't place that logic in the constructor, because you are not supposed to resolve properties there, what options are there besides the one I mentioned?
As with most logic in panels, the constructor isn't the best place. During construction-time, the panel (or any other component) isn't yet attaced to a page. That leaves the component in a fragile state where some components don't even have any markup.
More complex logic should be placed outside of the constructor. Wicket 1.5 offers an onInitialRender method that can be overridden where one can safely put any logic. In Wicket 1.4.x there is an easy way to simulate that hook by implementing onBeforeRender as
#Override
protected void onBeforeRender() {
if (!hasBeenRendered()) {
onInitialRender();
}
super.onBeforeRender();
}
thus creating an onInitialRender-hook that's only executed once and IMO the best place to put any logic that's not dependent on other hooks.
Edit: In your case the warning indicated that the intended chain of Resource-Lookups can't be used since the is no hierarchy of components that can be used as fallbacks if the resource isn't found at the current component or final application level.
Note: Wicket 1.5 does not offer an onInitialRender method (it was probably added and removed during some pre-releases). Instead, the onInitialize method should be used for adding child components to the panel (or any other component).
see https://cwiki.apache.org/WICKET/migration-to-wicket-15.html#MigrationtoWicket1.5-ComponentInitializationComponent%2523onInitialize for details.