本文整理汇总了C++中LIB_COMPONENT::GetFields方法的典型用法代码示例。如果您正苦于以下问题：C++ LIB_COMPONENT::GetFields方法的具体用法？C++ LIB_COMPONENT::GetFields怎么用？C++ LIB_COMPONENT::GetFields使用的例子？那么, 这里精选的方法代码示例或许可以为您提供帮助。您也可以进一步了解该方法所在类LIB_COMPONENT的用法示例。
在下文中一共展示了LIB_COMPONENT::GetFields方法的1个代码示例，这些例子默认根据受欢迎程度排序。您可以为喜欢或者感觉有用的代码点赞，您的评价将有助于系统推荐出更棒的C++代码示例。
示例1: initBuffers
void DIALOG_EDIT_LIBENTRY_FIELDS_IN_LIB::initBuffers()
{
LIB_FIELDS cmpFields;
m_libEntry->GetFields( cmpFields );
#if defined(DEBUG)
for( unsigned i=0; i<cmpFields.size(); ++i )
{
printf( "cmpFields[%d].name:%s\n", i, TO_UTF8( cmpFields[i].GetName() ) );
}
#endif
/* We have 3 component related field lists to be aware of: 1) UI
presentation (m_FieldsBuf), 2) fields in component ram copy, and 3)
fields recorded with component on disk. m_FieldsBuf is the list of UI
fields, and this list is not the same as the list which is in the
component, which is also not the same as the list on disk. All 3 lists
are potentially different. In the UI we choose to preserve the order of
the first MANDATORY_FIELDS which are sometimes called fixed fields. Then
we append the template fieldnames in the exact same order as the
template fieldname editor shows them. Then we append any user defined
fieldnames which came from the component, and user can modify it during
editing, but cannot delete or move a fixed field.
*/
m_FieldsBuf.clear();
/* When this code was written, all field constructors ensured that the
MANDATORY_FIELDS are all present within a component (in ram only). So we can
knowingly copy them over in the normal order. Copy only the fixed fields
at first. Please do not break the field constructors.
*/
// fixed fields:
for( int i=0; i<MANDATORY_FIELDS; ++i )
{
DBG( printf( "add fixed:%s\n", TO_UTF8( cmpFields[i].GetName() ) ); )
m_FieldsBuf.push_back( cmpFields[i] );
}