It's an info, not an error, so Debug.bugReport didn't work. I've pasted
an example backtrace below. I think the issue may be that we are
dynamically adding children to the prototype of a class like:
lz[this.gridRowClassName].children[i+len] = {
attrs: { name: cname, header: header }, name:
'gridcell' + cname
}
We do this so we can dynamically add subviews to a view that will be
replicator over based on a CSS attribute.
Will we need to find a different way to do this in 4.2?
lzx> Debug.inspect(«Backtrace(42)| Debug.deprecated <- makeC...»)
«Backtrace(42)#155| Debug.deprecated <- makeChild <- makeSomeViews <-
createImmediate <- cre...» {
length: 42
0: LzLoadQueue.XMLOnDataHandler @lfc/kernel/swf/LzLoadQueue.as#119
1: queuedCopyFlashXML @lfc/kernel/swf/LzLoader.lzs#511
2: queuedCopyFlashXML_internal @lfc/kernel/swf/LzLoader.lzs#635
3: returnData @lfc/kernel/swf/LzLoader.lzs#230
4: sendEvent @lfc/events/LaszloEvents.lzs#525
5: LzHTTPLoader.prototype._loadSuccessHandler
@lfc/kernel/swf/LzHTTPLoader.as#37
6: loadSuccess @lfc/data/LzHTTPDataProvider.lzs#245
7: loadResponse @lfc/data/LzHTTPDataProvider.lzs#324
8: sendEvent @lfc/events/LaszloEvents.lzs#525
9: handleResponse @../../framework/data/webtopdataprovider.lzx#239
10: setResponse @../../framework/data/webtopdatarequest.lzx#111
11: sendEvent @lfc/events/LaszloEvents.lzs#525
12: _handleResponse @../../framework/data/webtopdatahandler.lzx#123
13: handleResponse @../../applib/mail/handlers/RequestQueue.lzx#112
14: handleResponse
@../../applib/mail/handlers/FreshMessageHeadersRequest.lzx#40
15: _setFreshMessageHeaders
@../../applib/mail/handlers/FreshMessageHeadersRequest.lzx#125
16: _setHeaderArray @../../applib/mail/mailfolder.lzx#407
17: setChildNodes @lfc/data/LzDataElement.lzs#330
18: handleDocumentChange @lfc/data/LzDataElement.lzs#499
19: sendEvent @lfc/events/LaszloEvents.lzs#525
20: __LZcheckChange @lfc/data/LzDatapath.lzs#574
21: sendEvent @lfc/events/LaszloEvents.lzs#525
22: __LZcheckChange @lfc/data/LzDatapath.lzs#-1
23: __LZcheckChange @lfc/data/LzDatapointer.lzs#1374
24: runXPath @lfc/data/LzDatapointer.lzs#414
25: __LZHandleMultiNodes @lfc/data/LzDatapath.lzs#311
26: LzLazyReplicationManager @lfc/compiler/Class.lzs#297
27: $lzsc$initialize @lfc/data/LzLazyReplicationManager.lzs#-1
28: $lzsc$initialize @lfc/data/LzReplicationManager.lzs#-1
29: $lzsc$initialize @lfc/data/LzDatapath.lzs#-1
30: $lzsc$initialize @lfc/data/LzDatapointer.lzs#-1
31: $lzsc$initialize @lfc/core/LzNode.lzs#290
32: construct @lfc/data/LzLazyReplicationManager.lzs#142
33: getNewClone @lfc/data/LzReplicationManager.lzs#673
34: lz.mailmessagegridrow @lfc/compiler/Class.lzs#297
35: $lzsc$initialize @lfc/views/LaszloView.lzs#-1
36: $lzsc$initialize @lfc/core/LzNode.lzs#318
37: createChildren @lfc/core/LzNode.lzs#1069
38: createImmediate @lfc/services/LzInstantiator.lzs#280
39: makeSomeViews @lfc/services/LzInstantiator.lzs#242
40: makeChild @lfc/core/LzNode.lzs#1195
41: Debug.deprecated @lfc/debugger/LzMessage.lzs#556
}«Backtrace(42)#155| Debug.deprecated <- makeChild <- makeSomeViews <-
createImmediate <- cre...»
lzx>
On Mon, Dec 15, 2008 at 9:02 PM , P T Withington wrote:
The easiest way to figure out is to turn on backtrace, click on the
error (to inspect it), then type `Debug.bugReport()` in the debugger
eval window. If you can send the output of the report, we can track
this down. Thanks!
On 2008-12-15, at 19:46EST, Lorien Henry-Wilkins wrote:
I'm porting some code from pagan-deities to OL 4.1 and I am seeing a
bunch of the following error:
INFO: makeChild.name is deprecated. Use makeChild.class instead
I can't find any place in my code where I am actually calling
makeChild, so I think this is being called internally by the
platform itself. Any idea what's causing this?
Thanks!
Lorien
