2010-06-09 00:52:24 +08:00
|
|
|
//===-- ValueObjectChild.cpp ------------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "lldb/Core/ValueObjectChild.h"
|
|
|
|
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/ValueObjectList.h"
|
|
|
|
|
2010-07-22 06:12:05 +08:00
|
|
|
#include "lldb/Symbol/ClangASTType.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
|
|
|
#include "lldb/Symbol/Type.h"
|
|
|
|
#include "lldb/Symbol/Variable.h"
|
|
|
|
|
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
ValueObjectChild::ValueObjectChild
|
|
|
|
(
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject &parent,
|
2010-06-09 00:52:24 +08:00
|
|
|
clang::ASTContext *clang_ast,
|
|
|
|
void *clang_type,
|
|
|
|
const ConstString &name,
|
|
|
|
uint32_t byte_size,
|
|
|
|
int32_t byte_offset,
|
|
|
|
uint32_t bitfield_bit_size,
|
2010-10-15 06:52:14 +08:00
|
|
|
uint32_t bitfield_bit_offset,
|
2011-01-21 09:59:00 +08:00
|
|
|
bool is_base_class,
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
bool is_deref_of_parent,
|
|
|
|
AddressType child_ptr_or_ref_addr_type
|
2010-06-09 00:52:24 +08:00
|
|
|
) :
|
2010-10-15 06:52:14 +08:00
|
|
|
ValueObject (parent),
|
2010-06-09 00:52:24 +08:00
|
|
|
m_clang_ast (clang_ast),
|
|
|
|
m_clang_type (clang_type),
|
|
|
|
m_byte_size (byte_size),
|
|
|
|
m_byte_offset (byte_offset),
|
|
|
|
m_bitfield_bit_size (bitfield_bit_size),
|
2010-10-15 06:52:14 +08:00
|
|
|
m_bitfield_bit_offset (bitfield_bit_offset),
|
2011-01-21 09:59:00 +08:00
|
|
|
m_is_base_class (is_base_class),
|
|
|
|
m_is_deref_of_parent (is_deref_of_parent)
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
|
|
|
m_name = name;
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
SetAddressTypeOfChildren(child_ptr_or_ref_addr_type);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ValueObjectChild::~ValueObjectChild()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
lldb::ValueType
|
|
|
|
ValueObjectChild::GetValueType() const
|
|
|
|
{
|
|
|
|
return m_parent->GetValueType();
|
|
|
|
}
|
|
|
|
|
2013-01-26 02:06:21 +08:00
|
|
|
size_t
|
2010-06-09 00:52:24 +08:00
|
|
|
ValueObjectChild::CalculateNumChildren()
|
|
|
|
{
|
2012-02-23 07:57:45 +08:00
|
|
|
return ClangASTContext::GetNumChildren (GetClangAST (), GetClangType(), true);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ConstString
|
|
|
|
ValueObjectChild::GetTypeName()
|
|
|
|
{
|
|
|
|
if (m_type_name.IsEmpty())
|
|
|
|
{
|
2012-03-27 07:03:23 +08:00
|
|
|
m_type_name = ClangASTType::GetConstTypeName (GetClangAST(), GetClangType());
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_type_name)
|
|
|
|
{
|
|
|
|
if (m_bitfield_bit_size > 0)
|
|
|
|
{
|
|
|
|
const char *clang_type_name = m_type_name.AsCString();
|
|
|
|
if (clang_type_name)
|
|
|
|
{
|
2010-07-10 04:39:50 +08:00
|
|
|
std::vector<char> bitfield_type_name (strlen(clang_type_name) + 32, 0);
|
2010-07-21 06:52:08 +08:00
|
|
|
::snprintf (&bitfield_type_name.front(), bitfield_type_name.size(), "%s:%u", clang_type_name, m_bitfield_bit_size);
|
|
|
|
m_type_name.SetCString(&bitfield_type_name.front());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return m_type_name;
|
|
|
|
}
|
|
|
|
|
2012-03-27 07:03:23 +08:00
|
|
|
ConstString
|
|
|
|
ValueObjectChild::GetQualifiedTypeName()
|
|
|
|
{
|
|
|
|
ConstString qualified_name = ClangASTType::GetConstQualifiedTypeName (GetClangAST(), GetClangType());
|
|
|
|
if (qualified_name)
|
|
|
|
{
|
|
|
|
if (m_bitfield_bit_size > 0)
|
|
|
|
{
|
|
|
|
const char *clang_type_name = qualified_name.AsCString();
|
|
|
|
if (clang_type_name)
|
|
|
|
{
|
|
|
|
std::vector<char> bitfield_type_name (strlen(clang_type_name) + 32, 0);
|
|
|
|
::snprintf (&bitfield_type_name.front(), bitfield_type_name.size(), "%s:%u", clang_type_name, m_bitfield_bit_size);
|
|
|
|
qualified_name.SetCString(&bitfield_type_name.front());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return qualified_name;
|
|
|
|
}
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool
|
|
|
|
ValueObjectChild::UpdateValue ()
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
|
|
|
m_error.Clear();
|
|
|
|
SetValueIsValid (false);
|
|
|
|
ValueObject* parent = m_parent;
|
|
|
|
if (parent)
|
|
|
|
{
|
2011-08-03 01:27:39 +08:00
|
|
|
if (parent->UpdateValueIfNeeded(false))
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
2012-02-23 07:57:45 +08:00
|
|
|
m_value.SetContext(Value::eContextTypeClangType, GetClangType());
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
// Copy the parent scalar value and the scalar value type
|
|
|
|
m_value.GetScalar() = parent->GetValue().GetScalar();
|
|
|
|
Value::ValueType value_type = parent->GetValue().GetValueType();
|
|
|
|
m_value.SetValueType (value_type);
|
|
|
|
|
2010-09-29 09:12:09 +08:00
|
|
|
if (ClangASTContext::IsPointerOrReferenceType (parent->GetClangType()))
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
lldb::addr_t addr = parent->GetPointerValue ();
|
2011-08-16 08:44:29 +08:00
|
|
|
m_value.GetScalar() = addr;
|
2010-11-02 09:50:16 +08:00
|
|
|
|
|
|
|
if (addr == LLDB_INVALID_ADDRESS)
|
|
|
|
{
|
|
|
|
m_error.SetErrorString ("parent address is invalid.");
|
|
|
|
}
|
|
|
|
else if (addr == 0)
|
|
|
|
{
|
|
|
|
m_error.SetErrorString ("parent is NULL");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2010-11-03 05:21:20 +08:00
|
|
|
m_value.GetScalar() += m_byte_offset;
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
AddressType addr_type = parent->GetAddressTypeOfChildren();
|
|
|
|
|
|
|
|
switch (addr_type)
|
|
|
|
{
|
|
|
|
case eAddressTypeFile:
|
2012-02-17 15:49:44 +08:00
|
|
|
{
|
|
|
|
lldb::ProcessSP process_sp (GetProcessSP());
|
|
|
|
if (process_sp && process_sp->IsAlive() == true)
|
|
|
|
m_value.SetValueType (Value::eValueTypeLoadAddress);
|
|
|
|
else
|
|
|
|
m_value.SetValueType(Value::eValueTypeFileAddress);
|
|
|
|
}
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
break;
|
|
|
|
case eAddressTypeLoad:
|
|
|
|
m_value.SetValueType (Value::eValueTypeLoadAddress);
|
|
|
|
break;
|
|
|
|
case eAddressTypeHost:
|
|
|
|
m_value.SetValueType(Value::eValueTypeHostAddress);
|
|
|
|
break;
|
|
|
|
case eAddressTypeInvalid:
|
|
|
|
// TODO: does this make sense?
|
|
|
|
m_value.SetValueType(Value::eValueTypeScalar);
|
|
|
|
break;
|
|
|
|
}
|
2010-11-02 09:50:16 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
switch (value_type)
|
|
|
|
{
|
|
|
|
case Value::eValueTypeLoadAddress:
|
|
|
|
case Value::eValueTypeFileAddress:
|
|
|
|
case Value::eValueTypeHostAddress:
|
|
|
|
{
|
|
|
|
lldb::addr_t addr = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
|
2010-11-02 09:50:16 +08:00
|
|
|
if (addr == LLDB_INVALID_ADDRESS)
|
|
|
|
{
|
|
|
|
m_error.SetErrorString ("parent address is invalid.");
|
|
|
|
}
|
|
|
|
else if (addr == 0)
|
|
|
|
{
|
|
|
|
m_error.SetErrorString ("parent is NULL");
|
|
|
|
}
|
|
|
|
else
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
2010-11-02 09:50:16 +08:00
|
|
|
// Set this object's scalar value to the address of its
|
2011-08-13 07:34:31 +08:00
|
|
|
// value by adding its byte offset to the parent address
|
2010-11-02 09:50:16 +08:00
|
|
|
m_value.GetScalar() += GetByteOffset();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Value::eValueTypeScalar:
|
|
|
|
// TODO: What if this is a register value? Do we try and
|
|
|
|
// extract the child value from within the parent data?
|
|
|
|
// Probably...
|
|
|
|
default:
|
2011-10-26 08:56:27 +08:00
|
|
|
m_error.SetErrorString ("parent has invalid value.");
|
2010-06-09 00:52:24 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (m_error.Success())
|
|
|
|
{
|
2012-02-17 15:49:44 +08:00
|
|
|
ExecutionContext exe_ctx (GetExecutionContextRef().Lock());
|
2012-02-24 09:59:29 +08:00
|
|
|
m_error = m_value.GetValueAsData (&exe_ctx, GetClangAST (), m_data, 0, GetModule().get());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-10-26 08:56:27 +08:00
|
|
|
m_error.SetErrorStringWithFormat("parent failed to evaluate: %s", parent->GetError().AsCString());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
m_error.SetErrorString("ValueObjectChild has a NULL parent ValueObject.");
|
|
|
|
}
|
2011-03-31 08:19:25 +08:00
|
|
|
|
|
|
|
return m_error.Success();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObjectChild::IsInScope ()
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
2011-03-31 08:19:25 +08:00
|
|
|
return m_parent->IsInScope ();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|