I am using the A-Frame watcher plugin to create the scene, I was creating two entities for left and right tracked-controls-webxr. When I start my dev server from webpack I get this error:
core:a-node:error Failure loading node: TypeError: Cannot set properties of undefined (setting 'buttonStates')
at init (tracked-controls-webxr.js:25:64)
at initComponent (component.js:320:10)
at i.updateProperties (component.js:302:12)
at i.module.exports.Component (component.js:78:8)
at new i (component.js:662:15)
at HTMLElement.value (a-entity.js:332:19)
at HTMLElement.value (a-entity.js:495:12)
at HTMLElement.value (a-entity.js:463:14)
at a-entity.js:249:14
at a-node.js:127:21
Originally I had the two entities as childs to the camera cause that makes sense to me, but the page wouldn't load, I moved them out the page loads but I still get the errors.
afaik the tracked-controls are supposed to set up thetracked-controls-webxr:
tracked-controls sets two components that handles different Web API versions for VR:
tracked-controls-webvr
tracked-controls-webxr
You're getting an error, because tracked-controls-webxr are trying to access tracked-controls and fail - hence Cannot set properties of undefined (setting 'buttonStates').
Try using tracked-controls, or mimic their setup
Related
I'm getting Uncaught TypeError: container is undefined thrown in a loop when I create a custom geometry.
Geometries are created using code from https://forge.autodesk.com/blog/custom-models-forge-viewer
I'm using the AggregatedView. The error does not occur when I instantiate a GuiViewer3D directly.
Uncaught TypeError: container is undefined
getFragmentConsolidationType ConsolidationIterator.js:398
updateRenderProxy ConsolidationIterator.js:416
updateRenderProxy RenderModel.js:973
updateSelectionProxies Viewer3DImpl.js:2145
renderOverlays Viewer3DImpl.js:2152
cmdRenderOverlays Viewer3DImpl.js:1330
executeCommandList Viewer3DImpl.js:913
tick Viewer3DImpl.js:1908
animloop Viewer3DImpl.js:1939
Is this a bug in Autodesk Forge? Using version 7.80
Selecting a custom geometry with the AggregatedView.
Expected the object to be selected.
Instead an error is thrown continuously.
The engineering team confirmed that this is a problem with the SceneBuilder extension not being compatible with "model consolidation" - a process where multiple meshes are merged into a single GPU buffer to improve rendering performance. The AggregatedView class consolidates models automatically, which is why you're running into this issue.
While we are not planning to add consolidation support to models generated by the SceneBuilder extension, we will update the extension and make sure that this combination is handled gracefully. In the meantime, if you need to use SceneBuilder models in an AggregatedView app, please unconsolidate your custom models using model.unconsolidate().
I am in the progress of upgrading a legacy application from PrimeFaces 6.2 to 11.0.0 (which is the newest available with maven - https://mvnrepository.com/artifact/org.primefaces/primefaces). I have had to make a number of changes, including adding Object as the parameter for RowEditEvent and TreeNode objects (which are now generic) and changing instantiations of DefaultStreamedContent to use .builder(). Now, I am facing the following error whenever I try to run the application and navigate to certain pages:
"javax.faces.FacesException: Unable to automatically determine the lazy attribute. Either define the lazy attribute on the component or make sure the value attribute doesn't resolve to null."
It looks like an exception is being thrown rather than a warning as is noted in the conversation here: https://github.com/primefaces/primefaces/issues/8436. It also looks like it was fixed, but for version 12 (which is not on the maven central repository).
I am wondering what my options are, or what could be done about this. Should I go back to an older version?
As a workaround you could create an application factory which sets the lazy attribute to false.
See: https://primefaces.github.io/primefaces/11_0_0/#/core/globalattributes
Is it a lazy DataTable which uses LazyDataModel? If yes, just set lazy=true, otherwhise set lazy=false
Recently iam trying to update my angular project from 8 to 9. While updating i also updated wijmo from wijmo/wijmo to #grapecity/wijmo package as it supports IVY.
But after the completing the upgradation, i can able to compile the application but i am getting the following error at run time
global-error-handler.service.ts:43 Error: Uncaught (in promise): TypeError: (0 , t[n]) is not a function
TypeError: (0 , t[n]) is not a function
at backend.js:61
at Reflect.<anonymous> (backend.js:61)
at push../node_modules/#grapecity/wijmo.angular2.grid.detail/__ivy_ngcc__/index.js.__decorate (index.js:28)
at index.js:53
at Object../node_modules/#grapecity/wijmo.angular2.grid.detail/__ivy_ngcc__/index.js (index.js:53)
at __webpack_require__ (bootstrap:84)
I'd like to get some more info about this error. The quick thing to check is property initialization order. In Ivy, the properties are interpreted as they are specified in markup (previously wijmo controlled how they were interpreted). So you can break components by setting certain properties before others.
For example, if I tried to set the selectedIndex on a combobox BEFORE I set the data source, then the app would break at runtime because there are no items in the list to select yet.
More info here: https://www.grapecity.com/wijmo/docs/GettingStarted/Angular-Components#property-initialization-order-in-angular-9-ivy-and-higher
The next thing to check is component decorators (if you are inheriting our components). There are some breaking changes in decorators in Ivy.
For example, you might need to add {descendants: true} to ContentChildren queries.
Or you might need to add an #Injectable decorator to your class.
You can read more about breaking changes in Ivy and how to fix them here: https://angular.io/guide/ivy-compatibility-examples
But please feel free to contact us to work directly: wijmoexperts#grapecity.com
I'm experiencing a discrepancy between the first compilation of a Grails app and the compilation that happens when a file changes while the app is running.
Background:
My app creates some spring beans from Spring LDAP (docs) using conf/spring/resources.groovy.
I have an LdapUser.groovy class in src/groovy (I'm using it similarly to a domain class, except it isn't in grails-app/domain as it doesn't map to a database table).
In BootStrap.groovy I register a JSON marshaller for LdapUser (using JSON.registerObjectMarshaller).
I have a controller with an index method that responds a list of LdapUser objects. This renders correctly in JSON (according to the marshaller).
With that background, here are the pieces of the problem:
When the show method, which responds a single LdapUser, gets called, I get an exception that LdapUser cannot be converted to grails.converters.JSON. (fair enough)
But, if I save the LdapUser.groovy file, thus invoking a recompile on the file while the app is running, the JSON marshaller suddenly works fine.
Before saving the LdapUser.groovy, my controller has a to an LdapUserRepo (a class instantiated via an #EnableLdapRepositories annotation on the controller), but this reference becomes null after I save LdapUser.groovy. I'm not sure how this relates to the problem, as I was also able to reproduce the problem in a controller lacking an injected LdapUserRepo (but with the annotated controllers still in the app).
I also at one point was setting an asType method on the LdapUser class, which was called as expected before the save-invoked recompile. After the recompile, however, my asType method was no longer called and the JSON marshaller was taking over. ( I was doing exception-worthy things in the asType that were throwing before recompile and not throwing after... )
My understanding of the problem is therefore:
Somehow the asType method of the LdapUser.groovy class is not being automatically generated on first compile when running the app, but is being generated on subsequent compiles.
The LdapUser class is tied to the LdapUserRepo in more ways than merely being a type the Repo uses, and the recompile is not reflecting that connection correctly.
Methods rendering lists of objects are somehow unaffected by the asType method. This leads me to believe that the JSON marshaller gets called directly on list elements (instead of via asType) when the list asType has been called (whether or not the "as" operation is implicit...).
My question then is:
what is the Grails compiler doing differently on run-app vs on compile while app is running that could be causing this behavior?
how can I restructure things to ensure it works properly out of the box?
If I need to RTFM, what would be the FM section? (My google-fu is sadly quite weak).
Note: this question is vaguely similar, but doesn't have any meaningfulness to the answer:
Grails: Defining a JSON custom marshaller as static method in domain
I'm using MVVM Light and everything is fine except when launching my Windows Phone 8.1 WinRT app as a Share Target.
When I try to assign MainViewModel viewModel = ServiceLocator.Current.GetInstance<MainViewModel>(); I get an exception for ServiceLocator.Current.
Exception Message: ServiceLocationProvider must be set.
Do I need to do something extra in App.xaml.cs OnShareTargetActivated event to insure the Locator is running?
UPDATE:
A ShareTarget page needs to be thought of as a small extension of your app. It seems that not all of the app's resources are loaded (including app-wide resources in App.xaml). So I just created a new instance of MainViewModel in the share page's constructor, loaded only the things I need for the share to complete, save the information and call ShareOperation.ReportCompleted. This returns the user back to the app that is sharing.
I still haven't found a good solution for getting other resources in my ViewModel, but this works for now.
This indicates that the following line has not been executed:
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
This line will instruct the ServiceLocator class to use the SimpleIoc.Default instance as its ServiceLocator.Current. When you run your app as a Share target, the initialization is slightly different and probably the ViewModelLocator doesn't get initialized. You need to find a good location to perform the initialization before you use the ServiceLocator.
Cheers
Laurent