Within my Pure AS3 app (using IntelliJ) I'm getting the following warning:
"Member from unopened namespace" associated with the instance of the model.
The initial instantiation of the Model is fine (singleton) but each reference to it within the class that it's instantiated after the constructor are throwing the above warning.
The model it's self appear fine as is instantiated without issue from multiple other view classes.
Has anyone come across this before? Interesting that neither SO or Google verbatim throws up any results.
as ever, all suggestions and help appreciated!
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().
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
Looking for help writing an interface that has a property (or function) that returns an object typed as a "Form" (e.g. Access.Form as the return type).
Problem description:
The following simple example code returns a "User-defined type not defined" error if I attempt to compile the project.
I_TestInterface:
Public Property Get MyForm() as Form
End Property
cls_TestClass:
Implements I_TestInterface
Public Property Get I_TestInterface_MyForm() as Form
End Property
This is the only code/objects in a otherwise blank Access-2016 database and asking VBA to 'compile' produces a "User-defined type not defined" error. No lines are highlighted, it simply won't compile. Same occurs if replace 'Form' by "Access.Form"
My usecase is writing classes that wrap/hold a reference to a form internally - sometimes it is easiest to provide a reference to the underlying form so that consuming code can get at form properties without coding them all into the wrapper class.
Steps taken:
Lots of searches on 'user-defined type not defined' errors, in almost all cases this is due to a missing reference. Does not seem applicable since can create a standard module and happy to compile if write a function with a Form return type there. (*)
There was one previous SO thread on similar 'ambiguous' 'user-defined type not defined' error but I can't find it again and it wasn't specific to the 'Form' type in MS-Access
Have a clumsy workaround of providing property that returns an Object type that consuming code just has to cast to a Form (e.g. public property get MyFormAsObjectThatCanBeCastToForm() as Object).
(*). Possible clue? - if I just change the return types to object, the code still won't compile. I need to exit and use the 'de-compile' start up switch when relaunch Access. Then the above code with Object used as a return type is happily compiled.
Question / request:
Before I start re-installing Office, can others reproduce this?
Has anyone experienced this before? Developed a solution?
Thanks
PAHTDC
On a large inherited project I am getting the error below. So far I haven't even found where the error is being triggered. I've searched on various terms (I'm using Flash Builder) and find no references to registerClassAlias and only one reference to DataItem (below).
I am assuming that _ShoppingCart_FlexInit is some internal Flex call.
Does anyone understand this error: what is causing it and how to resolve it? The suggestion to "define spark.utils.DataItem in the top-level application" isn't clear to me. Is that an #import?
warning: The class spark.utils.DataItem has been used in a call to
net.registerClassAlias() in _ShoppingCart_FlexInit. This will cause
modules:ShoppingCart to be leaked. To resolve the leak, define
spark.utils.DataItem in the top-level application.
DataItem reference:
<s:typicalItem>
<s:DataItem eventID = "eEventIDNum"
eventName="eEventName"
eventLocation="local"
eventText1="I am a very long text description"
eventLinkName="Summary"/>
</s:typicalItem>
Some code is auto-generated by the mxmlc compiler, so you could try to use the compiler option keep-generated-actionscript=true to find the registerClassAlias call.
To follow the suggestion you could just define a DataItem dummy variable in the top-level application.
I'm following hemanth sharma's excellent tutorial series on the starling framework. I more or less copied his code and made a few changes towards the game I have in mind. The code is 80% the same he used in his project. Nevertheless I'm encountering a strange error: "error 1067" it complains about the "implicit coercion" of supposedly unrelated types.
I browsed previous questions and discovered this one:
1067: Implicit coercion of a value of type Class to an unrelated type flash.display:DisplayObject
The error message I'm receiving is basically the same but unfortunately the solution does not apply to my problem. Moreover I'm getting this error in many interesting different flavours.
I've got a custom event class called NavigationEvent that expands
starling.events.Event. When the used tries to switch between the
game screens this event is dispatched. Here's some code:
import starling.events.Event;
public class NavigationEvent extends Event
it is dispatched like this:
this.dispatchEvent(new NavigationEvent(NavigationEvent.CHANGE_SCREEN,{id:"play"},true));
the error message says:
Error 1067: Implicit coercion of a value of type events:NavigationEvent to an unrelated type starling.events:Event
The code worked fine when I first wrote it but now, after I've
changed another part of the program it is broken. I can't explain
it. I extended NavigationEvent from starling.events.Event so the
types are definitely not unrelated. I even ran the program like
this. Admittedly the routine to switch between screens was no yet
implemented but the event was fired without problems.
In order to let the user trigger this event I added a button to the
screen. It is starlings standard starling.display.Button;. The
button is a member variable of my screen class
private var playBtn:Button;
However this line results in an error:
playBtn=new Button(Assets.getAtlas().getTexture("play"));
This time the error is even more outrageous:
Error 1067: Implicit coercion of a value of type starling.textures:Texture to an unrelated type
starling.textures:Texture
What can I do about this ?
Sometimes, when you have two Flash Pro projects open in Flash Builder, and both projects have the same directory in the code path, you can get the error you experienced. This happens when you have the file open in one of the projects, but you're compiling and running both of the projects (especially if you're debugging and have set break-points).
What I think is happening is that FB compiles in the same file as if it were a different file, because it is "reaching over" from the one where the file is open and compiling it into the one where it's just referenced, but not open. The file that is open extends the base Class in its project, not the base Class in the project with the fla/xfl in it. Though we know that it's actually one file, FB apparently can't figure that out. I think you got off really lightly, because I've had to take truly heroic measures in the past to resolve this.
You could potentially resolve this by moving your shared code out into a library project, which I think is the scenario the engineers probably thought everyone would do. I think that they couldn't (or at least didn't) foresee the intersection of historical Flash development practices and the quirks of working with FB and FP together that would cause this particular bug to emerge.